I've been a fan of web components since I first heard about them. I wrote my first article about them probably 7 or 8 years ago (which I can no longer find, sadly). I've written numerous libraries for writing web components, including but not limited to Haunted. I've given talks on building web components. I've argued about them on Twitter (probably too much).
I remain a web component fan today, and find ways to bring them into most frontend codebases I'm apart of (Astro uses web components!).
What's changed is that I no longer believe in component-oriented architecture; that is the architecture where (front-end) apps are built like lego blocks out of components. It is this architecture that has taken over front-end in the last ten years and the web component community (myself included) has continued to chase.
Frameworks have always existed on the web, including in front-end. In the jQuery days the focus of frameworks was to enhance server-rendered HTML. Eventually the focus shifted to building entirely client-side applications. The SPA pattern.
The web component community quickly embraced this pattern. And if you are building a purely client-side app, using web components is as good of a choice as any other. In some ways it has advantages.
People enjoyed (and still enjoy) the DX of building front-ends with components as the central building block. So components expanded outside of client-side apps, and became used for nearly all types of web pages; from blogs to e-commerce and more. This brought in the need for SSR (server-side rendering).
The web component community again chased frameworks down this rabbit hole, but this time they were not such a natural fit. Since they are browser APIs there's no natural way for them to be used in a server context. New APIs were needed, and still are needed. Yet we continue to chase.
The number of new APIs that will be needed to complete the SSR story is massive; given the slow pace of web spec development we're not on track to complete the story in 5 years or 10 years. Probably not even in 20 years.
However this time there's probably little (if any) advantage to using web components for server-rendered apps. Isomorphism is complex enough; web components adds extra complexity with the need to render declarative shadow DOM and the still-unknown solution for bundling CSS.
Frameworks have had an easier time with SSR (though still with many problems) largely because they add an abstraction layer on top of web standards. This abstraction makes it easier to make code portable.
Given the prior and current difficulties with SSR in web components, many within the community have essentially given up. Progressive enhancement should be the bedrock of web component usage; they literally are hooks into HTML lifecycle, after all. Instead we have members of our community saying it's more trouble than it's worth.
Not only have we lost in mindshare but we've also lost the moral argument.
For a lot of fans of web components their choice for using them comes down to the fact that they are a standard. I'm sympathetic to this myself; I have vanilla JS web components that I wrote 5 years ago that will still work unmodified in apps today.
But this isn't a winning argument for the broader web community and never has been. You have to tell a story that's better in some (significant) ways. And you can't really do that by chasing what's already popular.
Despite the immense popularity of component-based frameworks, they are weak in some real areas. Web components can present a contrast in style that focuses on core web principles:
The core flaw of component-oriented architecture is that it couples HTML generation and DOM bindings in a way that cannot be undone. What this means in practice is that:
This is maybe ironic in an article that's about web components. But web components are a tool; they are not the goal. Components have a place, an important one, in front-end. But as the central building block, the problems listed above are inevitable.
Frameworks are going to continue trying to iterate on this dead-end model. This is our chance to blaze a new path that more correctly aligns with how the web actually works. A new architecture for developing backend agnostic, progressively enhanced front-ends.
I believe the solution is staring us directly in the eyes. CSS is a declarative language that enhances HTML. CSS is agnostic of how the HTML is produced. Despite this CSS is extremely ergonomic and powerful.
The path is there for web components to be used in a responsible and progressive manner. We just need people with the drive and desire to find a better way than the hole we've dug ourselves in.
I'm building my version of this vision with Corset. I look forward to seeing what other solutions arise.