What are the key features of ES2017 and what will ES2018 bring? Explore the latest and greatest ECMAScript features in two parts. The first part explores major features such as asynchronous functions, shared memory, and Atomics, while the second part explores the rest.

Looking at ECMA International, Technical Committee 39, it turns out that 6 in ES6 is not the number of years required for release. Since ES6/ES2015 took a long time to release (6 years), the committee decided to release a little each year. I think this momentum will change things and improve JavaScript. What will ES2017 bring, the list of ES2018?

You can learn about TC39 agenda progress from 2ALITY via Axel Rauschmayer:The TC39 Process for ECMAScript Features

ES2017

At the TC39 meeting in January, the group addressed the ECMAScript proposal, which will be considered a feature of ES2017 (also known as ES8, presumably to avoid confusion). The list includes:

The main features

  • Async Functions
  • Shared Memory and Atomics

The secondary features

  • Object. The values/Object. Entr…
  • String padding
  • Object.getOwnPropertyDescriptors()
  • Trailing commas in function parameter lists and calls

In this article, Part 1 covers the main features listed above. The second article covers secondary features.

Async Functions

Async Functions on GitHub (Proposed by Brian Terlson)

In ES2015, we used Promise to help us avoid callback hell.

The async/await syntax is inspired by TJ Holowaychuk’s Co package and reads like synchronous code. In summary, the async/await keyword and the try/catch block make the function execute asynchronously. They work like Generateors, but are not converted to Generateor functions. It goes like this:

// Old Promise Town  
function fetchThePuppies(puppy) {
  return fetch(puppy)  
  .then(puppyInfo= > puppyInfo.text())
  .then(text= > {
    return JSON.parse(text)
  })  
  .catch(err= >
    console.log(`Error: ${err.message}`))}// New Async/Await City  
async function fetchThePuppies(puppy) {
  try {
    let puppyInfo =  await  fetch(puppy)
    let text =  await puppyInfo.text()
    return  JSON.parse(text)
  }
  catch (err) {
    console.log(`Error: ${err.message}`)}}Copy the code

This doesn’t mean you should replace all promise code with async/await. Just as you won’t use arrow functions for every function (hopefully), use this syntax only where it’s most appropriate. I won’t go into too much detail because there are tons of articles that have covered async/await. Go and have a look. (The previous sentence was given to some blog posts). In the coming year we will see how people can make their code more readable and use async/await more efficiently.

Shared memory and Atomics

Shared Memory and Atomics on GitHub (Proposed by Lars T. Hansen)

This ECMAScript proposal introduces SharedArrayBuffer and a namespace object Atomics as well as helper functions to ES2017.

We use JavaScript to use more operations in the browser that rely on a JIT just-in-time compiler and a fast CPU. Unfortunately, as Lars T. Hansen said in his excellent March 2016 article A Taste of JavaScript’s New Parallel Primitives.

JS JIts are now slow to improve performance, and CPU performance improvements are mostly stagnant. All consumer devices now (from desktop systems to smartphones) have multiple cpus (true CPU cores) instead of faster cpus, and they usually have more than two except at the low end. A programmer who wants higher performance for a program must start using multiple kernels in parallel. This is not a problem for all “native” applications written in multithreaded programming languages (Java, Swift, C #, and C ++), But running very limited JS on multiple cpus is a problem (Web workers, with slow messaging and few ways to avoid data copying).

SharedArrayBuffer

This proposal provides us with a building block for multi-core computing to explore different ways to implement the JS high-level parallel architecture. What are these building blocks? SharedArrayBuffer MDN has a succinct definition, which I have posted here:

SharedArrayBuffer objects act as a generic, fixed-length block of raw binary data cache, similar to ArrayBuffer objects, but they can create views in shared memory. Unlike ArrayBuffer, SharedArrayBuffer cannot be detached.

I wonder if you felt the same way I did when I first read “??” .

Basically, one of the first ways we can run parallel tasks is using Web Workers. Because workers run in its own global environment and cannot be shared unless workers communicate with each other or with the main thread. Even better, the SharedArrayBuffer object allows you to share bytes of data across multiple wrokers and mainthreads. Furthermore, unlike its predecessor, ArrayBuffer, SharedArrayBuffer can be referenced by multiple parties at the same time, such as Web workers or web page main programs. You can use postMessage to transfer SharedArrayBuffer from one side to the other. Put it all together and use SharedArrayBuffer to transfer data between multiple workers and the main thread so that you can perform multiple tasks at once, which are parallel in JavaScript.

SharedArrayBuffer new message

Important! Note the shelving of SharedArrayBuffer. If you’ve been following the news lately, you may have heard that a processor chip security design flaw led to two vulnerabilities: Meltdown and Spectre. Read it until the browser disables SharedArrayBuffer until the issue is resolved.

Atomics

Next stop for parallelism: Atomics, a global variable with two methods. First, the Atomics approach addresses a problem: When parties (such as Web workers or the main program of a Web page) share a SharedArrayBuffer, each party can read and write to its memory at any time. So how do you maintain consistency and access sequencing, ensuring that parties know to wait for other parties to finish writing their data?

Atomics has wake and load methods. Atomics.wake is a way for parties to “wake up” as they “sleep” in the wait queue waiting for other parties to finish writing data. When you need to read data, you use Atomics.load to load data from a location that requires input of two parameters, TypedArray, a class of array mechanisms to access raw binary data (SharedArrayBuffer). And a subscript to find the location in TypedArray. There’s more to it than what we just introduced, but that’s the gist of it.

Currently, Atomics only has these two approaches. Finally, Hansen (author of our proposal and interpreter of parallel things) says there should be more methods, such as Store and compareExchange, to truly synchronize. Relatively speaking, we are at the beginning of JavaScript parallelism, and this proposal gives us a building block to achieve these goals.

While this is a question worth pondering, it is still a high generalization. This update may not be used by most developers for the next year, but will help advance JavaScript to the benefit of everyone. So thanks for reading, and browse through these fantastic resources to learn more!

More:

  • Dr. Axel to the rescue!
  • A Taste of JavaScript’s New Parallel Primitives from Lars T. Hansen

ECMAScript Goodies I: Check out the ES2017 Major Features. Welcome to star for occasional technical updates. Due to my limited level, mistakes are unavoidable, please correct! Please indicate the source, keep the original link and author information.