I think Google has done a great job of making Web Components seem both poorly implemented and way too complex. If Angular is the "Google blessed" way of writing Web Components and Angular makes a terrible hash of it, who can build good Web Components?
Angular and a couple other well known frameworks were targeting for far too long pre-spec Google-specific versions of Web Components and Web Components moved quickly past that and settled into cross-vendor specs with smarter defaults and simpler APIs a lot of the marketing damage was already done that Web Components were too complex and too poorly supported.
So much of the Web Components world is stuck with the quagmire of the Shadow DOM, and while there are some generalized use cases for the Shadow DOM, I have the harsh opinion that the Shadow DOM was mostly invented to be "better IFRAMES for Ad Publishers" and not much else. I don't think enough web developers yet realize that the Shadow DOM is entirely optional and its complexity is so much easier to ignore and toss than to try to utilize.
> focused on pulling in the good things from the framework world (i.e. what happened with jQuery), but they didn't.
I'm coming to the growing opinion that between Web Components and the TEMPLATE tag Browser vendors have finally caught up with some of the best ideas of the Knockout-era "Progressive Enhancement" world, assuming you ignore the Shadow DOM as mostly YAGNI.
Sure, a lot of cross-component communication and some of state management goes back to DOM APIs and DOM event management, but there used to be a lot of knowledge in those areas and maybe it past time to return to Vanilla JS ideas about some of that. In the time since jQuery and Knockout, all browsers today have much more consistent DOM APIs for event management, at least.
(Similar for routing. Vanilla routing, even "SPA" routing is easier than ever with modern APIs, even the API not fully standardized and cross-browser yet, but also the improved APIs for hash navigation. Also, Web Components seem a great reminder that MPA routing is great and brilliant, and so well tested in browsers and servers. With View Transitions now generally well supported, and getting better, many MPAs feel as good or better than SPAs even.)
(And I feel like most styling problems with Web Components are self-inflicted with and by the Shadow DOM. It's nice to embrace the cascade again, if you can.)
I was bullish on Web Components for a while, but most of my complaints have disappeared in recent months, and especially in realizing that I was very happy ignoring everything about the Shadow DOM. Sure, I'm not using Web Components without a "framework" but I'm using a far smaller "view engine" than a React or Angular, a lot more "Vanilla", and feeling a bit like it's a Revenge of Knockout sort of era.
> Sure, a lot of cross-component communication and some of state management goes back to DOM APIs and DOM event management, but there used to be a lot of knowledge in those areas and maybe it past time to return to Vanilla JS ideas about some of that.
My approach is, actually, an attempt to inject some Vanilla into front-end component development.
I think many of us, as this linked article that kicked off this discussion included, are thinking of various ways of using more Vanilla approaches. I appreciate the above poster's complaints that we aren't in some promised land of being able to do things 100% Vanilla without some form of reactivity management. That's still all in progress, no matter where you are in the Observables versus Signals "debate", Browsers are back to showing interest in native specs for one or both. (I personally think Signals are just "worse, poorly encapsulated Observables", but either proposal is a good building block for whatever the next steps are and thinner libraries to build on top of them will be.) But Web Components are mostly some steps in the right direction, I think, while that other work remains ongoing.
I also like gradual typing too much to expect to be 100% Vanilla any time soon. Typescript is too handy a verification/testing tool and while I'm still watching the native type stripping proposal with TC-39 with a lot of interest, it's certainly not on a fast track.
I haven't had too much trouble with Shadow DOM so far, and I was especially surprised to learn about `<template shadowrootmode="open">` recently. It makes SSR rendering of web components with shadow DOMs viable and appears to be well supported in browsers.
TLDR: Browser vendors made Shadow DOM for themselves.
Browser implementors use Shadow DOM extensively under the hood for built-in HTML elements with internal structure like range inputs, audio and video controls, etc. These elements absolutely need to work everywhere and be consistent, so extreme encapsulation and fixed api for styling them is an absolute must.
The Shadow DOM API is the browsers exposing, to developers, a foundational piece of functionality.
If you’re thinking about whether Shadow DOM is appropriate for your use case, consider how/why the vendors use it —- when an element’s API needs to be totally locked down to guarantee it works in contexts they have no control over. Conversely, if your potential use case is scoped to a single project, the encapsulation imposed (necessarily!) by Shadow DOM is probably overkill.
Web components are a decent way to make reusable UI, but if they don’t have strong encapsulation needs, you might avoid Shadow DOM.
Angular has nothing to do with web components. It isn't even a way to write web components.
If anything is the "Google blessed" way of writing web components (Google doesn't really work that way), it's Lit: https://lit.dev/
I'm aware of Lit and thought about mentioning some of its past versions too from the pre-spec era, but I think those are even more forgotten.
Around Angular 8-14 era Angular had a lot of "Angular is Web Components" marketing and assured devs at the time that the Angular way including CSS Modules support and its HTML Template language (and its super complex compiler) were "browser standards and the future of Web Components". Obviously none of that played out, CSS Modules are still in spec debate, the TEMPLATE tag was much simplified and no "template language" has been knighted as "the template language". But it was all so heavily marketed and it left scars in what people think of when they think of Web Components. People still expect CSS Modules. People still expect some sort of "blessed" template language out of the box for "Vanilla templating". Among other curious decisions by people marketing Angular to developers as a way to prepare for Web Components. (We can talk for hours about everything wrong with Zone.js and why it has taken Angular to version 20 to start to undo a lot of that [brain]damage.)
Lit was never quite so extreme in its worst pre-spec days, and it is useful for its templating language looked different enough from Angular's to, even at the time, prove that Angular's template language was neither HTML nor necessarily the template language to be knighted by Web Components. But it still had some versions with questionable Google-only decisions that are best forgotten today, and apparently easily forgotten today.
Of course, you don't have to take my anecdata on it, the sources still exist. If only Google made a search engine that works in 2025 maybe you could even find them.
> Lit was never quite so extreme in its worst pre-spec days
"pre-spec days"? What are you even talking about?
Lit 1.0 used non-standard decorators in 2019: https://lit.dev/blog/2019-02-05-lit-element-and-lit-html-rel...
A decorators proposal (and it was a different one than what Google was building stuff off of in 2019) didn't make it to Stage 3 until 2022 (and still hasn't made it to Stage 4).
This also contributed to the idea for years that Web Components were more complicated to support in non-Google browsers or without complicated build processes.
Lit has always supported plain JS ways of authoring components. Just because it also supported TypeScript and Babel decorators doesn't make it "pre-spec".
Lots of developers like decorators, we gave them the option. _shrug_