Why Everyone Hates Web Components

I couldn't NOT read the new Ryan Carniato article, give him a sub @ryansolid

Web components have been...rough. For awhile. Thankful the world is realizing.

SOURCES

S/O Ph4seOn3 for the awesome edit 🙏

[darylbarnes]

Theo seems to not understand that the Browser itself uses Web Components and Shadow DOM for what seems like simple elements. An HTML element does NOT have to be a primitive that is not composed of smaller entities. Just take a look at the simple input element or the details element in the Chrome console. Both of these elements have a shadow dom with functionality that exists simply by placing it on the page. In fact, Web Components are just an extension of this idea that we should be able to have access to this kind of power to create our own elements. And just like input and details, these elements can be composed of other elements.

[foxoninetails_]

Hey Theo, loved discussing with you in the chat during this whole thing. I had a few thoughts that didn't really seem to stick during the conversation, which I think may clarify some of the issues you're seeing.

The biggest thing is that, while framework authors' frustrations about being sold the idea that web components are for them are entirely legitimate, that is a flawed premise to begin with and should never really have been part of the discussion. If framework authors can make use of it, that's great! But for the most part, it's not aimed at them, but at a completely separate use case. The people pushing for frameworks to integrate with web components in the way you and Ryan described did both those framework authors and the web components API a disservice.

The primary function of web components is, put as simply as possible, to extend HTML. They aren't and were never "components" in the same sense as frameworks use the term, and the name "web components" has caused a lot of confusion as a result. They're far more similar in practice to an XML extension than a framework component - you're defining a new HTML element, in terms of the existing elements, with its own inherent semantic meaning and built-in behavior. That comes with both benefits and drawbacks, and it fundamentally serves a very different use case than what frameworks call a component; for example, while you might legitimately build an entire website almost solely out of React components for dozens of layers deep, and that deeply nested structure is idiomatic for React, you would effectively never use web components that way if you want to keep your sanity intact. But conversely, web components are perfect for cases like custom form inputs, where you don't want to have to think about the innards of your custom form input basically ever after you've built it, and you simply need the browser to see it as just another form element to be processed - a localized, self-contained use case, which may be used multiple times on a single page, in which the details of what's inside the component are best hidden away.

That said, it's not like web components can't be composed, but rather that defining web components in terms of other web components isn't idiomatic. They can be composed using <slot>s (the idiomatic way, where the shadow DOMs of each component aren't actually nested and the nested component is treated as a child of the outer component, rather than an implementation detail), or just by jamming one web component in another's shadow DOM (not idiomatic, structurally implies that the nested component is a hidden implementation detail of the outer component). Notice the distinction I'm making there - the shadow DOM is where implementation details live, and the light DOM is where content lives. That concept is fundamental to understanding the design intent behind web components, why slots work the way they do, and so on; I would even go so far as to say it's the underpinning of the entire API. And it's for exactly that reason that I claim putting web components inside each other's shadow DOM is, while entirely possible (contrary to claims in the video), not an idiomatic way of using them in general - they're designed primarily for building small, isolated parts of your site, not for structuring your entire site architecture around.

[jbest]

Web components are another tool in my toolbox. I worked on a workflow designer using D3. This was integrating with a legacy application, so the shadow dom keeps everything nice and isolated. Web components fit nicely into this projects requirements.

[griffadev]

The article content is good but pretty much everything Theo says off the cuff about web components is incorrect but said with such confidence

[gardiner_bryant]

I use Web Components. I like them. I don't get the hate.

I've written hundreds of them.

[erikslorenz]

Web components by definition cant fail. They are in the browser forever. And they keep getting better, albeit slowly. For something like a design system with primitive UI components they make way too much sense. I'm excited for Web Awesome.

[saelorasinanardiel]

We use a handful of web components. every single one is basically a full SPA written in vue designed for easy embedding in other projects. I doubt anyone who's embedded them even knows what a web component is. it breaks down to "to use our widget, stick this script in your head and you can now use this 'new html element'"

[tmbarral]

Web component as a response to React ?
Are you certain of this, Theo ?
I remember reading about WC in 2011 or 2012, if not before. React appeared after that.

[fernansd]

I believe the main issue of these discussions about WCs are due to them being called Web Components.
For example, if they were called Web Elements, clearly showing they are meant to extend HTML not build apps per se. Then the conversation would be about how these edge cases should be ironed out, not about whether they are unnecessary or not. Beyond considering this a necessary browser standard or not. They clearly need to be worked on so they behave better.

As a platform, currently the web benefits for having this API for experimentation. However, from the experience framework authors shared, it is undeniable the initial implementation left a lot to be desired and still needs to be worked on. Just as it happened with CSS, when the current bugs are solved, WCs will neatly fit into a place when simpler frameworks are enough for most of the web.

Remember this, big frameworks are only needed for big web applications. You don't need a framework for your blog with some interactive elements. Or a wiki site. Or a news site.
But this is a different conversation altogether.

What I believe WCs promise now is to think about a web where most websites don't need to have heavy reactive frameworks. As Lea said, you would use a WC for an element which would exist if dev resources for browsers/standards would make it given infinite resources.

To close my thoughts I would add, that we are already in a phase were big frameworks are starting to not be used for simple sites, with the push for vanilla js and server-centric frameworks.
The survey done by the Chrome teams was done quite a while ago when JS sucked a lot more and the web wasn't as mature. Maybe today results would be different. With even some folks coming back from Typescript. And if web components have performance issues, then maybe as part of this less is more trend, they should be optimized as they did for the frameworks before. I remember when React, Ember and AngularJS slowed the web for having too much JS shipped on slow internet and doing a lof of thins on JS when engines weren't as optimized and computers weren't as powerful.

[xpamamadeus]

youtube and github uses them and saying no one uses them its ridicilous

[ratoshi]

I don't think web-framework authors are impartial on this issue.
They built their entire paradigm around the world before custom elements, and are psychologically and financially locked into that paradigm.
Once you embrace the next paradigm: HTMX/zero-build/vanilla-js, webcomponents make a lot of sense.

[ZeroTorySeats]

Not all sites use a framework. I don’t love the API, they are far from perfect but if you just want one or two interactive components they are better than nothing. It’s nice that they work without a build tool.

[DrunkencoderPayk]

but you can actually use web components inside web components. thats not an issue as long as the are registered beforehand. they will be in the slot next to the shadow dom. this means their shadow domes are actually never nested, which is pretty clever actually

[brnto]

8:33 I don’t get the standards argument. Standards evolve and can improve. CSS and JS has been evolving quite nicely over the decades.

[samwight]

Kinda a dumb take. Web components are amazingly useful for things like design systems (eg. with Stencil, which is a fantastic framework). When you're working on small projects, you don't need a design system and something like shadcn works great. The vast majority of web code is not in small projects though, it is written for huge projects at large companies. That is where you need a design system. Often you want this design system to work across multiple frameworks. And that's where the issue arises: getting the frameworks to interop with each other is INSANELY hard. None of them play nice with each other. Try rendering a Solid component inside of a React component as a child. It's extremely hard while allowing that React component to be used like an Angular component in an Angular app.

Web components are supposed to fix that. You can implement a common set of HTML elements (which in larger apps SHOULD NOT be app-specific), and it allows you to reuse it in any framework out there. That's why you have companies like Amazon or Ionic using Stencil to build design systems, because it allows them to use whatever the right framework is a good fit for the job they need, while using their design system.

Sure it's harder to implement for framework authors. But framework authors have completely ignored interop stories for years and it is not a priority for them. React has no reason to care about interop with any of the frameworks that have a quarter the size of it, because if a component is written already that you need, it's probably going to be written in React. Web components might be a shitty interface for framework authors to have to adopt, but for the kind of interop that companies and larger teams need, it is a necessary pain that would've had to been done if we needed good interop anyways.

[DrGaius]

why did you give Lit an A rank in your framework tier list if web components suck?

[soviut]

I'm dubious on the claim that "not all elements are components". Every element has properties, every element is an event emitter. Further, many elements have logic and state; details element can be toggled, forms have validation state, a search field has a "filled" state which can be cleared using the X or esc key, buttons can be disabled, a fieldset can disable all the form fields within it, etc. Even complexity isn't a delimiter since form fields like an upload field have multiple sub elements and date fields have complex popovers.

[winns.x]

We use them from time to time, if we need something, not too complex to write, that can be just dropped to any project and used.

[yokowasis]

I love web components. Sure, it lacks when compared to React / Svelte Components. But when you have to work with react, svelte, and php, and plain html, and God knows what js framework spawning in the future. Creating 1 web component to use for every project suddenly makes sense.

[willcoder]

*"Just"* use X. *"Just"* do Y. "Just" minimizes someone else's efforts, when it's said this way. It's arrogant and inconsiderate to suggest the other person couldn't imagine X or Y. I usually learn more about the context of a problem when I ask: "Have you thought about X or Y?" with some humility instead. I *"just"* didn't know everything. (Disclaimer: "just" _can_ be used without arrogance in other ways, but we techies seem to use it in the arrogant form a lot.)