In the ClojureScript world, we do have a syntax for HTML-in-JS that we prefer. It’s called s-expressions. Or, sometimes more precisely, Hiccup syntax, named after the library that pioneered it.

Sample code to illustrate how we completely sidestep the JSX debacle: https://github.com/nathell/wordchampions/blob/master/src/cljs/gridlock/views.cljs#L162

We had a syntax for HTML-in-JS in the early 2000s. Standardized as E4X in ECMA-357 but never properly implemented by the most popular browsers and then removed. https://developer.mozilla.org/en-US/docs/Archive/Web/E4X.

Example from https://en.wikipedia.org/wiki/ECMAScript_for_XML:

var sales = <sales vendor="John">
    <item type="peas" price="4" quantity="6"/>
    <item type="carrot" price="3" quantity="10"/>
    <item type="chips" price="5" quantity="3"/>
  </sales>;

for each( var price in sales..@price ) {
  alert( price );
}
delete sales.item[0];
sales.item += <item type="oranges" price="4"/>;
sales.item.(@type == "oranges").@quantity = 4;

From this point of view I suppose the original sin of HTML was to base it on SGML. That made it complicated and difficult to embed (Scala tried to embed XML literals but the results were very mixed last time I used it). From that point on things got very hard and of course escaping string interpolation into HTML is still something that people get wrong.

If HTML had been simpler perhaps Javascript could have been a superset of HTML, which would really have been interesting. There’s something to be said for having a grammar that is simple enough to embed, particularly for presentation languages that often get embedded in some bigger piece of code.

Interesting article!

The article ponders the hypothetical implications of such a design, and states “There would be no distinction between JSON and html. (What would have been the downstream consequences to API design?)”

I think this conflates JSON and JavaScript. This would have no impact on JSON as I see it. And even if you had extended JSON to support this, I don’t think it would have changed API design much at all. API design is really about structured, semantic data. Since HTML is so presentation-centric I doubt it would have much impact on API design. There is a reason almost all serialization formats are effectively equivalent to one another.

In fact, if JSON had such a strong coupling to HTML it might have led to JSON not being widespread for APIs, and a new serialization format winning instead. That might in turn have reduced the popularity of JavaScript as a language.

There actually used to be a library for literally embedding HTML fragments into Haskell but the technique I think fell out of favour:

http://happstack.com/docs/crashcourse/Templates.html

I know Scala has XML embedding built into their language, but also don’t know how actively that is still used.

I liked the examples in this article, and agree with its assessment. I wrote a bit of code that gets at the “what might have been” example:

function convertValue(value) {
  if (value instanceof HTMLElement) {
    return value;
  }
  return document.createTextNode(value.toString());
}

function makeNode(tag, children) {
  let node = document.createElement(tag);
  children.map(convertValue).map(node.appendChild.bind(node));
  return node;
}

function H(tag, attrs = {}) {
  return (...children) => {
    let node = makeNode(tag, children)
    Object.keys(attrs).map(key => node.setAttribute(key, attrs[key]));
    return node;
  }
}

// example usage

let f = () => alert("foo");
let button = H("button", {class: "foo, bar", data: "1", onclick: "f()"})
document.body.appendChild(button("Hello ", H("em")("there")))

It works pretty nicely! (though solutions like lit-html would be far more robust)

I was just working on another project that needed to build a few lines worth of HTML in JS to add to an existing webpage. I’ve built a few similar things before, and never really liked any of the solutions. This time, I decided the least-worst was to just write them HTML directly to a string and insert into the doc using insertAdjacentHTML. The code was agreeably short and simple, but it felt a little ugly to then need to do a bunch of querySelector calls to get the DOM elements that I had just created by IDs.

In the past, I’ve tried creating elements using DOM JS calls, but that’s an awful lot of boilerplate per element. Using jQuery doesn’t seem to be much less ugly. The use cases I’ve worked with have been simple enough that it seems a bit much to pull in a major JS view library to make the code slightly simpler.

This idea is quite similar to what was recently added to Swift to support their totally-not-react-alike SwiftUI system.

Loved this article! I’ve had the exact same thought, HTML really is just structured data, no good reason not to use something like JSON.