These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc. This is JS all the way down. And spankalee mentioned below they're adding typescript support to type check the very similar lit-html, so that's coming too.

> That's why I like JSX, it's Javascript all the way down. Everything is code. It's a very well designed and thought out DSL.

It's also kind of a weird to highlight all this for a DSL that actually has to be parsed from a string to get it to be Javascript. Everything else you're talking about is tooling that had to be built special for it, not the language itself.

Why not just say "I like the style of jsx embedding and existing tools better" :)

There exists a medium-sized ecosystem of tools which supports static checks on strings inside angle brackets, a la JSX. There is a smaller-but-growing ecosystem of tools that supports static checks on strings inside backticks, a la HTM/lit-html/etc. There's no fundamental difference here.

With tagged literals you end up with runtime string parsing and concatenation.

Check out the output of the Babel plugin mentioned in the readme

> // input:

> html`<div id="foo">hello ${you}</div>`

> // output:

> React.createElement("div", { id: "foo" }, "hello ", you) options

https://www.npmjs.com/package/babel-plugin-htm

Tagged templates are strings.

Optimize, compile etc. what?

f`string` is literally a function call f("string"). What exactly are you "compiling and optimizing"?

> These are tagged templates, not strings. They work as code at runtime, and it already has support to optimize it, compile it, etc.

So. How exactly do they "work as code" and "have support to optimize it, compile it, etc."?

Here's HTM's main function https://github.com/developit/htm/blob/master/src/index.mjs#L...

It: concatenates strings, parses (via regexes), then concatenates again. Can someone enlighten me as to why this is awesome, is code, is optimized and compiled?

Secondly, the answer is Babel. Since the string's components are part of the AST, it can optimize and compile it as the original poster claimed.

The difference is so subtle as to be irrelevant. You still need to manually parse, process and assemble strings. There’s no magic. There’s no code. It’s just strings (with some values here and there).

It’s enough to see the implementation of HTM (or lit-html or any other library using tagged literals) to see that.

> the answer is Babel

Which is only mentioned once the bullshit claims about tagged literals are refuted.

Babel is not exactly the answer, but as poor man’s macros it will do.

> A Babel plugin that compiles htm syntax to hyperscript, React.createElement, or just plain objects.

The difference is even more pronounced once you start typing your code.

TS/TSX = 100% typed

arbitrary template DSL = 0% typed

and now these string template based on interpolation = 5% typed: Only the dynamic values inside ${} expressions are "typed", but there are no coherence checks. DOM attribute names and values remain untyped

In the absence of any real advantage for string templates, why even bother?

Sure, stringly typed programming is sometimes a quick and dirty solution - and that's fine, even permanently, if you just don't want to invest much in whatever you're doing - which too, is fine.

But it's not a good thing. It's cheap and easy, which is sometimes something you need to settle for.

So does HTM we discuss here.

I quickly googled. sql-tag and node-sql-template-strings do a lot of string concatenation (well, of course, they have to create a SQL statement out of values passed in). sql-template parses and concatenates.

Because it's really basically all you can do, be cause tag`string` is just a function call tag("string"). There's no magic.

So I actaully like this project, thanks for this :-)

BTW: it's similar to lit-html, t7 and hyperx

Write a method to get the list id.

And FWIW I honestly think JSX is misstep.

When you write templates, you get more room for optimization. Glimmer engine compiles templates to binary bytecodes to bypass JavaScript parsing. Vue3 inlines component fragments as part of the compilation step.

Glimmer compiles to bytecode, but I am not sure how that “bypass[es] JavaScript parsing” as the bytecode is evaluated by a runtime written in JS (which is obviously parsed) and that translates the bytecode into JS calls. Basically one type of parsing has been replaced with another, which is fine though not obviously faster.

Likewise, I don’t see the point with Vue since again vue templates are translated into JS calls.

Or you could just make JS calls, like React does, no runtime translation required.

It’s not obviously faster, but it’s been benchmarked to be faster. https://youtu.be/nXCSloXZ-wc

You can skip to 29:34 for the performance demo.

What if I make it my special js "syntax extension"?

Both intellij and emacs do all of these things for Vue code. That seems to cover >90% of developers' tooling needs.

Also, code itself is a string. Code is data.

For example, in most threads about Vue on Reddit, the fact that you can just add Vue as a script tag and start working with it is it's most frequently cited advantage.

A small app, especially for most newbies just starting out, doesn't need webpack. But obviously they didn't read the docs and didn't even try the same with React. They just went straight for webpack, even though they shouldn't have. Not to mention CRA exists.

Same with immutable and saga. Their benefits are apparent in much bigger applications, and even then there are arguably simpler and better tools like Immer, update-immutable, redux-thunk, redux-promise-middleware or even rolling out your own middleware.

*edit: clarity