> lit-html is a genius alternative to virtual DOMs, etc
It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast.
Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.
As for "etc.", I don't even know what etc. stands for. lit is busy re-implementing all the things all other frameworks have had for years. Including signals, SSR etc.
The classMap must be the only expression in the class attribute, but it can be combined with static values
--- end quote ---
So now you have to figure out which attribute this is called from, whether this particular call is allowed in this attribute etc.
So what they do is they parse (with regexes) their "close to HTML" code into a structure not dissimilar to React's, figure all this stuff out, reassemble actual HTML and dump it to the DOM
It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast.
Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.
As for "etc.", I don't even know what etc. stands for. lit is busy re-implementing all the things all other frameworks have had for years. Including signals, SSR etc.