Listening to Glenn Block talk about node.js at Technology and Friends, there’s something interesting about the philosophy behind node.js.
Threads are hard. Threads include overhead, but more significantly, using them requires the developer to hold more stuff in his head. Node.js has a philosophy that leads to asynchronous processing without multiple threads.
Glenn explains how the node.js server is single-threaded, but all the APIs are asynchronous, using callbacks. All the incoming requests go onto one queue, and then whenever processing a request requires calling a service or doing I/O or anything that may take some time, that call is executed asynchronously and the callback goes onto the queue. Because there’s only one thread, developers don’t have to think about multithreading. Because of the asynchronous APIs with callbacks, the single thread doesn’t block waiting for anything. Concurrent performance without threading.
Here’s a speculation. This idea is implemented in JavaScript because the restrictions of the browser and the mechanics of JavaScript have driven us toward this event-driven, callback model in that language. It is natural, then, to take this idea to the server in the same language. Is this model, with a single thread and a queue of incoming requests and callbacks to process, implemented in any other languages in different frameworks?
Node's approach follows the Reactor pattern and is also used in Ruby's EventMachine, Python's Twisted, and OWIN/Gate for .NET, to name only a few. The Wikipedia page lists more. It fits JavaScript much better than other languages because of JS's natural propensity for callback-style APIs, as you noted.