Have you noticed that there is a regular community.nextTick() that involves heated discussions around “Web Components vs. Frameworks” in some form or another.

It can be frustrating to see the same topics repeatedly pop-up, but I find it interesting to dive into why it does so.

A pattern I often see is a tension where we want to reduce a topic to a simple black and white abstraction, but when we fail to do so, we bounce off to fight another day.

Reductions and Abstractions

We are pattern matchers, and predictors of the future at our core. Much of our progression as a species has been in building up abstractions that allow us to model the future. So, it isn’t surprising that we try really hard in science and engineering to find abstractions.

Often science and math give us a purity of abstraction, whereas engineering has us in the complex muck where we hunt for patterns that are hiding in the world of a massive number of variables.

Early abstractions start out leaky. As we climb to the next level we need an escape hatch to where we are safe and knowledgeable. How much assembly was written in the early years of C vs. today?

Over time, if an abstraction is solid, we will be able to basically ignore a layer, at least in the main. There are a huge number of programmers that have never learned the assembly layer, and the machine layer below. Some may bemoan this at times, but if an abstract is good, many will get by.

NOTE: I still think it is optimal to understand one layer below (and one above if applicable!) as Glenn used to say..

How does this relate to Web Components and Frameworks?

Right! I contend that we are in a messy state of abstractions not being clean here, and the desire to find black and white is hitting up against the world of grey.

The simple to understand views are these:

  • Web Components lost and are unnecessary. Just use the component model in your framework of choice!
  • Web Components are all you need. <Components> all the way down baybee!
  • Use Web Components for UI leaf nodes, and an app framework to glue it together…. it all just works!
  • A company should only allow one framework to be used, and thus reuse is at that framework level!

In the real world, one of these could be true for one form of truth, but they miss all of the nuance and ignore many other forms of truth, such as:

  • For many apps, simple orchestration using Web Components, beyond leaf nodes is fine
  • For many apps, it is overkill to build reusable Web Components, and that’s fine
  • It is rare to see a company (of size) keep every application on the same version of the same framework, and this approach has many many trade offs
  • Sometimes companies buy other companies, and they come with code and legacy
  • It’s ok to experiment with new frameworks and new paradigms, it’s how we progress
  • Web Components aren’t the only way that you can share code, and that’s fine
  • Gluing between component models isn’t fun, but it’s also fine
  • There are very different roles. If you are a vendor of components you will think very differently about how you scale the component set and who you want to target

We can go on and on and on. It’s messy, and it can also work. The environment is changing around us (browser support, evolving libraries, new paradigms such as the recent “compilers”).

I think it is only a good thing for the platform to give us a way to define <our-components>, and I love seeing the interop change over time.

But at the end of the day, what I care most about is that we can be productive, and our ecosystem has content that users love (which includes, but isn’t solely subject to, performance… have you setup performance budgets?).

Do we have all of the components we need to move fast? Tooling? Can we fix bundling to not be a nightmare for developers?

If we can honestly look at ourselves and feel like we are doing the right thing there, the rest is gravy.

It’s OK living in the gray. It’s OK not having worked out the perfect abstractions, yet.