1. 16

  2. 23

    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

    1. 5

      This is similar to how I’ve seen it done in Haskell with blaze-html: https://jaspervdj.be/blaze/tutorial.html

      It’s regular functions that return something something html monad something. Integrates very nicely with the rest of the language without looking cumbersome. And you get powerful ways to manipulate the tree for free!

    2. 15

      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"/>
      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;
      1. 2

        If Apple and (mostly) Microsoft hadn’t killed ES4 back in the 2000s, only to re-invent it and call it TypeScript 10 years layer, we’d all be a lot better off by now.

        1. 1

          Ah, good old E4X.

          We had JavaScript style sheets for a while in the old days, too, but they didn’t catch on.

          1. 1

            Interesting, surprised I’ve never seen this!

            As someone that wasn’t a professional dev during peak XML, this provokes a similar response to seeing eg. XPath in the wild - “wow, this looks super powerful but maybe a tad too baroque”

            1. 3

              For me, E4X isn’t peak XML. It’s the period after the peak where we realised that SOAP was too complex and we were trying to transition away from it to something that was more web-friendly, but had to rely on XML representations.

              There were definitely people using the full gamut of XML, including XPath, but for many developers the trend was towards SOAP because automatic serialization/deserialization machinery existed and the developer requirement was getting smallish amounts of data from here to there right now.

              Developers using .NET could just point at a WSDL file and interact with a service without know anything about the underlying mechanisms. This promised interoperability with Java, but was excruciatingly painful because the tools were close, but not close enough, in terms of compliance. Over time, people forgot the full breadth of what XML could do since you weren’t really working with XML at the level where XPath could be used.

              XMLSpy and other specialist XML tools appeared near the end of the 20th century, but usage dropped, except for niches like publishing and special processes like FDA submissions. Web services took over and morphed into classic SOA. The originators of these were pushing the WS-* standards (that were never intended for human consumption) while implementers and the internet envisioned a simpler model building on REST and JSON. Some people couldn’t get to JSON without an intermediate step of XML, hence E4X.

              1. 1

                For me, E4X isn’t peak XML. It’s the period after the peak where we realised that SOAP was too complex and we were trying to transition away from it to something that was more web-friendly, but had to rely on XML representations.

                Interesting prospective. For me E4X is part of that period where XHTML was starting to be a thing (a desirable thing) but was killed by draconian error handling.

                All that aside, lest not forget that E4X is also a legacy of ActionScript, the JavaScript-like language that is (was) used to write Flash programs. The ability to seamlessly interact with HTTP endpoints that returned XML data made Flash (at least in the eyes of Adobe) a viable platform for business environments and not just for games.

                1. 2

                  XHTML arrived at the peak, but it took a long time before people really understood what it meant and tried to apply it 2002-2003 (approx.) It was desirable in a number of ways, but the W3C mishandled the transition because they were staunch XML fans, and the implementers where relatively unresponsive to the market. The WHATWG appeared on the scene in 2004 and the rest is history.

                  E4X grew from the identification of some of the better perspectives at the time rather than being an outgrowth from the XML juggernaut. In those times Flash might still have been considered an option for the next era of the Web (aka. Web 2.0.) Very quickly you’d see Adobe identify that something like Flex was needed, only for Flash to collapse because as a runtime there was never any real outreach/integration with the web. While I don’t think the implementation of Flash would have succeeded for much longer than it has done, I think Adobe made many strategic failures which resulted in a shorter fight. The death knell was Apple, but people on the other side weren’t even going to advocate for a closed platform like Flash.

              2. 1

                XPath itself I don’t think is too baroque. At least, if you have to deal with XML, it’s very handy to have on hand, provided that XML document isn’t huge.

                XSLT would be my point of “eh, this feels like too much”. But Xpath on its own can be very handy.

            2. 8

              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.

              1. 2

                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.

                1. 2

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


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

                  1. 2

                    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);
                      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)

                    1. 2

                      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.

                      1. 1

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

                        1. 1

                          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.