Reading 17 Addendum: More on the JavaScript Event Loop

Our current understanding of the event loop from this reading is solid. For the purposes of this class, that is what you need to know about how the JavaScript runtime system actually runs code and asynchronous callbacks. For those that are curious, it turns out that there are some additional details for how this all works, which can produce results that don’t align with our current understanding.

For example, consider this code:

/** Wait for `milliseconds` to pass before returning. */
function busyWait(milliseconds: number): void {
    const now = new Date().getTime(); // new Date().getTime() is always the current clock time in milliseconds
    const deadline = now + milliseconds;
    while (new Date().getTime() < deadline) {
        // do nothing, just wait until the clock reaches the deadline time
    }
}

let { promise, resolve, reject } = Promise.withResolvers();

setTimeout(() => {
  console.log("timer expired");
}, 0);

promise.then((result) => {
  console.log(result);
});

busyWait(5000);

resolve("promise resolved");

console.log("End of the code");

What do you expect to be printed in the console? Make a guess, then try it yourself! You can run the code on your own machine or here.

Interesting! If there were just one event queue, we would expect that the callback passed to setTimeout would be added to the event queue before the callback passed to the promise, especially because we are busy waiting for 5 seconds before we resolve the promise. So why don’t we see timer expired printed before promise resolved? Well, promise callbacks actually aren’t added to the main JavaScript event queue. They are added to another queue, called the microtask queue.

The microtask queue is just another queue like the main event queue (also called task queue or macrotask queue) that contains callbacks to run. However, these microtasks have a higher priority than the task queue:

The difference between the task queue and the microtask queue is simple but very important:

• When a new iteration of the event loop begins, the runtime executes the next task from the task queue. Further tasks and tasks added to the queue after the start of the iteration will not run until the next iteration.
• Whenever a task exits and the execution context stack is empty, all microtasks in the microtask queue are executed in turn. The difference is that execution of microtasks continues until the queue is empty—even if new ones are scheduled in the interim. In other words, microtasks can enqueue new microtasks and those new microtasks will execute before the next task begins to run, and before the end of the current event loop iteration.

This clears up the inconsistency above; the setTimeout callback is added to the task queue when the timer finishes, and the promise callback is added to the microtask queue when the promise resolves, which will be drained before we take the setTimeout callback off the task queue.

Just as we can use setTimeout to manually schedule tasks for the task queue, we can use queueMicrotask() to schedule microtasks on the microtask queue. However, you generally shouldn’t need to use queueMicrotask. Additionally, since the microtask queue is completely drained before the next iteration of the event loop, we must be careful if our microtasks ever queue other microtasks, since this recursive pattern could starve the event loop.

Why microtasks?

function animateMacrotask() {
    [currentLeftMacrotask, deltaLeftMacrotask] = updatePosition(currentLeftMacrotask, deltaLeftMacrotask);
    [currentTopMacrotask, deltaTopMacrotask] = updatePosition(currentTopMacrotask, deltaTopMacrotask);
    ballMacrotask.style.left = `${currentLeftMacrotask}%`;
    ballMacrotask.style.top = `${currentTopMacrotask}%`;
    requestIdMacrotask = requestAnimationFrame(animateMacrotask);
}

for (let i = 0; i < 10000; i++) {
    microtasks.push(faceLeftMicrotask, faceRightMicrotask, faceUpMicrotask, faceDownMicrotask);
    macrotasks.push(faceLeftMacrotask, faceRightMacrotask, faceUpMacrotask, faceDownMacrotask);
}

startButton.addEventListener('click', () => {
    resetAnimation();
    // delay to let repaint occur and update ball position
    setTimeout(() => {
        microtasks.forEach((task) => queueMicrotask(task));
        macrotasks.forEach((task) => setTimeout(task, 0));
    }, 200);
});

The event loop in Node is somewhat more complicated. Node breaks the event loop into different phases, such as a phase to handle callbacks from I/O operations. Each phase has its own queue, and each queue is exhausted (or a callback limit is reached) before moving on to the next queue.

Where do microtasks come in? The microtask queue still exists and is drained after each operation from one of the phases completes. So now, we can think of Node has having multiple task (also called macrotask) queues, one for each phase, which are drained before moving on to the next task queue. The microtask queue works the same way as before, having a higher priority than all the other task queues, so that after each task in one of the task queues, the microtask queue is completely drained.

nextTick queue

console.log(0);

const { promise, resolve, reject } = Promise.withResolvers();

promise.then((result) => {
    process.nextTick(() => {
        console.log(result);
    });
});

setTimeout(() => {
    resolve(2);
    console.log(1);
}, 0);

queueMicrotask(() => {
    console.log(3)
    process.nextTick(() => {
        console.log(4);
    });
    queueMicrotask(() => {
        console.log(5);
    });
});

process.nextTick(() => {
    console.log(6)
    queueMicrotask(() => {
        console.log(7);
    });
    process.nextTick(() => {
        console.log(8);
    });
});

console.log(9);

Wrapping up:

• The JavaScript event loop has a macrotask queue and a microtask queue
• The microtask queue is completely drained before each macrotask is taken of its queue and before the next browser repaint
  • macrotasks can interleave with browser repaints and requestAnimationFrame callbacks
• Promise callbacks are added to the microtask queue
• Node has different macrotask queues for different phases of the event loop, and a nextTick queue with the same priority as the microtask queue
• queueMicrotask can be used to schedule callbacks on the microtask queue, likewise with process.nextTick and the nextTick queue.
  • These generally won’t need to be used unless fine grained control of event ordering is needed.

Here are various documentation sources that were used to inform this addendum and can be helpful to find additional information:

• Node event loop documentation
• Node queueMicrotask specification
• Node process.nextTick specification
• MDN JavaScript Execution Model
• MDN microtask guide
• MDN microtask guide in depth
• HTML Living Standard Processing Model