[spankalee]

Of course you can write a syntax highlighter for HTML in template literals. The lit-plugin VS Code extension provides syntax highlighting plus type checking for bindings.

lit-html works by passing the template strings to the built-in HTML parser, so it doesn't need to bring its own.

The benefit isn't just avoiding JSX and build steps, but more importantly avoiding VDOM and expensive diffs. Template literals separate the static parts if a template from the dynamic and remove the need to diff the parts that never change. It's more efficient.

[dmitriid]

> lit-html works by passing the template strings to the built-in HTML parser, so it doesn't need to bring its own.

What do you call this then: https://github.com/Polymer/lit-html/blob/master/src/lib/temp... ? For example, used here: https://github.com/Polymer/lit-html/blob/master/src/lib/temp...

lit-html parses strings with regexps, does an ungodly amount of string concatenation, and only then dumps the resulting string blob into the DOM.

[spankalee]

The preprocessing is far from an HTML parser. It just helps pick what marker to join template fragments with before passing to the built-in parser.

You seem to think this is enough of a problem to comment on every time I mention lit-html, but you never back it up with any reasoning. Why should it be bad to do some string processing? What's "ungodly" about joining the template fragments?

The fact is, lit-html is very fast, and allows embedding parameterized, updatable markup in standard JavaScript. You don't have to use it.

[dmitriid]

> You seem to think this is enough of a problem to comment on every time I mention lit-html, but you never back it up with any reasoning.

I did, 3 months ago: https://news.ycombinator.com/item?id=19649717

And in that same thread, in a sibling comment: https://news.ycombinator.com/item?id=19643593

That also addresses the "not parsing" part.