JSX: the new E4X?

programming web dev
1

I said it before, and I’ll say it again: I like E4X. I was sad when it was abandoned in JavaScript (I believe Mozilla was the only browser that implemented it) and ActionScript 4.

But now there’s a new playa in town, JSX, similar to E4X in many ways, but also a little different. It has been picking up steam and even gotten the interest of the TypeScript team.

This bothers me a bit because I feel E4X should have gotten more love than it did. Was it ahead of its time? Was it the implementation too heavy?

2

Mozilla was the only big vendor… but they added it to Rhino in addition to SpiderMonkey / FF.

Re: AS4:

Without namespaces, E4X cannot stand on its own, so we remove it. Consequently, we also remove the
associated XML, XMLList, and QNames classes. Removing E4X also means removing a lot of cruft from the syntax (see section 2.15).

That was Bernd/Avik’s rationale from the AS4 WP. But Bernd came from Oracle Java land, so he was probably never going to be on board with something far from being JVM-like.

Ironically-ish, ES6 has Symbols, which the committee is actually recommending people use as crappy-looking namespaces:

class ThingThatCanBeIterated {
     [Symbol.iterator]() {
         return iterator
     }
 }

…and they’re already running into issues similar to ApplicationDomains in AS3 or ClassLoaders in Java, due to the “symbol registry” being hard to share between windows/tabs/worker threads, etc. :evil:

IMO, E4X just came just late enough to the XML party that it still specified a bunch of XML-cruft that people ended up wanting to get rid of in HTML5, like schemas and XML namespaces. JSX keeps the literal syntax and <a href={ n + 1 } /> interpolation, mostly… but not much else.

E4X also appeared in the era when Microsoft wasn’t being cooperative with ECMA, and E4X is ECMA-347… so it was sort of doomed by association.

3

I remember having (a) conversation(s) with Bernd about E4X. I had previous battles internally trying to prove its worth, but I could tell from my talks with him it wasn’t going to happen in AS4, especially with their lean approach. I remember the use of “<” in syntax being especially disruptive, notably with respect to what was being used for typed arrays. That was the argument that stuck out to me the most.

4

I liked E4X. That is all.

5

Here we go again: https://facebook.github.io/react/blog/2014/07/17/react-v0.11.html#jsx-namespacing

Another feature request we’ve been hearing for a long time is the ability to have namespaces in JSX. Given that JSX is just JavaScript, we didn’t want to use XML namespacing.

<UI.Layout><UI.Button /><UI.Label>text</UI.Label></UI.Layout>

Hmm, swapping the : with .. Reminds me of Blue Steel.

Also: https://facebook.github.io/react/docs/create-fragment.html

Note:
In the future, createFragment may be replaced by an API such as

return (
   <div>
     <x:frag key="right">{this.props.rightChildren}</x:frag>,
     <x:frag key="left">{this.props.leftChildren}</x:frag>
   </div>
);

allowing you to assign keys directly in JSX without adding wrapper elements.

So they’re still using that syntax too, albeit for something else. :trout:

Edit: Meant to mention something about how this all resembles XSL, too.

6

eck, I hope not. I guess the “namespace” approach makes sense, given that it does correlate to JS objects. But then to do that with fragments feels awkward. I also don’t like:

Note also that we’re relying on the JavaScript engine preserving object enumeration order here, which is not guaranteed by the spec but is implemented by all major browsers and VMs for objects with non-numeric keys.

_From: https://facebook.github.io/react/docs/create-fragment.html_

AS broke this. I can’t help but think it could happen with JS too. [edit:] Who am I kidding. We never break the web! … though this is funny: The ES2015 Nightmarefile - performance, web standards - Bocoup