Watch how JavaScript, then Node.js, actually runs your code — one step at a time.

Before Node adds anything, plain JavaScript already has rules worth knowing cold: one call stack, one thing running at a time, and a strict pecking order between timers and microtasks. This level treats every example as a script, not a server — no pools, no cluster, no HTTP — so the only thing on screen is the call stack and two small queues.

1. One thread, one call stackThree lines of code, run one after another — no exceptions.4 steps
2. A blocking function freezes everythingOne long synchronous function, and nothing else gets a turn.4 steps
3. setTimeout(fn, 0) does not run "now"A zero-millisecond timer still waits its turn.4 steps
4. Microtasks beat a 0ms timerPromise.then and queueMicrotask both cut in front of setTimeout.5 steps
5. await suspends, then resumes as a microtaskEven an already-resolved promise doesn't continue synchronously.5 steps

Level 1 was plain JavaScript. This level is what Node — really, the libuv library underneath it — adds on top: a fixed cycle of event-loop phases, an extra nextTick queue that jumps ahead of microtasks, a firm ordering between timers and setImmediate, and a small pool of background threads for the handful of things that genuinely need one.

1. What Node adds on top of V8V8 runs your JavaScript. libuv gives it timers, I/O, and a threadpool.4 steps
2. The six phases, in orderTimers, poll, and check — walked in the order libuv actually visits them.6 steps
3. process.nextTick jumps the queueNode's own queue drains before the standard microtask queue even starts.5 steps
4. setImmediate wins from inside I/OScheduled together from an I/O callback, check beats timers.5 steps
5. The libuv threadpoolfs.readFile and pbkdf2 leave the main thread; sockets don't.6 steps

With the event loop's mechanics in place, this level is about writing async code that actually uses them well: when Promise.all helps and when it doesn't, why await alone can't fix CPU-bound work, and where worker_threads and child_process fit in.

1. Sequential await vs Promise.allSame three queries, run one at a time vs all at once.4 steps
2. await can't rescue CPU-bound workA synchronous computation blocks everything, async or not.5 steps
3. Offloading CPU work to a worker threadSame computation, delegated so the main thread stays free.5 steps
4. A callback that never lets goRecursively rescheduling itself starves every other request.5 steps

This level puts it all together: a real request's path from socket to response, what happens when many requests overlap, where pools and blocking handlers bite, and how cluster trades shared memory for parallelism. It ends by handing you to the Lab, where every request kind and scenario from this path is available for free play.

1. The anatomy of one requestSocket, handler, response — the full round trip for one request.4 steps
2. A slow query doesn't block other requestsOne request awaits a 900ms query; three others finish in the meantime.4 steps
3. The connection pool has a limitTen queries, two connections — most of them have to wait.4 steps
4. One bad handler blocks the whole serverA synchronous computation freezes every connection, not just its own.4 steps
5. A leaked connection never comes backSkip client.release() and the pool quietly runs dry.4 steps
6. Scaling out with clusterFifty requests, spread across four worker processes.4 steps