Mozilla Xulrunner and Rhino (a JavaScript interpreter implemented in Java) used to support E4X: ECMAScript for XML, the ISO/IEC standard 22537:2006, and it was removed in 2014.
>ECMAScript for XML (E4X) is the standard ISO/IEC 22537:2006 programming language extension that adds native XML support to ECMAScript (which includes ActionScript, JavaScript, and JScript). The goal is to provide an alternative to DOM interfaces that uses a simpler syntax for accessing XML documents. It also offers a new way of making XML visible. Before the release of E4X, XML was always accessed at an object level. E4X instead treats XML as a primitive (like characters, integers, and booleans). This implies faster access, better support, and acceptance as a building block (data structure) of a program.
>E4X is standardized by Ecma International in the ECMA-357 standard. The first edition was published in June 2004, the second edition in December 2005.
>The E4X standard was deprecated by the Mozilla Foundation in 2014.
>"use strict" is currently our one real opt-in boundary for simplifying the language and reducing threats by dropping legacy complexity that is generally no longer needed. As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. Until we encountered this issues, it looked like SES could bring ocap security to ES5.1 without doing an accurate lex or parse. With this restriction, we could regain this economy.
>Besides, no one wants to upgrade the E4X semantics to be compatible with ES5 or ES.next, so this seems a good time to impose this opt-in restriction.
>Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute!
>So essentially, it's a great way for Facebook to push React.js without making React.js a standard.
>It was deprecated and removed from the only browser that ever supported it because it was a poorly implemented language feature that was causing all sorts of problems.
>As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. — Mark S. Miller
>The only way for it to come back would be via a new edition of ECMA-357, which Adobe and Mozilla were going to work on. Until then, it's out. — Brendan Eich
>The idea behind it wasn't bad, but the way it was integrated into the language was. SpiderMonkey was the only JS engine that ever implemented it, and there were endless problems caused by that and severe complications of the engine's implementation required for this support. — Till Schneidereit
https://en.wikipedia.org/wiki/ECMAScript_for_XML
>ECMAScript for XML (E4X) is the standard ISO/IEC 22537:2006 programming language extension that adds native XML support to ECMAScript (which includes ActionScript, JavaScript, and JScript). The goal is to provide an alternative to DOM interfaces that uses a simpler syntax for accessing XML documents. It also offers a new way of making XML visible. Before the release of E4X, XML was always accessed at an object level. E4X instead treats XML as a primitive (like characters, integers, and booleans). This implies faster access, better support, and acceptance as a building block (data structure) of a program.
>E4X is standardized by Ecma International in the ECMA-357 standard. The first edition was published in June 2004, the second edition in December 2005.
>The E4X standard was deprecated by the Mozilla Foundation in 2014.
https://bugzilla.mozilla.org/show_bug.cgi?id=695577#c1
>Mark S. Miller, 10 years ago
>"use strict" is currently our one real opt-in boundary for simplifying the language and reducing threats by dropping legacy complexity that is generally no longer needed. As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. Until we encountered this issues, it looked like SES could bring ocap security to ES5.1 without doing an accurate lex or parse. With this restriction, we could regain this economy.
>Besides, no one wants to upgrade the E4X semantics to be compatible with ES5 or ES.next, so this seems a good time to impose this opt-in restriction.
https://news.ycombinator.com/item?id=8266648
>bastawhiz on Sept 4, 2014 | parent | context | un‑favorite | on: JSX: XML-like syntax extension to ECMAScript – Dra...
>So..uh...this was a thing. And nobody wanted it. So it was deprecated and killed. See the "Prior Art" section at the bottom of the page.
http://en.wikipedia.org/wiki/ECMAScript_for_XML
>Brendan Eich was quoted as saying something along the lines of "E4X is crazyland". Parsing it is hard as hell to do right. Think of all the tooling that's out there for JavaScript right now that will either a.) not support JSX code or b.) bloat up beyond belief as it takes into account the suddenly absurd requirements necessary to deal with a similar-but-not-quite-XML-or-even-HTML-for-that-matter syntax. Oh, you want to lint that JavaScript? Bless your heart! You want to add syntax highlighting? Love will find a way. You want to use other static analysis tools, sweet.js macros, or anything else non-trivial? How cute!
>So essentially, it's a great way for Facebook to push React.js without making React.js a standard.
https://stackoverflow.com/questions/33642820/why-was-e4x-dep...
>It was deprecated and removed from the only browser that ever supported it because it was a poorly implemented language feature that was causing all sorts of problems.
>As Brendan said somewhere "E4X is crazyland", and FF's implementation of E4X deviates from the spec in ways that are not written down anywhere. — Mark S. Miller
>The only way for it to come back would be via a new edition of ECMA-357, which Adobe and Mozilla were going to work on. Until then, it's out. — Brendan Eich
>The idea behind it wasn't bad, but the way it was integrated into the language was. SpiderMonkey was the only JS engine that ever implemented it, and there were endless problems caused by that and severe complications of the engine's implementation required for this support. — Till Schneidereit