Server-Side JavaScript

You have an API to write. It receives an HTTP request, queries a PostgreSQL database, calls two external services, aggregates the responses, and returns JSON. Of the 180 milliseconds this takes, the processor may be working for 4. Everything else is waiting: the network, the disk, the database. A traditional server that allocates one thread per request therefore keeps 176 milliseconds' worth of stack memory tied up doing nothing, multiplied by the number of concurrent requests. At a thousand active connections, that becomes a problem of gigabytes and context switches.

Node.js starts from the opposite observation: since the server spends its time waiting, you might as well have a single thread of execution that handles events as they become ready. A request waiting on the database doesn't occupy a thread; it occupies an entry in a callback table, which is a few hundred bytes. This tradeoff, and only this tradeoff, explains both why Node handles I/O-bound workloads so well and why it collapses as soon as a long-running computation settles into the single thread. Understanding this bargain before you write your first line will spare you half of your production headaches.