The biggest issue is the lack of tooling and the inability to manage a shared state. We actually ended up creating new libraries like Stencil & Lit.

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.

This so much, automatic "data struture state -> visual state" without manual synchronization code to update the visual state is the main reason why frameworks are useful, not for components.

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.

I have heaps of experience with Stencil and it works great until a certain size indeed. It is a great way to ship web components quickly.

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.