It's a bit disingenuous to say the templates are parsed with regular expressions. The way lit-html generates DOM Templates from strings is by letting the browser parse the string through innerHTML. The purpose of the regexes you are referring to is to find the correct insertion points for dynamic values in the template, and has nothing to do with the HTML parsing process.

There is nothing fundamentally wrong with using innerHTML to parse HTML strings. You use the same parser for the content of index.html, and I don't think anyone is advocating to replace index.html with a single script that creates these nodes using a virtualDOM type rendering system.

Yeah, lit-html scans template strings to determine what kind of markers to join them with - comments for text expressions, {{}} for attributes. This is before handing to the browsers HTML parser.

So what? You always pop up to complain about this, like it should be some obvious fatal flaw, but you never explain why it bothers you personally so much.

Does it make lit-html slower? No. lit-html scanning + native HTML parsing is faster than native JavaScript parsing of transformed JSX.

Are lit-html templates "opaque"? That's arguable. Tagged template literals were invented and added to browsers for a reason. lit-html takes advantage of a very nice browser feature, and then hands the result to the native HTML parser, which does understand them. I'd say it's no more opaque than compiled JSX: the browser has no way of knowing that those nested function calls represent HTML, so they're "opaque".

I'm going to continue to shrug every time you complain about this until you explain why it's even bad.

Honest question: How is React/vue/etc. different in this regard?