> 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.
I pop up to complain about this because I refuse to give in to mass delusion about what tagged template literals are. Others have said it much better than I have [1]:
"...we’ve learned not to write code in strings. You’d think this would be a fundamental law of software engineering... Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimise it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it"
Edit. Found another great quote [1.1]:
"The benefits of the component as plain, non-stringified data are not the avoidance of closing tags, but what you can do with those components computationally. E.g. instrumentation, behavior/attribute injections, configuration, filtering etc. An approach based on string interpolation can only go this far, whereas having everyting as arrays, objects, iterators your possibilities of composition & transformation are almost endless..."
> Does it make lit-html slower?
The problem isn't performance, is it.
> Are lit-html templates "opaque"? That's arguable.
It's not arguable. It's a simple fact of life.
Not a single piece of the entire tech stack involved in working with them knows what they contain: not the editor/IDE, not the bundler, not the JavaScript VM, not the browser. In case of lit-html they only stop being opaque when they get dumped into the DOM via innerHtml, and when the browser attempts to parse that string as HTML.
> 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".
The browser has no idea that those blobs of string are HTML until you dump them into the DOM.
However, the browser knows a great deal more about the Javascript code that gets executed in it's VM.
> I'm going to continue to shrug every time you complain about this until you explain why it's even bad.
Above are some quotes from other users that express these concerns.
I can also quote myself from elsewhere [2]:
In a language that’s already a laughing stock for its insane dynamic type system, we said: “It’s all right, we’ll have all our code in strings now, thank you very much, and we’ll make sure we parse it at runtime because what can possibly go wrong”.
The only reason projects like lit-html, HTM and some others can boast about their “accomplishments” building fast, effecient libraries is because string handling has been insanely optimised by the modern Javascript VMs. And that .innerHTML is no longer the slowest operation on the DOM.
...
Why is this bad again?
Because this isn’t code. This is literally taking a bunch of opaque string blobs, parsing them at runtime, and producing some result. All of programming has been busy moving away from coding in strings and parsing stuff at runtime. For the past few years Javascript has been happily re-introducing the worst programming practices. And devs get away with it, too, just because modern Javascript VMs and browser DOM are optimised way more than they have any right to.
...
Since these are just arbitrary strings, no common tools will be able to lint them, analyse them, optimise them unless you write a very specific tool for this particular very specific string structure. And yes, that includes JS VMs.
...
You wanted macros? Here, have run-time string concatenation and regexp parsing, and stringly-typed everything.
[1] https://news.ycombinator.com/item?id=18511943
[1.1] https://news.ycombinator.com/item?id=18052072
[2] https://dmitriid.com/blog/2019/03/tagged-template-literals/