All About E: The Language that Infiltrated JavaScript
Doug Crockford is best known for his long-time work in JavaScript and for creating the JSON Data Interchange Format. His opinion tends to carry weight — and Crockford said it’s time to retire JavaScript.
“JavaScript, like the other dinosaur languages, has become a barrier to progress,” Crockford told IT outsourcing firm Evrone in an interview. “We should be focused on the next language, which should look more like E than like JavaScript.”
What is E? Wikipedia calls E “an object-oriented language for securing distributed computing,” and by design, E emphasizes security. But to learn more about E’s impact on JavaScript, The New Stack spoke with Mark Miller, the main designer of E, which he co-created with Dean Tribble as well as several Electric Communications colleagues, including Crockford, Doug Barnes, Dan Bornstein, and Chip Morningstar during the mid-1990s.
“Both Doug and I had a lot to do with the birth of the language,” Miller told us. “We were quite in love with the language that we had created.”
Miller considers the language itself dead — an open source language, E never attracted more than 100 users to the community, he said.
But E didn’t go softly into that good night — its influence is still seen in JavaScript today, thanks to the efforts of Miller, Crockford, and other members of the ECMAScript standards committee. Miller explained to The New Stack how E influenced JavaScript, how his company Agoric still puts the E ideas to use in DeFi with blockchain, and the additional aspects of E he’d like to see upcycled into JavaScript.
12 Angry Men and ECMAScript
“Have you seen the movie 12 Angry Men?” Miller asked me. I have, I replied. “I think that movie is the best way to explain what the ECMAScript committee was like at the time that I joined Google.”
Crockford convinced Miller to join the committee in 2007 as an additional Google representative. The committee was focused on upgrading ECMAScript 3 to ECMAScript 4 but it wasn’t going well.
“The committee had been meeting continuously from 1999 to 2007 at this point, and they still did not have a successor standard. Most of the committee was focused on ECMAScript 4, which in my opinion was a horrible language,” Miller said. “Doug started off as the one holdout — the Henry Fonda character saying, ‘No, we will not agree on this.’”
JavaScript was messy, complicated and weird, but Crockford convinced Miller that ECMAScript 3 had the seeds for an E-like experience and that it had the core enabling elements that would allow it to become an E-like secure distributed programming language.
“I joined his revolt against ECMAScript 4, and that revolt had several other members by that time — just like in 12 Angry Men — he incrementally convinced the jurors to come over to his camp,” Miller said. Eventually, the revolt won. The successor to ECMAScript 3 became ECMAScript 5, the version designed by the revolters while the rest of the committee focused on ECMAScript 4.
“The ECMAScript 5 standard did have the enablers for using JavaScript as a straightforward, simple, secure programming language. We were both very proud of what we did for ECMAScript 5,” he said.
One fundamental aspect of E they brought over in ECMAScript 5 was support for the object-capability security model, he said.
“JavaScript’s functions together with JavaScript’s objects, used as records, can be combined to create a pattern that Doug named the objects-as-closures pattern, and if you use JavaScript as objects-as-closures, the expressiveness feels much like E. But as of ECMAScript 3, it doesn’t have the security yet.”
The enablers they got into ECMAScript 5 enabled them to write the SES-shim, a library that brings about a secure language state, which is now called Hardened JavaScript, Miller said.
Freeze
In ECMAScript 5, they introduced several enablers, the primary being Object.freeze(). Despite its name, it has nothing to do with immutability, Miller said. Instead, it tamper-proofs the surface of an object so that the clients of the object can now only interact with the object — according to the object’s explicit behavior, Miller explained. The provider of the object can populate it with methods that capture internal state variables and can encapsulate that state, so the clients of the object cannot tamper with it. By “freezing,” what’s meant is that the properties of the object can no longer be changed, he added.
“The client can no longer change the shape of the object. So the shape of the object is fixed. The internal state is now hidden from the clients,” he said. “Now the object becomes something that can only be interacted with according to the object’s design.”
That step addressed a security problem: prototype poisoning, in which objects created in traditional JavaScript were all mutable and can be subverted to confuse or surveil other parts of a program by anyone who had access to them.
“One of the things that we do with freeze and with the other enablers that we got into ECMAScript 5 (Object.getOwnPropertyNames() and Object.getPrototypeOf() ) is we were able to write something we call ‘harden(),’ which is a transitive freeze that walks an object graph, freezing all of the objects that it finds by doing property traversal. We were able to enumerate all of the primordial objects, all of the objects that JavaScript programs within the same environment implicitly share, like Array and Array.prototype, etc.,” Miller said.
I/O Expression
The SES-shim library, at the beginning, when it initializes, does some repairs on the primordials, then hardens all of the primordials, he said. That ensures all of the implicitly shared objects are now genuinely immutable.
“We did some repair on the committee so that the primordials didn’t have any hidden mutable state or hidden I/O abilities,” he said.
Everything that was implicitly shared is completely powerless and immutable, he added, so that sharing does not violate isolation.
Another crucial enabler was the ability to virtualize all I/O. One of the beautiful and under-appreciated aspects of JavaScript, Miller said, is that the language is about computation — not about I/O. JavaScript programs express I/O by performing a global variable lookup of a host-provided object, like “document” in the browser or “process” in Node.
Those host-provided global variables are not standardized as part of the language standard, but are brought in by the host that provides all of the I/O abilities for affecting the outside world or for sensing the outside world.
“What that means is that if you can intervene in the global scope lookup, you can completely virtualize all of the I/O and that’s what we made possible with our enablers in ECMAScript 5. Hardened JavaScript continues to use the enablers to intercept the global scope lookup,” he said.
Hardened JavaScript is what Agoric still uses today. Agoric writes most of their code within a disciplined subset of Hardened JavaScript called Jessie (a name intended to evoke a combination of JS and E). Jessie emphasizes Crockford’s objects-as-closures pattern as an alternative to JavaScript’s inheritance mechanisms.
Promises
Another important aspect of E ported to JavaScript is non-blocking promises, which E was the first language to have, Miller said. Promises happened in ECMAScript 6 and those promises are directly based on E promises.
“A promise is an object returned by an asynchronous function. … the promise object provides methods to handle the eventual success or failure of the operation,” explains MDN web docs. E in a Walnut explains promises in more detail. Essentially, in promise systems before E, the calling thread would at some point block, waiting for the operation to complete. In much the way one wouldn’t wait for someone to finish a task on a project before beginning to work on one’s own tasks, E’s non-blocking promises made it possible to handle the eventual success or failure of the operation without blocking to wait for the resolution.
JavaScript’s promises only provide for local asynchrony out of the box, but Agoric’s Endo libraries extend them to also provide E-like distributed object-capability security over cryptographic protocols, making JavaScript into an E-like distributed secure language.
ECMAScript 6 introduced E’s non-blocking promises. But ECMAScript 6 also introduced classes and became at least twice as big … and kept growing, Miller said. It became more complex, an anathema to both Miller and Crockford. While Miller stayed, Crockford left the committee, essentially seeing JavaScript as a lost cause, according to Miller.
Miller still sees potential in JavaScript.
”I do not see it as a lost cause,” he told The New Stack. “I’m very proud of what we’ve continued to accomplish in the efforts of the committee, enabling us to use it as an E-like distributed secure language.”
