What if we'd had better HTML-in-JS syntax all along?

Example code:

    div ({ class: "form-group" },   
      label ({ for: "exampleFormControlSelect1" }, "Example select"),  
      select ({ class: "form-control", id: "exampleFormControlSelect1" },   
        option ("1"),  
        option ("2"),  
        option ("3"),  
        option ("4"),  
        option ("5")  
      )  
    )  

The arguments against this approach usually boil down to the mistaken notion that "you're not separating concerns". The response is: separation of language != separation of concerns. No matter what you should still strive to reduce cyclomatic complexity. So you're still separating model, view, themes etc. And you're doing so using abstractions within the language, rather than relying on language and file boundaries. Notably in the reverse case, when you have unavoidable links between these layers (since no useful abstraction isn't leaky), the benefits of expressing everything in one language are considerable (e.g. when refactoring).

First, the word "update" doesn't appear in the article at all, and efficient and stable updates are the primary reason that client-side template systems are much more complex than their server-side string-concatenation counterparts. Updates are the main reason why you want to treat HTML as structured, because you can't map data changes to DOM changes without some knowledge of the underlying DOM structure.

Then there's no mention of E4X (or the lesser-known E4H by Ian Hixie). We've had a proposed syntax, so what went wrong and why not revive it?

Again, updates. Creating the initial DOM state isn't that bad. E4X is an incremental improvement over innerHTML. What matters is updates, and the main difference between JSX and E4X is that E4X created _new_ DOM for every invocation, while JSX is typically used to create a new _description_ of the DOM, which is applied to existing DOM to update it.

Any proposal for adding HTML syntax to JS is completely jumping the gun if it doesn't address this point. The syntax matters way less than the semantics on what such markup expressions actually evaluate to and how that result is used to update the DOM.

THen, statements like this:

> This is rubbish for obvious reasons - composing the strings is bug-prone, no typing/linting etc etc. We then have to turn them into elements with the less than elegant:

don't hold up.

lit-html[1] (I'm a maintainer) works very much like this and it excels at composition and turning markup into structured data. The complaint is very much in the vein of complaining about embedding a language into strings and saying that just programming with strings. Well, basically every programming language is just strings, with a defined grammar and tools that enforce and extract the structure. This is no different with embeddings, and JS tagged template literals were specifically designed to make embedded languages more useful.

lit-html uses the browsers HTML parser to parse the strings, enforcing that they're well-formed. It creates HTML elements that are efficiently cloned for new DOM, and it remembers where the dynamic expressions are in the DOM to efficiently update it on repeated renders. It interpolates data post-clone, so it's robust against XSS. It has a plug-ins for VS Code, TypeScript, eslint, and more, for type-checking, highlighting code-completion, and linting of templates.

Which is just to say that string-based templates are a great option that _do_ allow for fast updates, type-checking, composition, and structure, with standard syntax available today.

Finally... there are a couple of recent proposals for JavaScript that affect this area. The records and tuples proposal might make it very efficient to describe DOM in object notation. The block parameters proposal[3], though probably defunct now, proposed adding something akin to Kotlin builders, which would have allowed for the attribute/children structure we need for markup.

[1]: https://lit-html.polymer-project.org/ [2]: https://github.com/tc39/proposal-record-tuple [3]: https://github.com/samuelgoto/proposal-block-params

  function MyArray() {
     this.length = 0;
  }

  function arrayPush( value ) {
     return this[this.length++] = value;
  }

  function arrayPop() {
     return this[--this.length];
  }

  MyArray.prototype.push = arrayPush;
  MyArray.prototype.pop = arrayPop;

  var a = new MyArray();
  a.push("frist");
  // no console available, debug using alert()
  alert( a[0] );     // "frist"
  alert( a.length ); // 1
  alert( a.pop() );  // "frist"
  alert( a.length ); // 0