[slibhb]

Web components fill an important niche: creating a library of components that can be easily used in react, angular, some other framework, no framework, or some framework that someone will invent next year. I expect their usage to increase over time.

[dmix]

Modern JS frameworks are heavily mixing mostly static with limited amounts of interactive components but all in one system. Where everything can still be the same component architecture, the same UI systems, same CSS/JS packages, same build systems, etc but you selectively choose which components (or small sections of a page) are interactive and require hydration.

I don't really see how Web components fill that picture as cleanly. You would basically still forced to choose between component overhead/custom code OR static HTML, creating a formal discintion rather than a boolean or flag or whatever. Why create that distinction just because it's "native" to the browser? The DOM is sufficient when your default is static and components are always SSR in the same DOM model.

It basically only makes sense if you're not building a "holistic" single frontend framework driven site and rather are mixing various server side view systems and occasionally adding a couple components.

Basically the sort of thing better suited for major legacy sites like Google rather than something you'd ever choose from the ground up.

[no_wizard]

This is a half truth. Their are big problems with this approach, as I think a lot of folks are finding out the hard way, namely:

- You cede rendering control from your framework to the web component, if it does anything like conditional children etc. meaning it can be hard to optimize or you get stuck using refs, which is suboptimal and in some frameworks makes optimizations hard to achieve

- it’s de facto CSS in JS and to boot your styles are also locked to shadow dom. Yes I know this isn’t true in an absolute sense but in practice all the web component implementations leverage this. This makes styling harder, can have performance impacts etc. also means you can’t leverage CDN caching and distribution for your styles

- FOUC is a real problem with web components as it exists today.

- Interop varies and can have gotchas, especially with custom events that may be emitted by components

- You can’t get fine grained optimizations in some frameworks using them because web components in practice often contain some kind of logic one way or another.

- to use slot you must use shadow dom, and that means your app needs to be rendering against a shadow root of some sort, which can be real clunky

[gochi]

I feel the opposite. I feel web components will hit the ceiling far faster due to the reduced churn and because their use case isn't all that applicable to most. Also why we see that a lot of the adoption of WC comes from major organizations with heavy design systems, those who do need to make components work across frameworks due to internal separation. Whereas most smaller teams or solo developers won't be involving themselves in that process at all.

It's a solid stable niche, not a growth kind of niche.