Rich Harris

Initially, Web Components were put forth as a way to replace JS UI frameworks like React, Angular, and Vue. But it turned out that WCs don't solve the same problems as frameworks.

Frameworks solve three problems:

1) Encapsulation. The DOM APIs don't make it easy to encapsulate reusable UI components. WCs help here.

2) Efficient re-rendering. The DOM APIs don't make it easy to manage client-side state variables, re-rendering just the UI parts that need changing. Unfortunately, WCs don't solve this problem; Shadow DOM slots (sub-components) render eagerly, whether you like it or not. https://twitter.com/tomdale/status/1153309794226147330

3) Quirks. DOM APIs are quirky; they were developed organically by web standards committees. They have a bunch of (well documented) gotchas that you have to work around, making them inconsistent and clunky. WCs don't smoothe over any existing quirks; it just adds more of its own. https://dev.to/richharris/why-i-don-t-use-web-components-2cia

(My favorite WC quirk: WCs don't render at all if the user disables JS. [])

As a result, most WC advocates today recommend using a lightweight framework on top of WCs, e.g. Lit.

In fact, most modern frameworks do allow you to use WCs transparently. (React makes you jump through some hoops, but you can* do it.) https://custom-elements-everywhere.com/

Why bother using WCs if you're using a framework? Because WCs can allow you to use the same component code in multiple different frameworks. Despite…

I see many people have problem with that in the comments here. However I don’t find that to be an issue. Passing properties (as opposed to attributes) allows complex types and many popular frameworks have a handy shorthand for it (e.g. in lit-html you write `<my-component .prop=${[1, 2, 3]}>`).

In my opinion the bad ergonomics is actually when authoring the components (not consuming it). Many of the faults have been excellently pointed out previously[1]. The most glaring the boilerplate you have to write if you want your attributes to reflect a property.

This has an easy fix though, which is that you simply don’t write your web components by hand. You either use a library (like lit-element[2]) or a compiler (like stencil[3]). I’m personally waiting for a less opinionated compiler with a smaller runtime then stencil (preferably no runtime; perhaps that is Svelte with a web component target, I haven’t tried it).

There is also a proposal for a declarative shadow DOM[4], which aims to tackle some of the bad dev experience we have with web components. However I’m personally a little skeptic that it is a good proposal, or that it will fix what most web component devs are concerned about.

1: https://dev.to/richharris/why-i-don-t-use-web-components-2cia

2: https://github.com/lit/lit-element

3: https://stenciljs.com/

4: https://github.com/whatwg/dom/issues/831

There have been many that have hit the front page over the years. If you're not aware of a technology's shortcomings then you're a bad proponent of said technology. They're also almost the antithesis of what the HTMX crowd also preaches as "the one true way" and meanwhile, Wordpressers will continue developing the majority of the world's websites blissfully unaware that either technology even exists.

https://dev.to/ryansolid/web-components-are-not-the-future-48bh

https://dev.to/richharris/why-i-don-t-use-web-components-2cia

https://daverupert.com/2023/07/why-not-webcomponents/

https://paularmstrong.dev/blog/2023/03/11/why-we-do-not-write-web-components/

https://nolanlawson.com/2024/09/28/web-components-are-okay/

https://www.zachleat.com/web/good-bad-web-components/

https://mayank.co/blog/web-components-considered-harmful/

https://adamsilver.io/blog/the-problem-with-web-components/

https://web-highlights.com/blog/are-web-components-dead/

along with some criticisms from very knowledgeable people:

https://x.com/youyuxi/status/1839833110164504691 (author of Vue) https://x.com/Rich_Harris/status/1839785839036887361 (author of Svelte)

Web Components solve a few problems and introduce a few others, use them when they make sense for your needs.

This is a better and more concrete example of the point made in the article:
- https://www.zachleat.com/web/details-utils

The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this.

That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2cia

For all the comments asking what's the difference between this and Bootstrap, Ant, jQuery UI, React, Vue and friends:

Interfaces built with FAST adapt to your design system and can be used with any modern UI Framework by leveraging industry standard _Web Components_.

The important word here is Web Components, which are like React or Vue components but using only standard HTML and JavaScript (no frameworks).

I guess you could even add Bootstrap on top of Fast.

Some references:

- https://en.wikipedia.org/wiki/Web_Components

- https://developer.mozilla.org/en-US/docs/Web/Web_Components

- https://developers.google.com/web/fundamentals/web-components

- https://caniuse.com/#search=components

Also worth reading: https://dev.to/richharris/why-i-don-t-use-web-components-2cia (discussion on HN: https://news.ycombinator.com/item?id=20232628)

Unfortunately, Web Components are still somewhat immature [1], but eventually, our plan is to support vanilla React as well. We really want to nail every single integration that we officially support before growing horizontally, because looking at some of our competitors, often its greatest failures come from rushing framework support.

So, we went with the most popular JS framework first (Next.js), and are gonna go from there once we're confident in it.

[1] https://dev.to/richharris/why-i-don-t-use-web-components-2cia