I used to look at Web Components like “what is this? Is it some modern thing I don’t understand, am I supposed to employ it now?”. As people move away from bloated JS SPA, some of them turn their attention to Web Components.
To not keep the suspense: Web Components are useless in their current design. The original idea of progressive enhancement is hopelessly lost, “you don’t need the JS framework” turned into Lit, Polymer, Stencil effectively creating frameworks on top of Web Components. The idea of “button handling its own logic” was doomed, the distributed logic is much harder to support and you really don’t need to support it, the model of “logic handles the buttons” is more concise and easier to reason about — th…
I used to look at Web Components like “what is this? Is it some modern thing I don’t understand, am I supposed to employ it now?”. As people move away from bloated JS SPA, some of them turn their attention to Web Components.
To not keep the suspense: Web Components are useless in their current design. The original idea of progressive enhancement is hopelessly lost, “you don’t need the JS framework” turned into Lit, Polymer, Stencil effectively creating frameworks on top of Web Components. The idea of “button handling its own logic” was doomed, the distributed logic is much harder to support and you really don’t need to support it, the model of “logic handles the buttons” is more concise and easier to reason about — that’s the sanest 10% part of React+Redux stack.
The original idea
Enchanced HTML was the original idea. Industry needed it, and still needs, the task haven’t been solved, rather worked around with things like Astro. You start from HTML, you put semi-dynamic components (custom HTML tags) into it, and then maybe generate fully dynamic content on top of it (via <template> HTML tag). Unfortunately, even in its original form it already had problems with handling state and reactivity — simple HTML string attributes are not enough. “Okay, let’s bundle the logic into the custom tag implementation” — said the original developers. “Nope” — said industry and rejected the original HTML+CSS+JS bundle idea, thus reducing Web Components into this weird one-wing thing we have right now. The final blow was packaging the new tool into JS class inheritance, so now your every component inherits the whole HTMLElement mess.
So what do we have right now?
Web Components are supported by all modern browsers and I cannot say the whole standard is useless. <template> is a usable tool (e.g. employed by SolidJS for storing templates), Shadow DOM was good for some third-party components, especially before CSS committee was woken up from their cryosleep to finally implement :where and @layer.
But the custom tags? Pretty much no use. Mutable shared entity with stagged loading (i.e. HTMLUnknownElement at first, then YourComponent.connectedCallback() on each customElements.define) to boot into manual reactivity and string-only attributes? That’s like all the tools to shoot yourself in the foot:
JS frameworks decision paralysis
I mean if you look at https://github.com/cferdinandi/reef — no solutions for component props-events two-way changes propogation (you’ll have to use web components or do it yourself), no handling of complex conditionals or arrays of children, and in the end your complex reef-based app you will leak the watchers (i.e. RAM) because there are no weak refs and no explicit unreferencing, you have a big ball of mutual strong references.
Slots look cool until you need an actual reactivity in these slots, and then you addd a framework into the mix, and then you ask “why did I even use Web Components in the first place? Is it providing any solutions or is it providing problems only?”. For example, you can have all the advantages of Lit without ever touching Web components: https://github.com/ryansolid/dom-expressions/tree/main/packages/lit-dom-expressions
I think I also have to reference the well known article by Ryan Carniato with deeper explanation of the subject: https://dev.to/ryansolid/web-components-are-not-the-future-48bh https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh
Discussion: https://www.reddit.com/r/webdev/comments/1pkn5s1/web_components_are_bad_for_you/