Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

leontrolski.github.io

Post reply on HN
Print view View original

61–70 of 170 posts

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

#61

Post by lhorie »

Suspiciously absent, but right up this alley is hyperscript:

    h('div', {id: 'foo', onclick: f}, 'Hello')
The benefits of hyperscript over `div()` is that in JS, variable names must be imported by name (so `import {div, ul, li, ...}` gets annoying fast). Also, React is super popular, and hyperscript interoperates nicely with JSX.

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

#62

Post by haburka »

The solution is not another templating language. Html is complex and many templating languages exist because it’s hard to compress and everything thinks it’s not that hard. There are so many things you need to do in HTML to make a modern web page that this suggestion conveniently ignores. The web is complex because it has replaced native programs and it’s perfectly backwards compatible. Stop trying to make it look easy.

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

#64

Post by eyelidlessness »

52-6F-62 wrote: post #14
eyelidlessness wrote: post #7

Earlier quoted context omitted.

I mean, it kind of caught on. It's syntactically very close (if not identical) to JSX. It just caught on in a different form/technology than what was built into Gecko. I think if it had been introduced later, with the kinds of performance seen in VDOM implementations, it may have had a greater chance of becoming a web standard.

Ultimately what is in the way of it being implemented now or in the near future? Is there anything? I don't see why it couldn't just live beside the current Element API.

The standards bodies have historically tended to adopt lower level APIs over higher level abstractions. I think the likelihood of JSX or E4X or whatever, as such, making it through the standards process is fairly low.

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

#65

Post by neilv »

An early alternative would've been to use an integrated language for both HTML and JS features, like Curl, published in 1997:

https://en.wikipedia.org/wiki/Curl_(programming_language)

https://dl.acm.org/doi/10.1504/IJWET.2003.003259

https://groups.csail.mit.edu/cag/curl/wwwpaper.html

(Disclosure: I worked at the Curl commercial spinoff.)

Or, many Lisp people just used s-expression data for HTML, and Lisp for everything else. Here's a typical way I did, in 2000, in Scheme:

https://www.neilvandyke.org/racket/html-writing/

And a less-common later take on it, which used syntax extension rather than data:

https://www.neilvandyke.org/racket/html-template/

I actually pitched some Web ideas to Tim Berners-Lee around 2000, including Scheme for Web programming. But shortly after that, he promoted using Python for some Web stuff, because, IIRC, Python was inclusive, making Web programming accessible to more people. Which was understandable, and one of the ways many techies thought about the Internet, before there were career tracks, when the Internet was something we knew about and wanted to bring to the world. (In hindsight, I wish I'd then tried to write a very inclusive practical intro book/tutorial for Scheme at that early point, but I was preoccupied with other things.)

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

#66

Post by leovander »

db48x wrote: post #2

Don't forget E4X: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X_tut... It never really caught on.

We use it in healthcare, at least in NextGen Connect, formerly Mirth Connect[0]. It uses Rhino[1] as its scripting engine which still supports E4X.

[0] https://en.wikipedia.org/wiki/NextGen_Connect

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rh...

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

#67

Post by masswerk »

TedDoesntTalk wrote: post #57
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!

There were even things like ViolaWWW [0][1], using a HyperCard-like approach, which exposed all its objects (even a canvas for drawing) and methods in its own scripting language. This was probably the nearest thing to the Web, we know today, but also an absolute security nightmare.

[0] https://en.wikipedia.org/wiki/ViolaWWW [1] http://viola.org

Edit: The basic building blocks of ViolaWWW were horizontal and vertical layout panes, which behaved much like flex elements and allowed the implementation of all the common HTML tags. These were accessible to viola-scripts and could also be generated by a script. Moreover, ViolaWWW also featured stylesheets (in a maybe more declarative form than CSS).

Styles were also much like this, with multiple concurring standards. While MS IE featured CSS, Netscape used JavaScript styles. (However, Netscape soon adopted CSS syntax, but this remained a mere bridge to the original JS styles for all of the NS4.x life cycle.)

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

#68

Post by acdha »

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…

The Re:DOM library might be of interest — it's very similar to your syntax above and it also comes with a robust toolkit for handling updates without the overhead of a virtual DOM:

https://redom.js.org/#elements

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

#69

Post by rafd »

kgwxd wrote: post #18

I've never had a chance to use it in production but, ClojureScript with Reagent[1] and it's Hiccup-like[2] markup is bliss in this domain. [1] http://reagent-project.github.io/ [2] https://github.com/weavejester/hiccup

...and, there's nothing particularly preventing a similar approach in JS (keywords would need to be strings, and... data manipulation in JS is relatively a huge pain compared to Clojure)

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

#70

Post by coding123 »

I think my favorite thing about JSX specifically - is that the {} breakouts used in it, get all the same treatment from the JS/TS compiler as your Javascript/Typescript does. And all without changing HTML into a JSON or Yaml representation. It just works in VSCode. The number of years of HTML being an relative of the SGML/XML family (pedants calm here, you know what I mean) shouldn't be thrown away just because it's not immediately available in JS.

I think one thing I would love to see from JSX is for it to start growing outside of the React world. Vue seems to be trying. Until React came along, we really had no compile time checking on templating languages at all. I think the reason for that, is, in part, because the templating aspect was always thought of as "dirty" that you shouldn't mix JS and the view parts. I think React debunked that notion. I've never been as productive in creating UIs as I have when I'm working in React. And a lot of that is because I call my backend, I get a typed object back, I tell the UI to use {response.medication.firstName} and if we ever change the structure of medication? I get full help from the compiler that that view will no longer work... If you haven't used React you might not get the full power of that.

Even if I am a React fan, it doesn't mean I don't think other frameworks won't ever take over, but I think at this point, the one that may eventually eclipse React is probably going to have native JSX support.

Post reply on HN