Node.js Event Loop Differences

The Code That Works in Chrome but Breaks in Node

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

Run this in Node.js 10 times. Sometimes you get timeout, immediate. Sometimes immediate, timeout. The order is genuinely non-deterministic. Weird, right?

But wrap it in an I/O callback:

const fs = require('fs');
fs.readFile(__filename, () => {
  setTimeout(() => console.log('timeout'), 0);
  setImmediate(() => console.log('immediate'));
});

Now it's always immediate, timeout. Every single time.

If you understand the Node.js event loop phases, this behavior is obvious. If you're using the browser mental model? Completely incomprehensible.

The Mental Model

The Six Phases

Node.js uses libuv for its event loop, which defines six phases executed in strict order. Step through each phase to see what runs where:

Between every phase transition, Node drains two queues in this exact order: first all process.nextTick callbacks, then all other microtasks (Promise.then, queueMicrotask).

process.nextTick vs. queueMicrotask

Here's a subtlety that catches browser developers off guard. Node.js has two microtask-level APIs: process.nextTick and queueMicrotask. They look similar but they're not the same.

Promise.resolve().then(() => console.log('promise'));
queueMicrotask(() => console.log('queueMicrotask'));
process.nextTick(() => console.log('nextTick'));

Output in Node.js: nextTick, promise, queueMicrotask

process.nextTick runs before other microtasks. There's an internal "nextTick queue" that drains before the "microtask queue."

Phase transition:
  1. Drain ALL process.nextTick callbacks (including newly added ones)
  2. Drain ALL other microtasks (Promise.then, queueMicrotask)
  3. Move to next phase

When to Use Which

The Node.js docs now recommend queueMicrotask over process.nextTick for most cases. nextTick is kept for backward compatibility and specific low-level use cases.

The setTimeout vs. setImmediate Race

Now let's solve the opening puzzle:

setTimeout(() => console.log('timeout'), 0);
setImmediate(() => console.log('immediate'));

Why is this non-deterministic at the top level?

When Node.js starts, it takes time to set up the event loop. By the time it reaches the timers phase for the first iteration:

• If the setup took < 1ms, the timer hasn't expired yet. The timers phase has nothing. The loop continues to poll, then check (setImmediate). Output: immediate, timeout.
• If the setup took >= 1ms, the timer has expired. The timers phase fires the callback. Output: timeout, immediate.

This is a race between Node.js initialization time and the system clock resolution. It's genuinely non-deterministic. And yes, that means the same code can produce different output on different machines -- or even on the same machine at different times.

Inside an I/O callback, there's no race. The callback runs in the poll phase. After poll comes check (setImmediate), then eventually timers (setTimeout). So setImmediate always wins.

Production Scenario: Server-Side Rendering Bottleneck

This is where understanding Node's event loop becomes a production survival skill. In a Node.js SSR server, you're rendering React components to HTML. Each render is CPU-intensive. With many concurrent requests, the event loop gets blocked:

// Bad: blocks the event loop during render
app.get('/page', (req, res) => {
  const html = renderToString(<App />); // synchronous, 50ms
  res.send(html);
});

50ms per render means the event loop is stuck in a single task for 50ms. Other requests, health checks, and WebSocket pings all wait.

// Better: yield between heavy operations
app.get('/page', async (req, res) => {
  // Use React 18 streaming to break rendering into chunks
  const stream = renderToPipeableStream(<App />, {
    onShellReady() {
      res.statusCode = 200;
      res.setHeader('Content-Type', 'text/html');
      stream.pipe(res);
    }
  });
});

React's streaming renderer yields to the event loop between chunks, allowing other I/O to be processed. This is the Node.js equivalent of chunking work with setTimeout in the browser.

For non-React CPU-intensive work, use setImmediate to yield between chunks:

function processLargeDataset(items, callback) {
  let index = 0;
  const CHUNK = 100;

  function processChunk() {
    const end = Math.min(index + CHUNK, items.length);
    while (index < end) {
      transform(items[index]);
      index++;
    }

    if (index < items.length) {
      // setImmediate yields to I/O between chunks
      setImmediate(processChunk);
    } else {
      callback(items);
    }
  }

  processChunk();
}

setImmediate is preferred over setTimeout(fn, 0) for yielding in Node.js because it runs in the check phase of the current iteration, while setTimeout waits for the timers phase of the next iteration. It's slightly faster and doesn't have the 1ms minimum delay that setTimeout adds.

Common Mistakes

Challenge: Node.js Output Order

Challenge: Phase Ordering

const fs = require('fs');

fs.readFile(__filename, () => {
  setTimeout(() => console.log('A'), 0);
  setImmediate(() => console.log('B'));
  process.nextTick(() => console.log('C'));
  Promise.resolve().then(() => console.log('D'));
  queueMicrotask(() => console.log('E'));
  console.log('F');
});

Key Rules