I began developing some web components without delving deeply into the mechanics of Lit and Polymer, aiming to identify gaps in the standard web components API. Early on, I created several decorators and, in hindsight, they closely resemble what Lit provides. Therefore, I might concede that Lit could become a standard. However, since I haven't used it personally, I can't fully endorse it yet.
I think there’s a bit of a misconception for people coming from other frameworks when it comes to Lit and it’s relation to vanilla web components.
It’s not like it’s “compatible” but a different thing, Lit is actually a standard web component the same way as a vanilla one might be.
The only difference is that you extend a different base class instead of HTMLElement, but Lit also extends HTMLElement, they just give you a massive quality of life upgrade when it comes to boilerplate and other developer experience factors and it only costs you like 5kb.
To the point that I think it’s generally a bad idea to extend HTMLElement directly. It’s very very rarely a good trade off though exceptions obviously exist.
I agree, but I feel like there is something still missing.
The render lifecycle works best when everything is already in memory. Fetching data based on state updates is tricky. Tasks are supposed to fill this gap, but are still a bit clunky:
The most reliable approach for me has been to batch api calls and state updates manually in a separate method on the element, and let lit focus only on rendering.
