If you want to drop in a calendar component into your page from npm, it helps if that component's styles don't leak into the page, and if page scripts don't accidentally mess with component internals.
This seems overstated. It’s different but not really harder.
document.querySelector('my-lit-element').elementIWant;
class MyLitElement extends Lit {
get elementIWant() {
return this.renderRoot.querySelector(...);
}
}
They don't work as well for building apps, sure you can do it, but tools like React/Vue/Svelte are much better at building a whole app experience. Particularly when you consider meta-frameworks and the ecosystem around them.
They could work well for building apps if the ecosystem was more invested in giving developers what they actually want in a timely manner. (Looking at you template instantiation)
The problem with using them for component libraries is that you break your rendering paradigm of the framework you're using, and that can lead to situations like trying to add event handlers to child components impossible for instance, or having to over-use refs
The language is still there. If anything, it has become more aggressive. Now lit (and stencil) are "standard-based" and "future-proof", and "they are not frameworks", unlike all those non-standards-based framework abominations. (at this point most people roll their eyes).
> They could work well for building apps if the ecosystem was more invested in giving developers what they actually want in a timely manner.
The problem is that none of the people involved in the development of web components ask what developers want. If they ever ask, any answers (including answers from other framework authors and contributors) are ignored, derided, and misconstrued.
There's a reason even people and frameworks who really advocated for web components in the very beginning (Vue, Svelte, Solid) are completely against them now.
Doesn't mean it's a good feature. This is recognised even by people who push them: https://w3c.github.io/webcomponents-cg/2022.html
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- end quote ---