The ECMAScript proposal “Function.prototype.toString revision” (by Michael Ficarra) is at stage 4 and therefore part of ECMAScript 2019. It brings two major improvements compared to ES2016:

• Whenever possible – source code: If a function was created via ECMAScript source code, toString() must return that source code. In ES2016, whether to do so is left up to engines.

• Otherwise – standardized placeholder: In ES2016, if toString() could not (or would not) create syntactically valid ECMAScript code, it had to return a string for which eval() throws a SyntaxError. In other words, eval() must not be able to parse the string. This requirement was forward-incompatible – whatever string you come up with, you can never be completely sure that a future version of ECMAScript doesn’t make it syntactically valid. In contrast, the proposal standardizes a placeholder: a function whose body is { [native code] }. Details are explained in the next section.

For health reasons, I’m taking June–August off from work (Twitter, blogging, etc.). See you in September!

In this blog post, I show six tricks enabled by new ES6 features. At the end of each section, I point to related material in my book “Exploring ES6” (which is free to read online).

In this blog post, we look at problems that arise when template literals contain whitespace:

• Breaking up long lines
• Dedenting content
• Joining Arrays
• Indenting inserted content

This blog post shows how to handle trees of ES6 Promises, via an example where the contents of a directory are listed asynchronously.

In Promise-based asynchronous code, rejections are used for error handling. One risk is that rejections may get lost, leading to silent failures. For example:

function main() {
    asyncFunc()
    .then(···)
    .then(() => console.log('Done!'));
}

If asyncFunc() rejects the Promise it returns then that rejection will never be handled anywhere.

Let’s look at how you can track unhandled rejections in browsers and in Node.js.

This blog post gives tips for error handling in asynchronous, Promise-based functions.

In this blog post, I argue that it should be possible to have multiple implementations of the same npm package (same name, same version).

ES6 arrow functions are often a compelling alternative to Function.prototype.bind().

The main use case for ES6 symbols is that you can use them as property keys that can’t clash with other property keys.

In case you think that name clashes don’t matter, here are three examples of where name clashes caused problems in the evolution of the JavaScript standard library: