This blog post gives tips for using async functions. If you are unfamiliar with them, you can read chapter “Async functions” in “Exploring ES2016 and ES2017”.

This blog post explains the ECMAScript proposal “Asynchronous Iteration” by Domenic Denicola and Kevin Smith. It has reached stage 4 on 2018-01-25 and is part of ECMAScript 2018.

The ECMAScript proposal “Rest/Spread Properties” by Sebastian Markbåge enables:

• The rest operator (...) in object destructuring. At the moment, this operator only works for Array destructuring and in parameter definitions.

• The spread operator (...) in object literals. At the moment, this operator only works in Array literals and in function and method calls.

The ECMAScript proposal “global” by Jordan Harband is currently at stage 3. It provides a new standard way of accessing the global object.

I really like the way EJS templates work, because the meta-language (loops, if-then-else, etc.) is just JavaScript. This blog post describes ideas for improving their syntax.

As of version 6, Babel supports presets, sets of features that can be enabled together. This blog post looks at three new useful Babel presets (and, as a bonus, two presets especially for Node.js).

This blog post describes a new setup for presenting with Apple’s Keynote app that I’ve experimented with. It involves:

• A Mac running Keynote
• An iOS device (iPhone or iMac)

The ECMAScript proposal “Template Literal Revision” by Tim Disney reached stage 4 and will be part of ECMAScript 2018. It proposes to give the innards of tagged template literals more syntactic freedom.

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!