When a function
f calls a function
g needs to know where to return to (inside
f) after it is done. This information is usually managed with a stack, the call stack. Let’s look at an example.
Initially, when the program above is started, the call stack is empty. After the function call
f(3) in line D, the stack has one entry:
After the function call
g(x + 1) in line C, the stack has two entries:
After the function call
h(y + 1) in line B, the stack has three entries:
The stack trace printed in line A shows you what the call stack looks like:
Next, each of the functions terminates and each time the top entry is removed from the stack. After function
f is done, we are back in global scope and the call stack is empty. In line E we return and the stack is empty, which means that the program terminates.
Simplifyingly, each browser tab runs (in) a single process: the event loop. This loop executes browser-related things (so-called tasks) that it is fed via a task queue. Examples of tasks are:
The event loop is surrounded by other processes running in parallel to it (timers, input handling, etc.). These processes communicate with it by adding tasks to its queue.
Browsers have timers.
setTimeout() creates a timer, waits until it fires and then adds a task to the queue. It has the signature:
callback is added to the task queue. It is important to note that
ms only specifies when the callback is added, not when it actually executed. That may happen much later, especially if the event loop is blocked (as demonstrated later in this chapter).
ms set to zero is a commonly used work-around to add something to the task queue right away. However, some browsers do not allow
ms to be below a minimum (4 ms in Firefox); they set it to that minimum if it is.
For most DOM changes (especially those involving a re-layout), the display isn’t updated right away. “Layout happens off a refresh tick every 16ms” (@bz_moz) and must be given a chance to run via the event loop.
There are ways to coordinate frequent DOM updates with the browser, to avoid clashing with its layout rhythm. Consult the documentation on
requestAnimationFrame() for details.
Let’s look at an example:
The function starting in line A is added to the task queue immediately, but only executed after the current piece of code is done (in particular line B!). That means that this code’s output will always be:
As we have seen, each tab (in some browers, the complete browser) is managed by a single process – both the user interface and all other computations. That means that you can freeze the user interface by performing a long-running computation in that process. The following code demonstrates that.
Whenever the link at the beginning is clicked, the function
onClick() is triggered. It uses the – synchronous –
sleep() function to block the event loop for five seconds. During those seconds, the user interface doesn’t work. For example, you can’t click the “Simple button”.
You avoid blocking the event loop in two ways:
First, you don’t perform long-running computations in the main process, you move them to a different process. This can be achieved via the Worker API.
Second, you don’t (synchronously) wait for the results of a long-running computation (your own algorithm in a Worker process, a network request, etc.), you carry on with the event loop and let the computation notify you when it is finished. In fact, you usually don’t even have a choice in browsers and have to do things this way. For example, there is no built-in way to sleep synchronously (like the previously implemented
setTimeout() lets you sleep asynchronously.
The next section explains techniques for waiting asynchronously for results.
Two common patterns for receiving results asynchronously are: events and callbacks.
In this pattern for asynchronously receiving results, you create an object for each request and register event handlers with it: one for a successful computation, another one for handling errors. The following code shows how that works with the
Note that the last line doesn’t actually perform the request, it adds it to the task queue. Therefore, you could also call that method right after
open(), before setting up
The browser API IndexedDB has a slightly peculiar style of event handling:
You first create a request object, to which you add event listeners that are notified of results. However, you don’t need to explicitly queue the request, that is done by
open(). It is executed after the current task is finished. That is why you can (and in fact must) register event handlers after calling
If you are used to multi-threaded programming languages, this style of handling requests probably looks strange, as if it may be prone to race conditions. But, due to run to completion, things are always safe.
This style of handling asynchronously computed results is OK if you receive results multiple times. If, however, there is only a single result then the verbosity becomes a problem. For that use case, callbacks have become popular.
If you handle asynchronous results via callbacks, you pass callback functions as trailing parameters to asynchronous function or method calls.
The following is an example in Node.js. We read the contents of a text file via an asynchronous call to
readFile() is successful, the callback in line A receives a result via the parameter
text. If it isn’t, the callback gets an error (often an instance of
Error or a sub-constructor) via its first parameter.
The same code in classic functional programming style would look like this:
The programming style of using callbacks (especially in the functional manner shown previously) is also called continuation-passing style (CPS), because the next step (the continuation) is explicitly passed as a parameter. This gives an invoked function more control over what happens next and when.
The following code illustrates CPS:
The library Async.js provides combinators to let you do similar things in CPS, with Node.js-style callbacks. It is used in the following example to load the contents of three files, whose names are stored in an Array.
Using callbacks results in a radically different programming style, CPS. The main advantage of CPS is that its basic mechanisms are easy to understand. But there are also disadvantages:
Callbacks in Node.js style have three disadvantages (compared to those in a functional style):
if statement for error handling adds verbosity.
The next chapter covers Promises and the ES6 Promise API. Promises are more complicated under the hood than callbacks. In exchange, they bring several significant advantages and eliminate most of the aforementioned cons of callbacks.
 “Help, I’m stuck in an event-loop” by Philip Roberts (video).
 “Event loops” in the HTML Specification.