Buckler Craig - JavaScript

JavaScript is regularly claimed to be asynchronous. What does that mean? How does it affect development? How has the approach changed in recent years?

Consider the following code:

Most languages process each line synchronously. The first line runs and returns a result. The second line runs once the first has finished regardless of how long it takes.

JavaScript runs on a single processing thread. When executing in a browser tab, everything else stops. This is necessary because changes to the page DOM cant occur on parallel threads; it would be dangerous to have one thread redirecting to a different URL while another attempts to append child nodes.

This is rarely evident to the user, because processing occurs quickly in small chunks. For example, JavaScript detects a button click, runs a calculation, and updates the DOM. Once complete, the browser is free to process the next item on the queue.

Single threads raise a problem. What happens when JavaScript calls a slow process such as an Ajax request in the browser or a database operation on the server? That operation could take several seconds even minutes. A browser would become locked while it waited for a response. On the server, a Node.js application would not be able to process further user requests.

The solution is asynchronous processing. Rather than wait for completion, a process is told to call another function when the result is ready. This is known as a callback, and its passed as an argument to any asynchronous function. For example:

doSomethingAsync() accepts a callback function as a parameter (only a reference to that function is passed so theres little overhead). It doesnt matter how long doSomethingAsync() takes; all we know is that callback1() will be executed at some point in the future. The console will show:

Often, a callback is only ever called by one asynchronous function. Its therefore possible to use concise, anonymous inline functions:

A series of two or more asynchronous calls can be completed in series by nesting callback functions. For example:

Unfortunately, this introduces callback hell a notorious concept that even has its own web page! The code is difficult to read, and will become worse when error-handling logic is added.

Callback hell is relatively rare in client-side coding. It can go two or three levels deep if youre making an Ajax call, updating the DOM and waiting for an animation to complete, but it normally remains manageable.

The situation is different on OS or server processes. A Node.js API call could receive file uploads, update multiple database tables, write to logs, and make further API calls before a response can be sent.

).

To enable Promise-based execution, asynchronous callback-based functions must be changed so they immediately return a Promise object. That object promises to run one of two functions (passed as arguments) at some point in the future:

• resolve: a callback function run when processing successfully completes, and
• reject: an optional callback function run when a failure occurs.

In the example below, a database API provides a connect() method which accepts a callback function. The outer asyncDBconnect() function immediately returns a new Promise and runs either resolve() or reject() once a connection is established or fails:

Node.js 8.0+ provides a util.promisify() utility to convert a callback-based function into a Promise-based alternative. There are a couple of conditions:

1. the callback must be passed as the last parameter to an asynchronous function, and
2. the callback function must expect an error followed by a value parameter.

Example:

Various client-side libraries also provide promisify options, but you can create one yourself in a few lines:

Anything that returns a Promise can start a series of asynchronous function calls defined in .then() methods. Each is passed the result from the previous resolve:

Synchronous functions can also be executed in .then() blocks. The returned value is passed to the next .then() (if any).

The .catch() method defines a function thats called when any previous reject is fired. At that point, no further .then() methods will be run. You can have multiple .catch() methods throughout the chain to capture different errors.

ES2018 introduces a .finally() method, which runs any final logic regardless of the outcome for example, to clean up, close a database connection etc. Its currently supported in Chrome and Firefox only, but Technical Committee 39 has released a .finally() polyfill.

Promise .then() methods run asynchronous functions one after the other. If the order doesnt matter for example, initialising unrelated components its faster to launch all asynchronous functions at the same time and finish when the last (slowest) function runs