The H Speed Guide to Node.js
by Dj Walker-Morgan
The traditional way of handling a web request is to get the request, parse it, wait to load the resources needed from disk to process it, process it (however long that takes), and return a response. Because there is a lot of waiting involved, to handle two or more requests at the same time would require spinning off a thread of execution for each request. The more requests you need to handle, the more threads you spin off and the more resources you consume to manage each thread.
Event-based frameworks take a different approach, but they do require that you code differently. They exploit the fact that many server applications spend their time waiting for I/O, and turn that waiting time into working time. There is only one thread of execution, but the programmer splits up his code into chunks which are called when an "event" occurs. For example, opening a file takes some I/O time, so in event driven systems, we say "please start opening a file, when you are done opening the file, call back to this function." The framework starts the open, makes a note of the required function and waits to be told by the OS that the file is open. When it gets that notification, that event triggers the calling of the required function.
Now, the first reaction could well be: "But doesn't this make my code a mess of interlinking functions?" The answer is yes, if your language isn't expressive enough to handle it. For example, if your chosen language handles anonymous functions, the code could look like this: