The power JavaScript: 'Gandalf of JS' Wirfs-Brock on ECMAscript 2017

JavaScript has become the interface to the web thanks to browsers, it's leaked onto servers with Node.js, and is now carving out a small niche in Machine Learning – but JavaScript just wouldn’t be without ECMAScript.

ECMAScript is the standard language definition on which JavaScript is based and this summer saw an important event take place for ECMAScript and – as a consequence - JavaScript. It marked the ratification of ECMAScript 2017.

This was the second update to ECMAScript, updates that are to follow a new, yearly cadence, and it’s a big departure from previous update cycles. The standard went for years at a time without many updates at all, and would then get a massive upgrade at once, in part due to divisions within the TC39 standards group that oversees ECMAScript.

Now, things are on a more even keel, says Allen Wirfs-Brock. A design expert, Wirfs-Brock has represented both Microsoft and the Mozilla Foundation on comms standards body Ecma International’s TC39 group in the past. He was also project editor for the last huge update to ECMAScript in 2015, originally called ECMAScript 6.

Since the release schedule became more regular, the team also changed the version numbers, renaming ECMAScript 6 to ECMAScript 2015 (ES2015). That major revision turned ECMAScript into a more general purpose programming language, ballooning the specification document from 250 pages to around 600.

“We knew there’d be bugs. We knew there’d be things we wanted to get into it that we simply didn’t have done in time, and so we made the commitment that for the foreseeable future we’d try to do yearly updates where we fix bugs and introduce a small number of features,” Wirfs-Brock told The Reg in an interview.

It’s had a long and torrid history since the first version was published in 1997.

JavaScript wasn’t always JavaScript. Originally, when Brendan Eich of Netscape developed it, it was called Mocha. Eich was a co-founder of the Mozilla project, Foundation and Corporation, and a CTO and CEO of the corproation. He is currently CEO of browser start up Brave Software.

After Mocha, LiveScript became the moniker before finally settling on JavaScript in 1995. Back then, it had promise as a programming language for web-based interfaces, and others took note.

“ JavaSript developed at Netscape and cloned into IE,” explains Wirfs-Brock. Microsoft’s own version of the language was called JScript. As the language made its way into more than one browser, it became clear that everyone would need to be in lockstep when designing new features into the language. “That led to the need for a standardization process.”

In 1996, Netscape delivered the language to standards body Ecma International, which created the specification called ECMA-262 that TC39 oversees.

'The design team of JavaScript', netscape and the troubled years...

“People say ‘standards’ and they think about taking a technology that was evolved somewhere, writing a document and putting a rubber stamp on it and then everyone has to use it,” said Wirfs-Brock, who joined TC39 in 2006. TC39 does the rubber stamping, but it also designs the language. “We are the design team of JavaScript.”

TC39 published version 3 of ECMA-262 in 1999, and then guided it through some troubled years when infighting between different factions slowed down development of the standard.

Netscape and its supporters wanted version 4 to be a more functionally rich, general purpose language but another faction, including Wirfs-Brock, wanted a less adventurous incremental release.

By mid-2008, the two sides had resolved their issues, setting aside the 4.0 concepts and folding the 3.1 ones into a version 5.0, released in 2009. From there, TC39 made incremental developments to under the informal name EcmaScript Harmony, headed by Wirfs-Brock as project editor.

The group released this version in 2015, featuring improvements including strict mode that provided ways to lock down parts of the system against attack. Then ECMAScript 2016 was finalized in June last year, kicking off the new, yearly release cadence. Right on schedule, Ecma ratified ECMAScript 2017 (ES2017) on June 27.

ES2016 had some minor feature changes and some bug fixes. ES2017 isn’t a bombshell release like 2015 either, but it does have some goodies. “It has a couple of major features, and a handful of minor features, and a couple of bug features,” said Wirfs-Brock.

The first major feature is asynchronous function support. Browser environments work different from classic desktop environments, in that all I/O happens synchronously via callbacks, where the programmer passes a function to an API.

ES2016 formalised that into "promises", an abstraction for managing callbacks. ES2017’s asynchronous function support offers programmers a syntax for promise-returning functions.

“In 2017, we added language mechanisms that let a programmer call a function and asynchronously delay or wait for that function to complete,” Wirfs-Brock explains. That makes it easier to program around responses with time delays.

The other big feature is shared memory. Increasingly, JavaScript programs are broken into separate processes (browsers call these "workers") that run concurrently. ES2017 lets these workers share binary memory buffers, communicating directly with each other.

Shared memory works in conjunction with atomics, providing a new memory model that lets multiple agents work as part of a single program. The atomics functions order their calls sequentially in the shared memory model.

“It actually may make programming more complicated,” said Wirfs-Brock, explaining that you must now co-ordinate the activities between two processes. “But it can make it faster because now those two workers can execute in parallel on multiple cores.”

Ceepie-Geepies

What’s next for ECMAScript? It has evolved into the general-purpose programming language that advocates originally envisioned, opening up opportunities in other areas. In some cases it’s even being used for artificial intelligence, although not to the same extent as Python.

You might think that the atomic shared memory’s parallel computing capability would boost machine learning and deep learning capabilities, and you’d probably be right, but developers have already been using JavaScript to take advantage of GPUs directly, leapfrogging the CPU’s multi-core capabilities altogether in some cases.

One example is TensorFire, a JavaScript library developed by MIT graduate students that runs TensorFlow-style machine learning models on any GPU, from directly in the browser. It takes advantage of the shader capabilities in the WebGL browser-based graphics technology originally designed to add shadows and lighting effects to rendered surfaces. Instead of using them for rendering, it uses them to run the parallel computations that neural networks need for fast execution.

There are neural network libraries in JavaScript, such as brain and mind. CovNETJS is a convolutional deep learning network with several demos that runs directly in the browser, while researchers at the University of Tokyo have MILJS. Here’s a JavaScript library that runs Keras models directly in the browser, with GPU support.

We’re also seeing some machine learning and numerical analysis tools emerging for JavaScript-based frameworks like Node, such as ml.js and synaptic, although Node has become an area of conflict for the JavaScript/ECMAScript community.

ECMAScript 2015 introduced a whole syntax for modularizing JavaScript programs. This is different from that used by the Node.js community, which runs JavaScript server-side.

“There has been some negotiation there, because the Node community is big enough that we need to bring them into the core JavaScript ECMAScript world,” said Wirfs-Brock.

That’s the biggest difference that he has seen in TC39 and its surrounding discussions: there are more people involved as the language’s scope has grown.

The core of ES2015 was created by a handful of people, with around ten at the core and 15-20 showing up at committee meetings. Now, there are over 50 people at those meetings. That will eventually shoot up to 100, he predicts.

“At its core there’s these design aesthetics; this amorphous thing about what makes JavaScript,” he said.

ES2016, 17 and 18 have been about fleshing out small details that didn’t get done for ES2015. That won’t last forever.

“We can go on for a few more years with simple extensions, but at some point pretty soon, the process going forward will have to be figured out,” he concluded.

“It will probably be a new generation of people. It will be put together with much more scrutiny and visibility in the world, because it’s such an important piece of technology.” ®