The Failed Promise of Web Components

Fully agree with the author.

My biggest complaint about web components is that I don’t see a lot of advantages over using React, Svelte, or some other JS library. The author hints at this: if I’m already committing to a big JS build process, why wouldn’t I reach for one of these more ergonomic JS tools? Warm fuzzies for trying to use open standards isn’t enough to convince most people to switch away from more popular JS solutions.

The benefit isn't warm fuzzies - it's interoperability: with other components, tools, the browser and devtools, other developers.

If you build an app with web components, even if you're using one specific helper library to do it, it makes it possible, easy even, to incrementally migrate to other libraries. You can migrate top-down, bottom-up, or even middle-out to other helper libraries and have a continuously working app. You can import and use another web component built with another library without being constrained to just the framework you chose.

You can even build an app with all web components, later decide you really don't like them and want to use only a framework and still easily incrementally migrate top down and not break the app.

This makes web components the much safer choice for large and long lived projects, and more flexible for projects of all sizes.

One huge advantage is that you can isolate a web component in its own shadow DOM, which means it has CSS that's independent from the rest of the page. If you're making something for other people to embed in their code, even if you're on the same project, you can save them from breaking it by styling it by mistake.

You can also close the shadow DOM to stop people easily inspecting it, but I must admit I haven't actually figured out a reason to do that yet.

That is the same if you use e.g. styled components with React, where every component is self-contained and doesn't leak the styles. The mechanism is different, but the end result is the same, and oh it's a game changer IMHO.

(Disclaimer: author and editor of the modern custom elements spec here.)

The specific "failed promise" that I see is largely this positioning of web components vs. frameworks.

How web components was originally envisioned was as leaf-node or light-DOM-using components, of the sort HTML already has. For example, <dialog>, <details>, <input type=range>, etc. Web components was supposed to give you the tools to create your own components of this sort, such as <tabpanel->, <toast->, <carousel->, <switch->, etc. In particular:

* Custom elements gives you the ability to just drop in tags, like you do with vanilla HTML, and those tags can react to lifecycle events like being added/moved/attributes changed, automatically. The browser mediates between those occurrences and the web component's code.

* Shadow DOM lets you encapsulate the inner details of your component, while using slots to reproject content into it. So e.g. <switch-> could have its innards entirely in shadow DOM, just like <input type=range>. While <tabpanel-> would be given children by the web developer using it, with some of those children being special (like <summary> is special for <details>), but some parts hidden in the shadow DOM and not provided by the web developer (like the disclosure triangle and behavior for <details>). More on this in https://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

From this perspective, the lack of data-binding (cited in a sibling thread) is not a big deal. There's no data binding for <input>, or <details>, etc. You just use normal DOM children and attributes to supply the data, perhaps with a framework to do that via binding or React-style re-rendering or whatever.

Instead, we've seen people use web components as a React competitor. They want to write their whole app in web components, starting from a <my-app> component on down. It turns out the system is flexible enough to do this, but it wasn't designed that way from the beginning, and doing this doesn't play to its strengths. You end up just creating new frameworks, which are slightly smaller and potentially a bit faster than other frameworks because they can rely on native code for some of their lower-level building blocks like style encapsulation. But you're not living up to the promise of reusable components which behave like built-in elements.

Edited to add: I do understand where developers are coming from in this regard. Using web components for leaf/reusable components and React/Vue/whatever for app-specific components is probably twice as many component models as most app developers want to deal with. I'm not sure how to deal with that tension.

But why should developers have to use a framework like React to do something the browser could provide for them? Not everyone is writing a JS application. Some just need to add some custom HTML, CSS and little bit of JS.

Agree with this 100%. It's called Web Components since it's best used for writing individual components that be dropped into larger apps. I did a side project with LitElement recently, and just could not find the value add over React. That's when I realized that was never the intention anyways.

I think the desire to make Web Components a React competitor also comes in part from the movement towards 100% static sites, i.e. no server HTML generation. So if I'm building a shopping app, I would never create an HTML file with the following with proper declarative HTML:

<shop-app> <shop-item name="Nike Air Force 1" price="85" currency="dollars"></shop-item> <shop-item name="Nike Lebron 18" price="130" currency="dollars"></shop-item> <shop-item name="Nike Kobe 8" price="145" currency="dollars"></shop-item> </shop-app>

Then, you can add interactivity with JS events or a JS framework. Instead, you'll just see:

<shop-app></shop-app>

where the data to render the child elements is dependent on an AJAX request that gets the initial data. Creating standalone, declarative, and well-scoped components is just not necessary in this case, since everything is done in JS anyways.

There used to be something similar to do this called "scoped styles", but they were removed in favor of WebComponents. We could have had this without all of the Shadow DOM baggage.

Though maybe it's coming back now? https://github.com/w3c/csswg-drafts/issues/3547

I don't think the GP was arguing against that. If you're already committed to an existing build process building new components as web components doesn't really have many advantages vs a component built in react. It's just adding needless complexity.

My thoughts exactly. For some reason people tend to think that a web component should stand on its own from high level. But that's just not how HTML works. Something like <shop-app></shop-app> should be seen as an anti-pattern IMO.

I see web components as a compositional approach for dealing with complexity.

Something else that is extremely powerful that people seem to forget is that you can add a src attribute to your web component that links to JSON data, or HTML fragements on a server. It can give you a lot of caching and concurrency opportunities, browser engines are extremely efficient dealing with this. For most people an src attribute feels really obvious for an img tag, but apparently less so in other contexts.

Because then you don't have to pass a huge framework library down the wire along with all of your custom code? Look at it the other way, if you don't get a big advantage over web components by using React, Svelte, etc then why would you use them? Web components are natively supported by modern browsers. Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments.

The difference is that web components provide browser supports low level APIs which frameworks can use to make isolated components.

Sure, you can get the same effect in React. But that only works if everyone on your page is playing by the same rules and using React.

I can drop a web component into some legacy page which is full of old school jQuery and global CSS styles and my component will be isolated and work. Try the same trick with React in that situation and it will likely conflict terribly and get stomped by the old legacy code.

> Using a fairly simple base class like Lit-Element to provide some template niceties and lifecycle hooks gives us all the extras we need. We've figured out a really nice top-down functional state pattern for data that eliminates the need for two-way binding and requires very little "framework" level code - it's probably like 100 lines if you take out whitespace and comments.

I'm also a fan of LE, which I'm using to build my current side-project.

However, the data doesn't back up this claim. A component built with LitElement gets about 19 KB added to it when bundled:

https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...

In what way does <shop-app> not deal with complexity through composition? It is a component, composed of other components, which in turn are composed of further components.

At what arbitrary level of complexity should we stop composing?

As somone who builds large apps via web components, I couldn't disagree more.

I'm able to compose components into higher order screens and get an enormous amount of reusability across projects.

I have a set of components, screens, etc... that I've built up over time and I can mix and match them and whip out an app extraordinarily fast.

Additionally, there are some great design systems and component libraries like Ionic built on top that make this even easier.

I can write a component for a client, and they can use it anywhere in their ecosystem, regardless of technology.

Web components can be built separately to the rest of an application as standalone components and included by adding a <script> tag, and then using them is as straightforward as using an HTML tag. You need a build process for the component (or the author of the component does..) but you don't need one for the website you're using it in. You can do that with a React component as well but you don't get the benefits of things like styled components if you do. You do with web components.

you can make your component's css "not leak" if you name all it's classes with random uuid and scope all selectors accordingly, exactly what styled components does. But "not leaking css" is a nicer way of saying that you can't customize it.

At the level where the overhead from it exceeds the benefits of componentizing. It's a subjective judgment, sure, but that doesn't make it any less real.

In particular, if something is never going to be re-used, what's the point of componentizing it?

In some contexts, decomposition into easily workable scope of complexity.