What if we'd had better HTML-in-JS syntax all along? • Hacker News Board

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

#51

Post by ChristianBundy » Mon, May 11, 2020, 5:24 PM UTC

applecrazy wrote: post #17

glutamate wrote: post #8

Something close to this is possible already in JS, I'm working on a library for generating HTML in node, heavily inspired by Haskell's blaze and lucid. Example code: div( { class: "table-responsive" }, table( { class: ["table table-sm", opts.onRowSelect && "table-hover"] }, thead(tr(hdrs.map(hdr => headerCell(hdr)))), tbody( vs.map(v => tr( mkClickHandler(opts, v), hdrs.map(hdr => td(typeof hdr.key === "string" ? tex…

This actually already exists as a library. This type of syntax is called Hyperscript[1], and it's existed (at least) since 2012. [1]: https://github.com/hyperhype/hyperscript (Although this library does not look maintained anymore)

Yup, it's almost exactly the same syntax if you use Hyperaxe (built on top of HyperScript): https://github.com/ungoldman/hyperaxe/

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

#52

Post by tannhaeuser » Mon, May 11, 2020, 5:24 PM UTC

eh "you must know the rules to break them" I guess.

It's not like JavaScript, the DOM API, and HTML/SGML/XML don't have a very long history of coexistence, including a native syntax for XML-in-JavaScript (E4X) that was however endorsed by Mozilla only, and since abandoned. JSX stands for "JavaScript XML" btw.

> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascript.

I'd have to say this theory is really poorly recherched, then :)

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

#53

Post by thramp » Mon, May 11, 2020, 5:28 PM UTC

I like the retrospective of this post! The "what ifs" that could've been taken are fun to think about.

I think I might take a step further than this post does—I think some sort of Racket/Rust-style macro system should be implemented in JS, which means that that means something like JSX could be implemented as a library. There's already been _some_ work on this in JavaScript (SweetJS https://www.sweetjs.org/), but making it first-class would be a big win, IMO.

I know that there are common objects to macros as being too complicated/having poor misuse resistence, but it can (and has!) been implemented and used pretty judiciously all the non-C/C++ languages I've used.

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

#54

Post by insin » Mon, May 11, 2020, 5:32 PM UTC

andrewla wrote: post #39

An interesting native approach; there have been library-based approaches to this that date back a while. Laconic ( https://github.com/joestelmach/laconic ) is one of the oldest that I'm aware of, and suffers from some jsquery-ness: $.el.div({'class' : 'example'}, $.el.div('content')); Pithy ( https://github.com/caolan/pithy ) is another; uses function syntax to get the effect of the tag name. This was discussed previ…

How far back can we go? insin/DOMBuilder was initially based on a 2006 library of the same - but differently-cased - name by Dan Webb (https://www.webstandards.org/2006/04/13/dom-builder) and the earliest variant I can recall was Mochikit.DOM (https://mochi.github.io/mochikit/doc/html/MochiKit/DOM.html)

By the end of DOMBuilder's life it could generate DOM or HTML from the same code and I'd tried unsuccessfully to implement a way to rehydrate HTML by hooking up events using the same code on the client.

Not long after, I happened to be in the audience for Pete Hunt's React: Rethinking best practices talk at JSConf EU (https://www.youtube.com/watch?v=x7cQ3mrcKaY) and I was totally floored; they'd solved everything I had been trying to do with UI as code and much more, and JSX was the icing on the cake, as using nested object/array syntax has always been rife with comma-management hell when you're maintaining UI code.

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

#55

Post by masswerk » Mon, May 11, 2020, 5:32 PM UTC

irrational wrote: post #43

masswerk wrote: post #40

Earlier quoted context omitted.

So, if initially there were no Array nor Object constructors (there were arrays and objects, but only prepopulated ones, representing anchors, forms, etc, found in the document), how were arrays done in a script? function MyArray() { this.length = 0; } function arrayPush( value ) { return this[this.length++] = value; } function arrayPop() { return this[--this.length]; } MyArray.prototype.push = arrayPush; MyArray.pro…

I have been using JS since the mid 90s, but I don't recall needing arrays or objects back then. Frankly we weren't trying to build applications and any real programming work was done on the back end (remember that xmlHttpRequest wouldn't exist for years to come, so any changes to the page were made by going to a new page which would require a round trip to the server, so the server could do anything it needed to do t…

There were a few interactive scripts, usually interacting with a form as an UI. The first JS book, I knew, was the "Official Netscape JavaScript Book" (1996), which was based on Netscape 3 beta. This one featured a pretty complex area code application as a demonstration object and things like order forms. I started pretty much with the introduction of NS3, when NS2 and JavaScript1.0 were still the common platform.

Fun fact, for a year or so, you'd frequently include a script twice, once in a simpler form for NS2 and similar, and once targeting Netscape 3 (and, later, IE3) using a `` tag, which was ignored by the earlier browsers, implementing a more complex version of the same functions. (This scheme was used again, when DHTML became a thing, this time using the `language="javascript1.2"` attribute. However, this switch came with a few caveats, since it also activated some rather odd behavior, like negative zero as a numeric value, which could break a few things.)

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

#56

Post by bwindels » Mon, May 11, 2020, 5:34 PM UTC

glutamate wrote: post #8

Something close to this is possible already in JS, I'm working on a library for generating HTML in node, heavily inspired by Haskell's blaze and lucid. Example code: div( { class: "table-responsive" }, table( { class: ["table table-sm", opts.onRowSelect && "table-hover"] }, thead(tr(hdrs.map(hdr => headerCell(hdr)))), tbody( vs.map(v => tr( mkClickHandler(opts, v), hdrs.map(hdr => td(typeof hdr.key === "string" ? tex…

I went with this syntax as well for a project [1], being just a simple wrapper on top off createElement, with functions as children/attributes being used as one-way bindings.

1: https://github.com/bwindels/brawl-chat/blob/master/src/ui/we...

Works very well, and don't need to transpile.

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

#57

Post by TedDoesntTalk » Mon, May 11, 2020, 5:35 PM UTC

masswerk wrote: post #20

> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascript. It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). The genuine way of generating HTML in JS were various methods of `String.prototype` for generating HTML form…

There was also the the idea that JavaScript was just one way of scripting the page. VisualBasic Script (VBScript) had momentum in IE releases. The general idea was that the user-agent was going to be able to parse multiple scripting languages, the list of which would probably grow as time went on. Think native TypeScript parsing in a browser today!

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

#58

Post by kroltan » Mon, May 11, 2020, 5:38 PM UTC

kroltan wrote: post #50

This reminds me of a very cool property of the Lua language that allows for very neat "syntax extensions", and reminds of functional languages too: If you have two expressions adjacent to eachother, it evaluates to calling the left-hand side with the right-hand side as a parameter. At its simplest: function foo(text) print("Foo:", text) end foo "bar" But you could implement a JSX-lite in it: function Div(props) retur…

In fact, since objects and arrays are one and the same in Lua, one can even do away with the nested calls, which also simplifies things visually:

  Div {
    id = "outer",
    Div {id = "innerA"},
    Div {
      id = "innerB",
      Div {}
    }
  }

This works because when you omit the key (id=) of a table item in Lua, it is assumed to have a incrementing numeric key.

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

#59

Post by brlewis » Mon, May 11, 2020, 5:40 PM UTC

jannes wrote: post #29

brlewis wrote: post #11

Earlier quoted context omitted.

I'm sure it was one of the inspirations for JSX -- https://facebook.github.io/jsx/#prior-art

The creators of JSX (Facebook employees obviously) once said in a talk that their biggest inspiration for JSX was server-side PHP code which supports being interspersed with HTML.

> PHP code which supports being interspersed with HTML

You're one of a large number of people who say this, but it is false. PHP intersperses a programming language with static strings. Those static strings frequently adhere to HTML syntax, but that's aside from PHP.

What is HTML? It's not random strings; it's a syntax. JSX is much closer to interspersing HTML with a Turing-complete programming language than PHP ever was, because frequently the mistakes that make JSX not compile are the same mistakes that make HTML invalid.

Admittedly I haven't used PHP since 2012, but at least back then you could make all the HTML mistakes you wanted, and PHP wouldn't bat an eyelash.

EDIT: Here's someone else's comment making the same point in different words. If my comment doesn't make sense to you try this one: https://news.ycombinator.com/item?id=23144268

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

#60

Post by jdmichal » Mon, May 11, 2020, 5:41 PM UTC

I have a hypothesis about a different way to organize responsibilities within webpages. I think the split of "content" to HTML and "presentation" to CSS was a mistake. To me, those are both describing content. That is, the author's intent to emphasize a particular part of text, whether via tags or CSS, is part of the content.
I think there was a missed opportunity to instead split page layout into its own technology. This would allow for complex layouts, up to and including constraint solving. The browser would calculate the layout, then load each of the content segments into the calculated layout. I imagine it something like ASP.NET master pages, where you can define a page structure with fixed placeholders that can be replaced with other content. Except, of course, this could only specify where on the screen a particular panel exists.
HTML and CSS could then live together in a single technology. I think you could even go a step farther and combine content, presentation, and scripting all into a single technology. Some operators within that technology would have the side-effect of manifesting things on the user's screen. Something based on s-expressions would probably work very well, with its ability to blend code and data into a single format.
I imagine I could probably do some kind of mock-up using iframes to at least demo the idea...

Permalink View on HN Reply on HN Top