[parasti]

I tried to embrace web components, but when I reached "declarative shadow DOM" I really just stopped seeing the point of all that complexity just to do what I can already do with a library. The target audience of that API seems to be library developers.

[yoz-y]

Yup. Lit element is much more accessible if you want “just” web components, but with a sane syntax.

[cube00]

As much as I dislike Google, Lit has been a nice middle ground for me.

It's lighter then a framework, events are vanilla JavaScript so you don't have to figure out how to make a JS libray you've found work within some framework's custom event bus.

It has enough rendering support so you don't need to update everything with .innerHTML. Change the state of a component, lit will call your render function but only update the parts of the DOM that have changed. I felt that was a nice partial answer to suggestions you need a virtual DOM because updating the real DOM is slow.

[skrebbel]

I’d argue that the target audience of Web Components in general should be library developers.

Web Components are great for distributing UI elements that work with every framework.

Web Components are terrible for just building apps. Use a framework!

From this perspective, Elena seems like a welcome approach. If Web Components are for library authors, and they are, then it stands to reason that Web Component frameworks optimize for that as well.

[troupo]

> The target audience of that API seems to be library developers.

And then most library developers find them severely lacking, riddled with unsolved and unsolvable issues, filled to the brim with invalid assumptions and awkward APIs etc :)

They are somewhat okay as framework-agnostic "leaf" components if the authors spent a lot of time honing the usage and the APIs. Things like date pickers for example.