Node.js Runtime & Event Loop

Node.js runs JavaScript on a single main thread, but it can handle many concurrent requests because I/O is asynchronous. The event loop coordinates the call stack, libuv-backed operations, microtasks, timers, and callbacks. Understanding that order makes async bugs much easier to predict.

Execution Order

Synchronous code runs first on the call stack. After the stack clears, Node drains process.nextTick, then Promise microtasks, then moves through timer and I/O phases.

console.log("sync start");

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

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

console.log("sync end");

The typical output begins with sync start, sync end, nextTick, and promise. The exact ordering of setTimeout(..., 0) and setImmediate can depend on where they are scheduled, especially around I/O callbacks.

Blocking The Loop

Async I/O does not help if your JavaScript blocks the event loop with CPU work. While a synchronous loop hashes data, compresses images, or parses huge files, no other request handler can run.

export function expensiveSum(limit: number): number {
  let total = 0;
  for (let index = 0; index < limit; index += 1) {
    total += Math.sqrt(index);
  }
  return total;
}

That function monopolizes the main thread until it finishes. For CPU-heavy work, use worker_threads, a job queue, or a separate service. Use process.nextTick sparingly for callbacks that must run before the event loop continues; overusing it can starve I/O. Use setImmediate when you want to yield and continue after the current poll phase.

Libuv And Async I/O

libuv provides the cross-platform event loop and thread pool behind file system operations, DNS work, and networking. Node can wait for sockets without dedicating one JavaScript thread per connection, which is why it works well for I/O-heavy APIs.

Further Learning

Search these terms to go deeper:

• “Node.js event loop phases” — timers, poll, check, close callbacks, and microtasks
• “process.nextTick vs Promise Node” — priority ordering and starvation risks
• “libuv thread pool Node.js” — what work happens outside the main thread
• “worker_threads CPU bound Node” — moving expensive computation off the event loop

Node.js Runtime & Event Loop

Node.js runs your JavaScript on a single thread — one lane. Yet it can juggle thousands of requests at once. How? Because it never waits around for slow things (like reading a file or a database) — it hands that off and moves on to the next task while waiting.

The order things run in

Regular code runs first. Then Node quickly checks a couple of “priority” queues before getting to timers:

console.log('sync start')
setTimeout(() => console.log('timeout'), 0)
Promise.resolve().then(() => console.log('promise'))
console.log('sync end')

// order: sync start, sync end, promise, timeout

The rule of thumb: regular code first, then Promises, then timers (setTimeout) — even a setTimeout(fn, 0) waits until after any pending Promises.

The one thing that breaks everything: blocking the thread

Since there’s only one lane, if your code does a big chunk of heavy math synchronously, nothing else can run until it finishes — not even other users’ requests:

// this hogs the single thread until it's done — bad for a server!
function expensiveSum(limit) {
  let total = 0
  for (let i = 0; i < limit; i++) total += Math.sqrt(i)
  return total
}

Why Node is great for I/O

Node shines specifically for things like APIs and web servers, where most of the waiting is for other things (databases, files, network) rather than heavy computation. The waiting happens efficiently in the background while Node handles other requests.

In one sentence

Node runs JavaScript on one thread but handles many requests well because I/O waits happen in the background (not blocking) — the danger is CPU-heavy synchronous code, which freezes the entire server until it finishes.

Want to go deeper?

Switch to Expert mode above for the full event loop phases, process.nextTick vs Promises, and worker_threads.