The Event Loop

The server in the last lesson can handle many browsers hitting it at the same time, without waiting for one request to finish before starting the next. This lesson explains how — and why Node was designed this way in the first place.

Many server platforms handle concurrent requests by starting a new thread — a separate line of execution — for each one. Node does the opposite: your JavaScript code runs on a single thread. Only one line of your code executes at any instant, ever.

The trick is that most of what a server spends time on isn't actually computing — it's waiting: waiting for a file to finish reading off disk, waiting for a database to respond, waiting for another server's API to reply. Node hands that waiting off to the operating system in the background, and immediately moves on to the next piece of code, rather than sitting idle until the wait is over.

When the wait finishes — the file is read, the database replies — Node queues up the callback you provided, and runs it as soon as the single thread is free.

This is why the previous lesson's server can serve a second visitor while the first visitor's request is still being handled — as long as the handling involves waiting (for a file, a database, a network call) rather than heavy computation, the single thread is free to work on other requests during that wait.

You rarely write "event loop" code directly — it runs automatically, underneath every callback, promise, and async/await you write. But understanding that it's there explains a lot: why Node.js code is written the way it is, why blocking file operations are discouraged in servers, and why the next several lessons on events, callbacks, and promises all matter as much as they do.