The event loop

The event loop in one picture

On a web page, JavaScript runs your code on one main thread. The main thread is the one worker that runs your code. The same worker also draws the page. It can do only one job at a time.

Some jobs have to wait: a timer, a click, a reply from a server. While they wait, none of your code is running. The event loop is the set of rules that picks which waiting job runs next.

Here is the whole rule in one sentence: the event loop runs one task, then runs every waiting microtask, then gives the browser a chance to paint the page, then starts the next task. The next sections explain what a task and a microtask are. Press Play to see one turn:

Browsers and other programs that run JavaScript differ in small details. Stage 11 covers the browser's full rules. This lesson gives you enough to explain real "what prints first?" puzzles today.

This lesson goes further than the Runtime at a glance lesson. It has four steps:

1. The call stack and the task queue.
2. The microtask queue.
3. How the browser paints the page.
4. Starvation: when some work never gets a turn.

The call stack is the list of functions that are running right now. You met it in The call stack lesson. When one function calls another, the new one goes on top. When it returns, it comes off the top.

The event loop has one key rule here, called run to completion. Once a task starts, it runs until the call stack is empty. No other task can jump in halfway.

A task is one job that waits in the main line, the task queue. A queue is a waiting line: the first one in is the first one out. These jobs are all tasks:

• Running a script file.
• Calling a timer's callback.
• Handling a click.

Your code doesn't watch the clock or the mouse. Other parts of the browser do. When a timer is due or you click, they put a task in the queue, and wait for the event loop to run it:

A callback is a function you hand over, to be called later. In setTimeout(fn, 0), fn is the callback. It does not run right away. It waits in the task queue as a later task. That is why a timer with a delay of 0 still waits for the current script to finish.

Code that runs right away, line by line, is called synchronous code. The console.log lines below are synchronous. The callbacks are not.

Watch it happen. The visualizer below runs real code in a small, simulated browser. Press Play, and follow each call onto the call stack. Timers and click listeners wait in the browser, and when a timer is done, its callback moves to the task queue. The event loop moves it to the call stack only when the stack is empty.

When the program is done, click Click me! on its page. Your click becomes a task too: onClick runs and starts a 2-second timer. Press Edit code to change anything, or pick another program.

1console.log("start");2setTimeout(() => console.log("timer"), 0);3queueMicrotask(() => console.log("microtask"));4console.log("end");

Pick A timer and a microtask in the visualizer to run this one. Line 2's timer is done at once, so its callback moves to the task queue right away. It is ready to run, but ready is not the same as running. Line 4 still prints first, because the current task must finish. After that, waiting microtasks get their turn before the next task.

The tiny puzzle above, line by line:

1. Line 1 prints start right away.
2. Line 2 puts the timer callback in the task queue.
3. Line 3 puts a callback in the microtask queue.
4. Line 4 prints end. Neither callback can cut in before this line.

So the final order is start, end, microtask, timer.

1button.addEventListener("click", () => {2  for (let item = 0; item < 100000000; item += 1) {3    doSmallPiece(item);4  }5});

A click handler is a task too. Say it runs a long loop like this one. While the loop runs, it holds the main thread:

• Another click cannot cut in.
• The browser cannot paint the page.

The fix: do a small piece of work, then stop. Schedule the next piece as a later task.

A microtask is a small callback that waits in a second line, the microtask queue. This line goes before the task queue.

Microtasks run at a microtask checkpoint. That is the moment right after a task's code finishes. At a checkpoint, the event loop does not run just one microtask. It keeps running microtasks until the microtask queue is empty.

That is why this common pattern surprises people:

• Synchronous lines, like console.log, print first.
• Promise callbacks and queueMicrotask callbacks print next.
• Timer callbacks print last.

1setTimeout(() => {2  console.log("first task");3  queueMicrotask(() => console.log("microtask after first"));4}, 0);5setTimeout(() => console.log("second task"), 0);

Here, each setTimeout puts one task in the queue. Step by step:

1. Lines 1 to 4 queue the first timer. Line 5 queues the second timer.
2. The first timer runs. Line 2 prints first task.
3. Line 3 puts a microtask in the queue.
4. The first task ends, so a checkpoint comes. The microtask prints microtask after first.
5. Only then does the second timer run and print second task.

A checkpoint comes after every task, not only after the first script. On a timeline of the main thread, it looks like this:

Now watch the microtask queue fill up and empty. Press Play, and keep an eye on the two queues: after the script, the event loop runs every microtask before it takes the timer from the task queue. Try the other programs too, such as Each task gets a checkpoint.

The table below compares the queues. Read each row as: this kind of work waits here, and it runs at this time.

A microtask can put another microtask in the queue. The new one joins the end of the same line. It still runs before the next task. This is useful for a tiny follow-up job right after the current code. It is risky if you keep adding more and more.

Rendering means the browser draws the page on the screen. It has three steps:

1. Style: work out each element's colors and sizes.
2. Layout: work out where each element goes.
3. Paint: draw the pixels.

JavaScript and rendering share the same main thread. When your code changes an element's style, the browser notes the change. But it cannot draw the change while your task is running.

After the task ends and the microtask queue is empty, the browser gets a chance to render. It may update the screen then. It does not have to draw a new frame for every small change. A frame is one picture of the page on the screen.

requestAnimationFrame(callback) fits in here. The browser calls callback just before it paints a frame. It is not a task, and it is not a microtask. Use it for animation code that gets the next frame ready.

Sometimes you want clicks and painting to happen between pieces of work. For that, use later tasks instead, such as setTimeout.

1box.style.background = "red";2box.style.background = "gold";3box.style.background = "lime";4// The browser can paint only after this task ends.5 6requestAnimationFrame(() => {7  box.style.background = "red";8  requestAnimationFrame(() => {9    box.style.background = "gold";10    setTimeout(() => {11      box.style.background = "lime";12    }, 0);13  });14});

The All in one task button sets red, then gold, then lime, all in one task. The browser gets its chance to paint only after that. By then the box is already lime.

The Spread over several turns button sets red now, gold in an animation-frame callback, and lime in a later timer task. So the browser gets a separate chance to paint each color.

A chance to render does not promise a new frame right away. The browser may skip or delay painting:

• when the tab is hidden,
• when the device is busy,
• when nothing on the page changed.

Use requestAnimationFrame to line your work up with a possible frame. It cannot force a frame to appear.

Now put the pieces together with one real event. Here is a click listener for a Save button:

button.addEventListener("click", () => {
  console.log("click handler");
  button.textContent = "Saved";
  Promise.resolve().then(() => console.log("microtask"));
  console.log("handler ends");
});

Line 1 doesn't run the listener. It hands the function to the browser, to call later, every time someone clicks. When you click Save, line 2 prints click handler, line 5 prints handler ends, and then the callback from line 4 prints microtask.

Before any of that, the click makes a short trip. In the visualizer, press Play to run the script, then click Save on its page and watch your click travel:

Three things to notice:

• The browser, not your code, notices the click and queues the task.
• The new text exists as soon as line 3 runs. You see it only after the task and its microtasks finish.
• If another task is running when you click, your click waits in the task queue.

Try the last one: pick Clicking a busy page, press Play, and click Save while busy(3000) holds the call stack. Your click joins the task queue at once, but it waits there until the slow work ends. That is what a page that "doesn't respond" feels like, and a slow listener does the same to the clicks after it.

Starvation means one kind of work keeps getting turns, so other work never gets one. In the cashier story, the express line never ends. The regular line waits, and the price display waits too. On a page, timers, clicks, and painting all seem frozen.

The risky shape is a microtask that queues another microtask, over and over. The browser must empty the microtask queue before it can run the next task or paint.

The demo below is safe: it always stops after the number of steps you choose. Then it shows how long a waiting timer had to wait. Compare that with splitting the same work into later tasks.

1setTimeout(() => console.log("timer"), 0);2let count = 0;3function spinMicrotasks(limit) {4  count = count + 1;5  if (count < limit) {6    queueMicrotask(() => spinMicrotasks(limit));7  }8}9queueMicrotask(() => spinMicrotasks(50000));

1for (let i = 0; i < items.length; i += 1) {2  doSmallPiece(items[i]);3  if (i % 100 === 99) {4    setTimeout(processNextChunk, 0);5    return;6  }7}

1let item = 1;2function processChunk() {3  console.log("item", item);4  item += 1;5  if (item <= 3) setTimeout(processChunk, 0);6}7processChunk();

This example prints item 1, item 2, and item 3, each in its own task. Each call does a little work. Then it schedules the next call with setTimeout. Between tasks, clicks and painting get a turn. They don't have to wait behind one giant loop.

Where you'll use this

When an output order surprises you, ask four questions:

1. Which lines are synchronous?
2. Which callbacks are tasks?
3. Which callbacks are microtasks?
4. When can the browser paint?

Each row below is a common situation. Read it as: when you want this, use this, and here is why it works.

1async function yieldToBrowser() {2  if (globalThis.scheduler?.yield) {3    await globalThis.scheduler.yield();4    return;5  }6  await new Promise((resolve) => setTimeout(resolve, 0));7}

scheduler.yield() is a newer way to give the browser a turn. Not every browser has it yet, so line 2 checks for it first. Checking before you use a feature is called feature detection.

• If the browser has it, line 3 waits for scheduler.yield().
• If not, line 6 waits for a setTimeout instead. That works in every browser, but its timing is less exact.

Both ways start a later turn. The later turn is what matters, not the exact delay.

Common misconceptions

1console.log("start");2setTimeout(() => console.log("timer"), 0);3Promise.resolve().then(() => console.log("promise"));4console.log("end");

The output is start, end, promise, timer. The timer is not late because the browser is slow. It waits in the task queue, because the event-loop rules say it must.

Predict the answer before you click. Each wrong answer tells you which queue rule it missed.

Key takeaways

• JavaScript runs one task at a time. The current task runs to the end before anything else.
• Timer callbacks and clicks wait in the task queue. The browser queues them, and your listener runs only when the event loop takes the task.
• Promise callbacks, queueMicrotask callbacks, and MutationObserver callbacks are microtasks.
• After every task, all microtasks run until the microtask queue is empty. Then the next task can start.
• The browser can paint only between turns, after the microtasks are done. requestAnimationFrame callbacks run just before a paint.
• A chain of microtasks can starve tasks and painting. Split long page work into tasks.

1box.style.background = "red";2box.style.background = "gold";3box.style.background = "lime";4// The browser can paint only after this task ends.5 6requestAnimationFrame(() => {7  box.style.background = "red";8  requestAnimationFrame(() => {9    box.style.background = "gold";10    setTimeout(() => {11      box.style.background = "lime";12    }, 0);13  });14});

Up next: Microtasks in depth. You will predict the order of promise, queueMicrotask, and await puzzles with fewer clues.