What they are doing is backing in the browser, via specifications and proposals to the platform, their ideas of a framework. They are using their influence in browser makers to get away in implementing all of this experiments.
Web Components are presented as a solution, when a solution for glitch-free-UI is a collaboration of the mechanics of state and presentation.
Web Components have too many mechanics and assumptions backed in, rendering them unusable for anything slightly complex. These are incredible hard to use and full of edge cases. such ElementInternals (forms), accessibility, half-style-encapsulation, state sharing, and so on.
Frameworks collaborate, research and discover solutions together to push the technology forward. Is not uncommon to see SolidJS (paving the way with signals) having healthy discussions with Svelte, React, Preact developers.
On the other hand, you have the Web Component Group, and they wont listen, they claim you are free to participate only to be shushed away by they agreeing to disagree with you and basically dictating their view on how things should be by implementing it in the browser. Its a conflict of interest.
This has the downside that affects everyone, even their non-users. Because articles like this sell it as a panacea, when in reality it so complex and makes so many assumptions that WC barely work with libraries and frameworks.
We currently use Lit for the framework on top (you do need one, that's fine). For state management we just pass props around, works great and allows community to easily develop custom cards that can plug into our frontend.
The downside is lack of available components. Although we're not tied to a single framework, and can pick any web component framework, the choices are somewhat limited. We're currently on material components and migrating some to Shoelace.
I talked more about our approach to frontend last year at the Syntax podcast[2].
[1] https://www.home-assistant.io [2] https://syntax.fm/show/880/creator-of-home-assistant-web-com...
Sounds like people are about to rediscover why Redux came to be.
It’s more a custom element API than a component API, I mean that line in the sand is pretty subjective, but I just can’t see this API being a part of any major web framework, I can see that with shadow dom, I can’t see that with the whole customElement.register and garbage you have to do in the constructor.
Also the goals of this API are just not aligned with the purpose of a framework/component system. I do encourage people to play around with them but it’s really annoying to hear how they’re being promoted they’re are a lot less exciting than the platform advocates are willing to admit but that doesn’t mean they are useless but we need up stop pretending they’re the future of web applications.
Frameworks are often designed with the goal of managing application complexity without being overwhelmed by the shortcomings of the platforms. Web Components have done little to reduce the need for such a thing.
That said, this and many other webcomponent articles mischaracterize usage cases of webcomponents:
1. Being "Framework-free"
Frameworks can mean anything from something massive like NextJS, all the way to something very lightweight like enhance.dev or something more UI-focused like shoelace. To suggest being completely free of any kind of framework might give some benefits, depending on what kind of framework you're free of. But there's still some main benefits of frameworks, such as enforcing consistent conventions and patterns across a codebase. To be fair, the article does mention frameworks have a place further down the article, and gets close to articulating one of the main benefits of frameworks:
"If you’re building something that will be maintained by developers who expect framework patterns, web components might create friction."
In a team, any pattern is better than no pattern. Frameworks are a great way of enforcing a pattern. An absence of a pattern with or without webcomponents will create friction, or just general spaghetti code.
2. Webcomponents and the shadow DOM go together
For whatever reason, most webcomponent tutorials start with rendering things in their shadow DOM, not the main DOM. While the idea of encapsulating styles sounds safer, it does mean parts of your page render after your main page, which can lead to DOM elements "flashing" unstyled content. To me, this janky UX negates any benefit of being able to encapsulate styles. Besides, if you're at a point where styles are leaking onto eachother, your project has other issues to solve. The Shadow DOM does have its use, but IMO it's overstated:
https://enhance.dev/blog/posts/2023-11-10-head-toward-the-li...
<h3>${this.getAttribute('title')}</h3>Custom Elements missed the mark with the problem frameworks solve. We don't necessarily need custom HTML, we needed easy way to build and manage the whole data and visual flow locally while treating the backend response as a datasource.
Nowadays, I use web components for one-off, isolated components as a replacement for iframes, but rarely for anything complex.
Coding agents will allow us to write plain JS way more quickly but it still takes a bit more time by humans to read compared to reading something that was written with in a framework.
Until the day that I don't have to do reviews of my AI generated code, or some sort of pseudocode abstraction layer becomes available, I think there is still a place for frameworks and libraries to create web components like Stencil.
BUT, these frameworks are most useful for actual "applications". So much of web development is "merely" focused on making beautiful "pages", and a framework can very well be overkill in those scenarios.
People "going back to basics" really need to learn to evaluate when what you are doing (or how much) falls into each camp.
(Ignore me if all you do is readonly pages with no state transition)
A lot of times I just need a small component with state simple enough that it can live in the DOM. Custom elements gives me lifecycle hooks which is often all I really need for a basic component.
I ran into https://github.com/WICG/webcomponents/issues/814
As long as this is not fixed I can't take Web Components seriously.
The article also misses something more important: broad native ES module support in browsers means you don't need a build step (webpack).
The "AI makes it easy!" part of the article makes me want to hurl as usual. And I'll stop short of an accusation but I will say there were some suspicious em dash comparison clauses in there.
Put it another way, you can make a page out of web components without using a framework, but you are not going to convert a React page with that approach.
This is the truth that a lot of web component advocates gloss over on purpose. They know this, just like they know that there's no decent templating solution either as tagged template literals still need escaping. Then there is efficient DOM updates, etc. (aside, I got Claude to write a web component recently, and it's code had every single keystroke assigning the same class to the element)
There are many features like this, and when you finally get them to admit it, they just say "write your own"!. Well guess what, frameworks already provide all of this.
The really funny part is that Stencil, one of the popular tools for writing web components actually does provide all of the above! Their web components have exactly the same type of features you'd expect in any other framework *because it IS a framework*.
Which again highlights how stupid the discourse is here. It's not "independence" of frameworks, your components will still depend on a framework of some kind, be that Stencil or Lit or whichever thing YouTube uses now or your own supporting code to get back even half the features you get elsewhere.
It all starts to make sense when you realise that the Chrome developers hated frameworks because they didn't understand them, pushed for web components, not realising frameworks dealt with all of the above.
https://youtu.be/UrS61kn4gKI?t=1921 32:00 (but the whole video is valuable and I wish everyone on both sides of this debate would watch the whole thing).
I think the only thing I like about web components is they scope "this" to the element it owns.
And I don't find that bad for web components, as a whole, but if you wanted to build an app, you would most likely just use a web component framework (something that uses a base component and extends the rest from it), in which case you're limited to what that framework provides (and it won't be as robust as any non-wc framework). But if you're just looking to quickly slap in a component that "just works", you would have to do some real diligence to make sure it would fit which just is not a problem for any defined framework.
My approach has been to make a complete suite of CC0 components (which also meant no dependencies that I didn't write myself, so that I could make each dependency CC0, too), and let each component be an entirely standalone library, so that you could treat them like drop-in new html elements, rather than libraries to ingest and work with (in effect, the component should be as self-sufficient as an <input> or a <select> and require no js interaction from the consumer to work; just add the script and use the new tag). Of course, the major downside of that is that each component has to be it's own library which needs competent documentation (at least, I'm not going to remember how 15-20 different components all work in fine detail. I want some docs and examples!), and no other dev has any way of knowing that these components won't require an additional "base" script or component to work.
Overall, though, I'm happy with the results I've got (just finishing up all that documentation, at this point). And I definitely don't mind things like web components "not having reactivity" or "state", because I, personally, don't like being forced to push every piece of data through the rube-goldbergian plinko machine of reactive state. Different paradigms for different purposes and all that. So between not being forced to use it and having the events and attribute observation to be able to use it when I want it, I'm pretty satisfied with the state of web components on that front.
Honestly, the biggest issue I have with web components is how they work with "parts". I had to write a whole little library to make working with parts reliably comfortable for both library dev and consumer devs. I'd love a way to query on the "part" attributes, while within the component's shadow dom. As it stands, the best you can do is `[part="my-part"]`, which has obvious shortcomings if you're trying to use it like a class. Multi-classed elements are easy to select; doing anything complicated with part selectors would quickly spiral into a lot of `[part*="red"]:not([part*="redorange"])`, instead of `.red`, or whatever. The light dom is better because the ::part() selector treats parts like classes, so you can write selectors like class selectors. But, of course, you're limited to the part itself, so every single thing that should be stylable (in a lot of components, every single element; implementing devs should control style and display layout, just not functional layout) needs to have a part. And that's still a fairly superficial problem compared to the issue of not being able to automatically convert all "part" attributes into an "exportparts" value for the parent element. Again, not something that most libraries will need, but when you do need it, it's crazy that I would have to make a porting solution, myself. That's just begging for errors.
In any case, I generally agree with most of what the article has to say. As others have pointed out, some of the examples aren't really "best practices", but the overall point that web components are perfectly capable of building with is a solid one. I do still think that the old adage holds true, though: 'if you don't use a framework, you'll build one'.
[0] https://github.com/catapart/magnit-ceapp-taskboard-manager
(Notes for the demo pages: not production ready; the component will write to an indexedDB instance in your browser; the pages will add to your browser history [an option that is currently on, but is not the default config of the component];)
Anytime it's attempted, someone tries to scare them into thinking that their code will impossible to maintain without a framework to provide "structure"
We need to talk more about pages vs applications, web compnents are an excellent choice for making pages more maintainable, but without support for somehow automating translion of internal state (often data in a machine suitable format produced by an API) to visual state (for human consumption where said data might be scattered or otherwise recomputed) then you do run into the "maintainability" issues as soon as the visual state needs to be updated by user updates to the more machine near data model.
According to the people "helping" them, before writing any line of code you should learn about ruff, uv, pip, venv, black, isort and so on… I guess most people aren't good at imagining other situations than their present one.
To all of the above I might add that without "custom elements" Web Components is severely crippled as a feature. If I want to sub-class existing functionality, say a `table` or `details`, composition is the only means to do it, which in the best style on the Web, produces a lot of extra code noone wants to read. I suppose minimisation is supposed to eliminate the need to read JavaScript code, and 99% of every website out there features absolutely unreadable slop of spaghetti code that wouldn't pass paid review in hell. With Web Components that don't implement "custom elements" (e.g. in Safari) it's a essentially an OOP science professor's toy or totem. And since professors like their OOP theory, they should indeed take Liskov's principle to heart -- meaning the spec. is botched in part.