What Is the Event Loop?

The event loop is the scheduler that decides what your code runs next. It sits between your JavaScript and the operating system, and it keeps two things moving: a queue of tasks such as timer callbacks and network completions, and a queue of microtasks such as promise reactions.

console.log("1 - sync");

setTimeout(() => console.log("5 - macrotask"), 0);

Promise.resolve().then(() => console.log("3 - microtask"));
queueMicrotask(() => console.log("4 - microtask"));

console.log("2 - sync");

The output order is the whole idea in one snippet. Your synchronous code runs to the end of the current task, giving one and two. Then the runtime drains the microtask queue completely, giving three and four. Only then does it take the next task from the task queue, which gives five.

There is one more part of the picture in a browser. After the tasks and the microtasks are empty, the browser may render. It gets a chance to update the page, run the animation frame callbacks, and paint, and then the loop starts again. That is why a page can look frozen while a long synchronous function is running: the loop never gets control back, so no frame is ever painted.

In Node the shape is the same but the sources of tasks differ. The event loop has several phases, and each phase has its own callback queue, with the timers phase and the poll phase being the ones that matter most. The microtask queue behaves identically, which is why the ordering rules you learn in a browser hold in Node too.

It follows a fixed cycle. Run the current task to completion. Then drain the microtask queue completely, including any microtasks that those microtasks queue. Then, if the browser wants to render, let it paint. Then take the next task and start again.

const log = [];

// A timer that is due immediately still waits for the current task.
setTimeout(() => log.push("timer"), 0);

// A microtask queued from inside a timer.
setTimeout(() => {
  log.push("timer 1");
  Promise.resolve().then(() => log.push("microtask inside timer 1"));
}, 0);

Promise.resolve().then(() => log.push("microtask 1"));

log.push("sync");

setTimeout(() => {
  console.log(log.join(" -> "));
  // sync -> microtask 1 -> timer -> timer 1 -> microtask inside timer 1
}, 10);

The key detail in that output is where the microtask inside the timer appears. It does not wait for the next timer, and it does not run immediately. The microtask queue is drained after the current task finishes, so the microtask queued inside the timer callback runs immediately after that callback and before the next timer.

That is the rule that explains most of the surprising orderings people encounter. Every task is followed by a complete microtask drain, and a microtask that queues another microtask extends that drain rather than postponing it.

The consequence worth warning about is starvation. If a microtask keeps queueing more microtasks, the loop never gets back to the task queue, so timers and input handling never run and the page appears frozen. A promise chain that recurses without a base case does exactly this. The same applies to a task that schedules another task with no delay, which is why an infinite chain of timers keeps the page busy without ever yielding to rendering.

A repeating timer is the simplest way to see the loop cycling: each tick is a separate task, and the gap between them gives the runtime time to do other work and, in a browser, to render a frame.

let count = 0;

const id = setInterval(() => {
  count += 1;
  console.log("tick", count);

  if (count === 3) {
    clearInterval(id);
    console.log("stopped");
  }
}, 10);

Two things about setInterval. It returns a timer identifier, and passing that identifier to clearInterval stops it, which is how you avoid a timer that keeps firing after the thing it was watching has gone. And the delay is a minimum rather than a promise: if the runtime is busy, the callback runs late, and a long task will delay several ticks rather than causing a catch-up burst.

In a browser there is a fourth option worth knowing about. The requestAnimationFrame callback runs just before the next repaint, which is exactly the right hook for animation that has to stay in step with the display. It is throttled to the refresh rate, it pauses when the tab is in the background, and it gives you a timestamp that you can use to compute the frame delta instead of assuming sixteen milliseconds.

For work that does not need to be tied to the display, setTimeout is the better tool, and if the work is heavy enough to matter you should move it off the main thread entirely. A worker thread in the browser, or a worker thread in Node, keeps the event loop free so that input handling and rendering stay responsive.