Runtime bootstrap and the event loop

From node app.js to your first line

Nothing of yours runs first. When you type node app.js, the C++ node binary boots an entire runtime before your code exists. It creates a V8 isolate (an isolated instance of the JS engine with its own heap and GC) and a context (the global object and built-ins for that isolate). It hands V8 a platform shim so V8 can post tasks back to libuv, the C library that owns the event loop and the OS I/O primitives. libuv then initializes the default loop. Next, Node runs its internal JavaScript bootstrap — thousands of lines that wire up process, the globals (console, Buffer, timers), and the module loaders (CommonJS require and the ESM loader). Only then is your entry module loaded and its top-level synchronous code executed, top to bottom, to completion.

That last clause is the whole mental model: your top-level code runs synchronously to the end before a single asynchronous callback fires. A setTimeout(fn, 0) at line 1 does not run at line 1 — it registers a timer and keeps going. The loop is entered only when the call stack is empty, i.e. after your module finishes. This is why a long synchronous block at startup delays every timer and I/O callback you scheduled: they are all waiting for the stack to drain.

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

// stdout:
// 1: top-level start
// 2: top-level end          ← all sync code finishes first
// 3: promise microtask      ← microtasks drain before the loop ticks
// 4: timer                  ← loop's timers phase, last

The libuv loop: phases in a fixed order

Once the stack is empty, Node enters the loop. libuv does not have one undifferentiated queue — it has an ordered set of phases, and each tick walks them in the same sequence, draining that phase’s own callback queue before moving on:

1. timers — callbacks for setTimeout/setInterval whose threshold has elapsed.
2. pending callbacks — a few deferred system callbacks (e.g. some TCP error codes).
3. idle / prepare — internal bookkeeping; you never touch these.
4. poll — the heart of the loop. It computes how long to block, then blocks waiting for I/O (new connections, socket data, completed fs work), running their callbacks as they arrive.
5. check — setImmediate callbacks fire here, right after poll.
6. close callbacks — socket.on("close") and friends.

The poll phase is where the process spends idle time: with nothing else to do, it sleeps in epoll_wait (Linux) / kqueue (macOS) until the kernel says a file descriptor is ready. That kernel-level readiness notification — not the threadpool — is how Node scales tens of thousands of concurrent network sockets on one thread.

Microtasks cut between everything: nextTick > Promise > the loop

The phases are the macro structure. Underneath them sit two microtask queues that Node drains between every callback and between phase transitions — they are not phases of the loop at all. The order is fixed and worth memorizing:

1. The process.nextTick queue (Node-specific, highest priority).
2. The Promise / queueMicrotask job queue (the ECMAScript microtask queue).

Both are fully drained to empty before the loop is allowed to advance. So the global priority is: process.nextTick > Promise/queueMicrotask > setTimeout/setImmediate/I-O. A program makes this concrete:

console.log("sync");
setTimeout(() => console.log("timeout"), 0);
setImmediate(() => console.log("immediate"));
Promise.resolve().then(() => console.log("promise"));
process.nextTick(() => console.log("nextTick"));
queueMicrotask(() => console.log("queueMicrotask"));
console.log("sync end");

// stdout (deterministic for the microtasks; timeout/immediate order may swap at top level):
// sync
// sync end
// nextTick          ← nextTick queue drains first
// promise           ← then the Promise job queue…
// queueMicrotask    ← …in FIFO order with promise jobs
// timeout           ← only now does the loop tick its phases
// immediate

process.nextTick runs sooner than a Promise — useful when an API must defer to “after the current operation” without yielding to the loop at all (e.g. emitting an event the caller hasn’t had a chance to subscribe to yet). That same priority is its danger, covered below.

The threadpool: where “single-threaded” stops being true

JS executes on one thread, but several built-in operations cannot be done with a non-blocking syscall, so libuv offloads them to a threadpool: fs.* (file I/O), dns.lookup (the default resolver, which calls blocking getaddrinfo), CPU-bound crypto like pbkdf2/scrypt/randomBytes, and zlib compression. The pool’s default size is 4 (UV_THREADPOOL_SIZE, settable up to 1024, and only read once at startup). Crucially, network I/O does not use the pool — sockets go through epoll/kqueue in the poll phase. So your 10,000 idle sockets cost nothing, but five concurrent fs.readFiles with a pool of four means the fifth waits for a slot.