E4X

E4X (ECMAScript for XML) was a set of extensions that made XML a native data type in JavaScript and the other ECMAScript languages. It was standardized by Ecma International as ECMA-357 in June 2004. With E4X a program could write XML directly in source code as a literal, walk it with the ordinary . operator, read attributes with @, search all descendants with .., and filter a list of elements with a predicate in parentheses. The aim was to let the millions of people who already knew JavaScript work with XML without learning the W3C DOM or XSLT.

For a few years E4X ran in Firefox, Mozilla’s Rhino engine and, most widely, Adobe’s ActionScript 3.0. It never reached Internet Explorer, Safari or Chrome. Firefox removed it in 2013, and both Ecma and ISO/IEC have since withdrawn the standard. It is a clear example of a well-designed feature that lost out, partly because the web moved from XML to JSON.

History & Origins

A BEA-led proposal (2002)

By the early 2000s XML was the standard format for web services, configuration files and document exchange. Programmers had two main ways to handle it: the W3C Document Object Model, a verbose tree API, or XSLT, a separate declarative language. BEA Systems, which sold the WebLogic application server and the WebLogic Workshop IDE for building web services, wanted something simpler for its customers.

The Brief History in the first edition of ECMA-357 records the start: “On 13 June 2002, a group of companies led by BEA Systems proposed a set of programming language extensions adding native XML support to ECMAScript (ECMA-262).” The ECMAScript group, Ecma TC39-TG1, “unanimously agreed to the proposal” and set up a subgroup, and development of the standard began on 8 August 2002.

The design and editing came largely from AgileDelta, a small company that says it “proposed the E4X initiative, led the development of the international E4X standard, authored the E4X specification and developed the first complete E4X implementation for our customer BEA Systems.” John Schneider, listed as “BEA/AgileDelta (Lead Editor)”, edited the specification. The supporting editors were Rok Yu of Microsoft and Jeff Dyer of Macromedia. The full contributor list covers most of the ECMAScript world at the time: Brendan Eich (Mozilla Foundation), Waldemar Horwat and Patrick Beard (AOL/Netscape), Gary Grossman (Macromedia), Peter Torr and Herman Venter (Microsoft), plus people from IBM, RIM, palmOne, Openwave, MITRE and the University of Washington.

Pre-standard: WebLogic Workshop

BEA shipped the idea before the standard was finished. The WebLogic Workshop 8.1 documentation describes “an extended version of the ECMAScript (also known as JavaScript) programming language with enhanced support for handling XML”, including “native support for XML as a type”. It documents the . and .. operators, @ for attributes, {} embedded expressions, filtering predicates and += insertion, all of which appear in E4X. The extensions were used in .jsx (“JavaScript with extensions”) files, called from XML Maps to reshape web-service messages. Some secondary sources date BEA’s first implementation to WebLogic Workshop 7.0; this page has not checked that version’s documentation.

Standardization (2004–2006)

The Ecma General Assembly adopted the first edition of ECMA-357 in June 2004, and a second edition followed in December 2005. ISO/IEC JTC 1/SC 22 then published it as ISO/IEC 22537:2006 on 13 February 2006. The specification was written as an extension to ECMAScript Edition 3, and the 2004 edition expected that it “will be integrated into future editions of ECMA-262”. That never happened.

Design Philosophy

The second edition of ECMA-357 lists six non-normative design principles:

The specification’s motivation section explains why the existing options fell short. DOM code “is more verbose and often obscures the developer’s intent with lengthy tree navigation logic”. XSLT makes ECMAScript programmers learn “a declarative programming model, recursive descent processing model, new expression language” and more. Mapping XML onto plain objects loses things XML depends on, such as element order, namespaces, attributes, comments and processing instructions. Writing about E4X in 2004, Jon Udell summed up the aim as “an 80/20 solution that does what most people need in a way that most people can easily understand.”

Key Features

XML as a native type

E4X added two new types to the language, XML (a single node) and XMLList (an ordered list of nodes), plus Namespace and QName objects. XML could be written directly in source code:

1
2
3
4
5

var order = <order id="1024">
              <customer>Ada Lovelace</customer>
              <item sku="A1" price="4.50" qty="2"/>
              <item sku="B7" price="12.00" qty="1"/>
            </order>;

Navigation with familiar operators

1
2
3
4
5
6

order.customer                        // child elements, as an XMLList
order.@id                             // attribute: "1024"
order.item.length()                   // 2
order.item[1].@sku                    // "B7"
order..item                           // every <item> descendant, at any depth
order.item.(@sku == "B7").@price      // filtering predicate: "12.00"

The .(...) filter evaluates its expression once for each element in the list and keeps the elements for which it is true. This replaced a whole category of DOM loops.

Embedded expressions and in-place modification

Curly braces in a literal embed values computed at run time. Assignment, += and delete change the tree directly:

1
2
3
4

var sku = "C3";
order.item += <item sku={sku} price="1.25" qty="4"/>;   // append
order.item.(@sku == "A1").@qty = 3;                     // update an attribute
delete order.item[1];                                   // remove an element

for each ... in

E4X introduced the for each (var x in list) statement, which iterates over values rather than property names:

1
2
3
4

var total = 0;
for each (var it in order.item) {
    total += Number(it.@price) * Number(it.@qty);
}

Namespaces

Namespaces were first-class values. The :: operator qualified names, and a default xml namespace directive set the namespace for unqualified names:

1
2

var soap = new Namespace("http://schemas.xmlsoap.org/soap/envelope/");
var body = envelope.soap::Body;

The specification also defined an optional annex with domNode(), domNodeList() and xpath() methods, so implementations could connect E4X objects to the DOM and to XPath.

Implementations

Evolution and Decline

E4X peaked in the mid-to-late 2000s. Flex developers used it constantly to process XML returned by web services. On the browser side, though, it was in trouble almost from the start. Mozilla’s Firefox 21 release notes later said it was “implemented only in Gecko”, so any web page that used it ran in only one browser family. As Ajax applications grew, JSON, which JavaScript could already read natively, replaced XML as the usual data format, and E4X lost much of its purpose on the web.

E4X also complicated the language itself. XML literals, the .., @ and :: operators, and the filtering predicate all had to fit into the JavaScript grammar. It was never folded into ECMA-262 as the 2004 edition had expected. Mozilla removed it in stages:

1. Firefox 10 (January 2012) banned the “deprecated” E4X syntax in strict-mode code.
2. Firefox 17 (November 2012) disabled it for web content by default.
3. Firefox 21 (May 2013) removed it completely.

ISO/IEC withdrew ISO/IEC 22537:2006 on 10 February 2021, and Ecma International lists ECMA-357 among its withdrawn standards. ActionScript 3.0 kept E4X, but its future became tied to the Flash Platform, which Adobe ended at the close of 2020.

Current Relevance

E4X is no longer available in any mainstream web browser, but it has not disappeared. The Rhino engine still includes it: since Rhino 1.8.0 (January 2025) the implementation has been an optional rhino-xml module, and the project README for Rhino 1.9.1 (February 2026) still documents it as adding “the implementation of the E4X XML standard”. Because Rhino supports it, E4X is still used in production by Rhino-based products. The best-known is the Mirth Connect healthcare integration engine, where E4X expressions such as msg['PID']['PID.3'] are routine in HL7 transformer scripts. Adobe’s ExtendScript still provides its E4X-subset XML object for automating its desktop applications, and the community-maintained AIR SDK documentation still covers “the E4X approach to XML processing” for ActionScript.

Why It Matters

E4X was one of the most complete attempts to make a markup language part of a general-purpose programming language. It is worth studying for several reasons:

• It showed that XML can be language-native. Navigating XML like ordinary objects was much shorter than equivalent DOM code, as the specification’s own side-by-side DOM comparison shows.
• It reached a wide audience through ActionScript. Through ActionScript 3.0 it became the everyday XML API for a generation of Flash and Flex developers.
• It shows how features get dropped from the web. Only one browser engine implemented it, the industry moved to JSON, and it added complexity to the grammar. Together these meant even a ratified Ecma and ISO standard could be removed from a browser.
• It left practical traces. Its for each ... in statement and its idea of writing markup literals directly in a programming language were notable features of mid-2000s JavaScript. A later, unrelated technology, React’s JSX, also embeds XML-like literals in JavaScript; Wikipedia’s E4X article notes the comparison, although JSX compiles to function calls rather than creating XML objects.

E4X shows what JavaScript might have looked like if XML, rather than JSON, had remained the web’s main data format.