Origins of JSX and Why It Exists | Hacker News Reader

Origins of JSX and Why It Exists

dodov.dev

32 pointsredbell13 comments

No mention of E4X? https://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-part...

This article feels rather incomplete if there's zero mention of XHP: https://pusher.com/blog/the-evolution-of-react/

Because it's not about React (or about XML, looking at the sibling reference to E4X not being mentioned). It's about JSX. Just like your article doesn't mention JSX, and the sibling article on E4X calls out all the ways JSX fundamentally diverges from E4X, and so they "feel rather incomplete" in the context of comments on a post about the origins of JSX as explored through making a parser for JSX.

The JSX syntax was inspired from work on XHP, not E4X.

Seems strange to focus on E4X when discussing the origins vs the actual origin.

Just because E4X is somewhat similar doesn't make it the origin.

JSX exists because Javascript doesn't have macros. But Javascript has some popular code-generating transpilers for it, and those are where the community can inject new syntax without having to have it EcmaScript and adopted by implementations of JS engines in browsers and elsewhere.

I'm surprised that TC39 hasn't adopted JSX into ECMAScript. It wouldn't need to be React, but just the syntax. It could even bypass React.createElement and "output" (execute as) document.createElement (with attribute properties and children) for you.

I wish this was out many years ago. Would have saved me a lot of time trying to understand what the new syntax was and why it was in syntactically valid.

It still doesn’t go over why the greater than and less than signs somehow still transform into a syntactically valid JS especially when none of the jsx is in quotes.

The new syntax isn't syntactically valid Javascript. It's valid syntax inside a transpiler language like Babel.

It doesn't have to be in quotes because the tool, like Babel, has tokenization and parsing rules for it which disambiguate it somehow. It basically is a kind of quote. Or, well quasiquote. Just like " introduces a textual quote, a token sequence like <div> introduces a HTML quasiquote.

You can transform a language into JS that doesn't look like JS in any regard. So of course you can transform one that looks like JS, but does weird things that would be syntax errors in JS.

I think, it's a bit difficult to name a particular origin like HyperScript. The idea has been around for a long time. It's actually close to the core of what JS is all about. I personally remember writing a small library for generating (reactive) page UI from hierarchical object definitions in a 2007 project, and I was certainly not the first to so. I wouldn't have thought so for a moment. I did so in the 1990s using document.write() and even then I wouldn't have thought of claiming the idea.

What if you just set innerHTML to a quoted HTML string then the syntax colorizer would color it for you? Would that settle most of what you were doing transpiling for? Or just put the tags and attributes in JSON and the content in quotes? Universal and guaranteed to work without proprietary superlanguages.

I'm not a frontend engineer so I might be misunderstanding, but I thought react was creating representations of dom elements in the render function so that it only needs to apply diffs to the actual dom to keep the browser from eating cpu

But the browser could be doing that itself.

Check out what Lit is doing with tagged template literals.

Reply on news.ycombinator.com