At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing.

Normal HTML elements don't exclusively use HTML attributes either. Surely you've used button.onclick or element.classList or element.innerHTML?

Being plain HTML is important for the user of the element.

That the element may use a library for its implementation is basically irrelevant.

Hi.

That's not web components, though that's lit-html. That's an additional library you need to pull in to manage your web components. Which kind of ruins a lot of the stated benefits of web components. If I need a framework to write my web components, why not just pull in a different framework that skips the web component level completely and just outputs HTML/CSS directly? What is this intermediate step actually bringing me?

How does using a library ruin the goals of the components at all?

The goal of web components is to enable interoperable, encapsulated, reusable components, where how they're built is an implementation detail.

You can use a web component that used lit-html without knowing anything about lit-html, it even that the component uses it.

In theory it is completely an implementation detail, I agree. In practice, it's bloat. If every web component I use in my project might pull in a completely different framework behind the scenes (and worse: if those web components depend transitively on other web components that pull in yet more frameworks), then I now have to deal with all of those different frameworks. Each of them will load more bytes and make my page's startup time slower. Each of them will have their own state management systems. Each of them will have their own approach to templating. Each of them will behave subtly differently in practice.

Why bother when I can just write everything in a single framework?

Not in <template>s, the vanilla HTML alternative to this.