Why was E4X deprecated??

I have questions
1

I was just going through old MDN archives and found this; the E4X - ECMAScript for XML;
The syntax:

<script type="text/javascript;e4x=1">
var person = <person>
  <name> Bob Smith </name>
  <likes>
    <os> Linux </os>
    <browser> Firefox </browser>
    <language> JavaScript </language>
    <language> Python </language>
  </likes>
</person>;

alert(person.name); // Bob Smith
alert(person['name']); // Bob Smith
alert(person.likes.browser); // Firefox
alert(person['likes'].browser); // Firefox
</script>

Looks peculiar, dugh!! it's native JSX. I want to know why in the hell such a thing was depricated!:rage::triumph:

2

No, it more closely aligns with JSON than JSX, if you read the implied semantics closely enough. Equivalent code would look closer to this:

var person = {
  name: "Bob Smith",
  likes: {
    os: "Linux",
    browser: "Firefox",
    language: ["JavaScript", "Python"],
  },
};

alert(person.name); // Bob Smith
alert(person['name']); // Bob Smith
alert(person.likes.browser); // Firefox
alert(person['likes'].browser); // Firefox

Conversely, JSX is a language extension almost always remapped to something considerably more complicated.

Edit: I might be wrong on the person.likes.language bit, but I haven't actually used E4X. Also, of course, as you can see from my username, I'm very much not a TC39 member, and so I'm not really the authoritative source here.

3

Sadly you're wrong about it because that example was taken from MDN
It directly maps to an XML object; The syntax above is just a syntactic sugar for new XML("<person>..."); Just like JSX maps to a tree of Objects.
It was designed as an alternative to the tedious and expensive XML DOM manipulation.
The question still remains unanswered!!:cry:

4

Just to reiterate:

I'm open to being wrong, and just throwing stuff at the wall. But IIUC it's the simpler nature of JSON that effectively destroyed E4X (it wasn't designed to work with the live DOM for one, sharply hampering its broader utility).

5

I would agree that it aligns more with the JSON example, not JSX. JSX usually maps to function calls, not structured data like JSON/E4X.

We supported E4X in ActionScript 3 (via Tamarin), but removed it in ActionScript 4, largely due to performance concerns. The extra parsing overhead wasn't worth the whatever benefit it may have provided, especially when there was a perfectly usable alternative going through the DOM API. Plus XML as a format was losing popularity largely due to JSON.

6

Guys this doesn't have anything to do with JSON; why bother to mention it here? It honestly feels
to me like saying: "why use HTML when you can write it in JSON and convert it into DOM"; Nobody does that right; This question was all about ECMAScript for XML (E4X); i.e, the use of ECMAScript alongside the web standard XML. And the official word for dropping it. I just wanted to know what was wrong with it after it got implemented in SpiderMonkey why other browser vendors didn't endorse it.
Please don't spam with invalid answers that lead the discussion astray from the main topic.

7

JSX maps to function calls, but don't those function calls just produce a chunk of structured data? Sure, that piece of data is meant to be consumed by specific libraries, not userland code, but I would think React could have been implemented to use this E4X instead of JSX.

With that said, from the examples I've seen, I've never seen the ability to interpolate data into the XML structure (a big need for React programmers). There's also this snippet of code on wikipedia that's comes without any explanation, but from the looks of it, E4X is adding a whole bunch of other syntax features besides XML in Javascript.

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"/>
  </sales>;

alert( sales.item.(@type == "carrot").@quantity );
alert( sales.@vendor );
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;

It looks like the "@" is used to refer to properties, and .(@type == "oranges") is some sort of query syntax to find a specific element. I'm not sure how this sales data is structured under the hood, but for all I know, these specific features turn E4X into a superset of Javascript that's incompatable with vanilla Javascript - i.e. maybe you can't refer to other Javascript libraries from this one, because of these underlying differences. If that's really the case, then that's a huge issue with this E4X thing.

I honestly have no idea, I'm just trying to speculate on different possible reasons why it didn't receive the same kind of popularity as JSX.

8

Thanks for the info!
Trying to be a superset of JavaScript! I think that was a nail in the coffin for E4X. But it was introduced way back in 2004 when ECMAScript was very young. The new syntax was very alien(but revolutionary) to JavaScript; Like the for..each. Those funky syntaxes couldn't get through standardisation and eventually caused a huge gap between E4X & ECMAScript.
But I think it's kind of cool actually ;)
I also think that the XML standard later went with XSL, XQuery, XPath, XLink, XBase,..etc instead of creating an abomination of XML & JS.
Any way these are just speculations and If anyone finds something else, please let me know.
I really wish E4X to be reestablished.:cry:

9

The following blog post from one of the JSX designers may interest you:

https://blog.vjeux.com/2013/javascript/jsx-e4x-the-good-parts.html

3 Likes
10

Thank you very much! That explains a lot!