Analysis / News / Top Stories /

Newly Released ECMAScript 8 Sets the Stage for Concurrent JavaScript Processing

21 Jul 2017 11:00am, by

Last week, the specification for ECMAScript 8, aka ECMAScript 2017, passed final approvals. The specification, which will serve as the blueprint for different implementations of JavaScript, includes new async features, shared memory and atomics for concurrent processing, and string padding.

“Most of the changes in ECMAScript 8 are quality of life changes for JavaScript programmers. The JavaScript standard library is getting better,” said CJ Silverio, the Chief Technology Officer at npm, Inc.

He noted that a lot of the early stuff in the Node.js Package Manager (npm) was about compensating for failures of what JavaScript has built into it.

“There’s a very popular package called Lodash. It’s the utility library JavaScript should have had all along. Every single ECMAScript release has made Lodash smaller because the stuff it does is appearing in the language. Things like string padding which, in my opinion, should have been there all along,” said Silverio.

Likewise, the object.values/object.entries is another improvement. The object.entries function can be used to iterate over objects (finally!) and, likewise, object.values returns the values of the enumerable string-keyed properties.

What about Browser Support?

In years past, JavaScript developers would have to wait a few more years of waiting for all browsers to support the new specification.

Today, however, thanks to the Babel Project, JavaScript developers have already been using some of the ES8 features for some time. Perhaps most notably, async functions have been available in Babel for almost two years now. That’s because the whole point of Babel is to smooth out the inconsistencies between browser implementations of JavaScript.

A little under two decades ago, doing that meant writing some sort of apparatus to fix the broken implementation of JavaScript in Microsoft Internet Explorer, but today, the problem is that JavaScript implementation versions are typically outdated in older browsers. And the problem of users remaining on an older version of a browser is not going away anytime soon.

Tower of Babel

Originally, Babel was called 625, said Henry Zhu, a contributor on the project. He said the first intent of the project, before he’d joined, was to build a compiler that could turn ECMAScript 6 code into ECMAScript 5 code, enabling it to run on older browsers.

Since that time, a second mission has arisen out of this ability to spread language updates even before browsers support them. Babel gives developers a way to try out the newest features, and even use them inside applications before support is available in the mainstream.

This has the added effect of allowing for feedback on new ECMAScript proposals before they’re completed. The JavaScript community has long sought a better path to collaboration with the ECMAScript committee, due to the somewhat scattershot nature of language updates.

A perfect case in point is the newly added async functions in ECMAScript 8. This feature was added into Babel as far back as 2015, enabling the community to get used to the functionality and syntax of this new feature long before it arrived.

Async functions will, essentially, also be replacing another solution the JavaScript community came up with: Co.

The other major change in ECMAScript 8 is the addition of the new SharedArrayBuffer constructor and Atomics. These combine to make parallelism and concurrency easier to build in JavaScript by giving safe methods of sharing and accessing data that is being used by multiple processing threads.

One almost humorous addition in ES8 is string padding. Famously, the Node.js community had developed a small app for adding left pads to code, and when it was removed from npm’s repositories by its creator, Babel, among other packages, broke. This sent a cascade of failed npm builds throughout the JavaScript world, though it was quickly and easily rectified. Adding string padding to JavaScript at least solves the problem at its root.

Zhu said that string padding was already in the works when the npm incident happened. “It’s funny because it was proposed before the incident happened. It was already at stage 3. People joke that’s what pushed it over,” said Zhu.

Feature image by Martin Reisch via Unsplash.


A digest of the week’s most important stories & analyses.

View / Add Comments

Please stay on topic and be respectful of others. Review our Terms of Use.