Polymer is deprecated in favor of LitElement which comes with TypeScript decorators.
[1] https://lit-element.polymer-project.org/guide/start#use-lite...
—-
I should probably edit this:
It’s still string blobs that are totally opaque to the browser, and that are parsed with regular expressions[1] at runtime[2] and dumped into DOM via innerHtml[3].
[1] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc...
[2] http://exploringjs.com/es6/ch_template-literals.html
[3] https://github.com/Polymer/lit-html/blob/61c08a615abadbe58bc...
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.
"generates DOM templates from strings" <- this is what I'm talking about. lit-html literally:
- parses opaque string blobs [1]
- parses them with regexps [2]
- concatenates string chunks together [3]
- dumps the resulting string blob into DOM via .innerHtml [4]
So it does everything that was considered bad programming practices as early as 1999. And does all that at runtime.
> and has nothing to do with the HTML parsing process.
Yeah, no. This is literally parsing HTML with regexps. Because lit-html has to know whether a value is inside an HTML attribute, or inside a tag, for example. In order to know that it has to... well, parse the string that's passed to it. And what do you pass into lit-html? Oh, HTML. That it parses.
> 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, you're apparently advocating to replace index.html with a function call that parses strings at runtime and dumps blobs of strings via innerHtml into DOM.
[1] Because tagged template literals are just function calls with lists of strings, and some values
[2] https://github.com/Polymer/lit-html/blob/master/src/lib/temp...
[3] https://github.com/Polymer/lit-html/blob/master/src/lib/temp...
[4] https://github.com/Polymer/lit-html/blob/master/src/lib/temp...
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.
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/
Vue has its own templating language that gets compiled to function calls that are very similar to React’s [2]. I have my fair share of criticisms against Vue (as any templating system, it’s quite inconsistent[3]).
I don’t think any of them just dump string blobs via innerHtml. And I doubt any of them parse strings with regexps at runtime.
[1] https://reactjs.org/docs/react-without-jsx.html and https://overreacted.io/react-as-a-ui-runtime/ (specifically section on React elements)
Why does this matter? React still eventually compiles down to DOM operations whether that be innerHTML or XML modifications.
--- quote ---
…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 optimize it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it…
--- end quote ---