5 ms·

I kinda don't get the whole "put html in template literals". Wouldn't there be no syntax highlighting? And the framework is either putting the string into the D

I kinda don't get the whole "put html in template literals". Wouldn't there be no syntax highlighting? And the framework is either putting the string into the DOM with some regex manipulations, which would lead to some very confusing error messages, or it's parsing the string into a tree, which means it needs to implement what's essentially XML parsing, which would come with an overhead. And for what? Avoiding JSX? If you don't like JSX, just desugar it to nested function calls. Or just use a templating language.

spankalee 7y ago
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 7y ago
  > 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/template.ts#L227 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/template.ts#L97 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 7y ago
    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 7y ago
      > 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 https://news.ycombinator.com/item?id=19649717 And in that same thread, in a sibling comment: https://news.ycombinator.com/item?id=19643593 https://news.ycombinator.com/item?id=19643593 That also addresses the "not parsing" part.
dmitriid 7y ago
My personal opinion is that tagged template literals are the worst addition to Javascript [1] As HN user stevebmark said [2]: --- start 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 --- [1] https://dmitriid.com/blog/2019/03/tagged-template-literals/ https://dmitriid.com/blog/2019/03/tagged-template-literals/ [2] https://news.ycombinator.com/item?id=18511943 https://news.ycombinator.com/item?id=18511943
- tobr 7y ago
  I think your blog post misses an important aspect of tagged template literals, which is that the first argument is an immutable object that is unique to the source location of the template. That doesn’t necessarily invalidate the rest of your argument, but it is a very powerful feature that is not really equivalent to anything else in JavaScript.
  - rounce 7y ago
    What do you mean by 'source location'? Why does this matter? I'm intrigued (and also suffering from conjunctivitis so excuse me if I'm being a bit dense and totally missed your point).
    - tobr 7y ago
      If you put a tagged template literal on line 42 in foo.js, every time the tagging function is called from there, the array of strings passed as the first argument is the same object. It’s unique for the source location of the template literal, so even if you paste the exact same code into bar.js, it will have a different object. So, the function can recognize that it is being called from the same location in the source. This has some interesting implications for meta programming and debugging. I’m not sure that it matters so much to the discussion, but it is a completely unique feature, and really has to be mentioned when discussing what tagged template literals offer. EDIT: Looked for a good reference - best detailed description I could find was here: https://exploringjs.com/es6/ch_template-literals.html#sec_implementing-tag-functions https://exploringjs.com/es6/ch_template-literals.html#sec_im...
brandonmenc 7y ago
> Wouldn't there be no syntax highlighting? Are there major IDEs that don't support language injections?

spankalee 7y ago

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 7y ago
> 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/template.ts#L227 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/template.ts#L97 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 7y ago
  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 7y ago
    > 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 https://news.ycombinator.com/item?id=19649717 And in that same thread, in a sibling comment: https://news.ycombinator.com/item?id=19643593 https://news.ycombinator.com/item?id=19643593 That also addresses the "not parsing" part.

dmitriid 7y ago

My personal opinion is that tagged template literals are the worst addition to Javascript [1] As HN user stevebmark said [2]: --- start 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 --- [1] https://dmitriid.com/blog/2019/03/tagged-template-literals/ https://dmitriid.com/blog/2019/03/tagged-template-literals/ [2] https://news.ycombinator.com/item?id=18511943 https://news.ycombinator.com/item?id=18511943

tobr 7y ago
I think your blog post misses an important aspect of tagged template literals, which is that the first argument is an immutable object that is unique to the source location of the template. That doesn’t necessarily invalidate the rest of your argument, but it is a very powerful feature that is not really equivalent to anything else in JavaScript.
- rounce 7y ago
  What do you mean by 'source location'? Why does this matter? I'm intrigued (and also suffering from conjunctivitis so excuse me if I'm being a bit dense and totally missed your point).
  - tobr 7y ago
    If you put a tagged template literal on line 42 in foo.js, every time the tagging function is called from there, the array of strings passed as the first argument is the same object. It’s unique for the source location of the template literal, so even if you paste the exact same code into bar.js, it will have a different object. So, the function can recognize that it is being called from the same location in the source. This has some interesting implications for meta programming and debugging. I’m not sure that it matters so much to the discussion, but it is a completely unique feature, and really has to be mentioned when discussing what tagged template literals offer. EDIT: Looked for a good reference - best detailed description I could find was here: https://exploringjs.com/es6/ch_template-literals.html#sec_implementing-tag-functions https://exploringjs.com/es6/ch_template-literals.html#sec_im...

brandonmenc 7y ago

> Wouldn't there be no syntax highlighting? Are there major IDEs that don't support language injections?