The rise of async JavaScript

As JavaScript has evolved over the past several years, so have the patterns for handling its asynchronous nature. Through callbacks, Promises, and now async functions, JavaScript has made asynchronous control flow easier to tackle. Jeremy Fairbank dives into the new async functions landing in ES7 and investigates various use cases and gotchas along the way.

Jeremy Fairbank explores the new async function declarations in ES7. He briefly reviews the history of asynchronous control flow mechanisms in JavaScript before making a case for the usefulness of async functions. Asynchronous programming is a crucial part of JavaScript but has also proved a great challenge. In the beginning, we managed it with callbacks, which unfortunately led to callback hell. Next, we gained Promises, which untangled the nested callbacks and gave us powerful mapping constructs over eventual values. However, even with Promises, it was difficult to express meaningful, readable control flow and manage errors. Ultimately, to manage asynchronous JavaScript, we’ve had to create our own semantics apart from natural language constructs, such as error-object-first callbacks in Node. Jeremy’s goal is to not only introduce async functions, but also investigate their use cases and demonstrate why they matter. One immediate benefit, for instance, is the ability to write asynchronous code in a synchronous manner, which means that we regain control of natural language constructs such as for loops and try/catch blocks with asynchronous code. Jeremy will cover the await operator, dissect an async function to determine what is semantically happening under the hood of a JavaScript engine or in transpiled code, prove that async functions always return Promises, and identify the differences between—and performance implications of—sequential and parallel XHR requests with await.