Node.JS's most significant advantage is its non-blocking nature. It's single-threaded, so it doesn't need to spawn a new thread for each new incoming connection.
Behind the event-loop (which is in fact single-threaded), there is a "Non-blocking Worker". This thing is not single-threaded anymore, so (as far as I understood) it can spawn a new thread for each task.
Maybe I misunderstood something, but where exactly is the advantage? If there are too many tasks to handle, wouldn't the Non-blocking Working turn into a Blocking Worker?
Thanks Christian
You need to read about libuv, the "magic" behind node's non-blocking I/O.
The important thing to take away from the libuv book is that libuv uses the host OS's asynchronous I/O facilities; it does not simply create a new thread for every connection.
libuv tells the OS that it would like to know about any changes (connection state, data received, etc) that happen on a particular set of sockets. It is then up to the OS to deal with managing the connections. The OS itself may create one or more threads to accomplish that, but that's not our concern. (And it certainly won't create a thread for every connection.)
For other types of operations like calls to C libraries that may be computationally expensive (ie crypto), libuv provides a thread pool on which those operations may run. Since it is a thread pool, again you don't have to worry about thread count growing without bound. When the pool is fully busy, operations are queued.
So yes, JavaScript runs on a single thread. Yes, node (via libuv) spawns many threads in the background to do work so that it need not block the JavaScript thread. However, the thread count is always controlled, and I/O generally doesn't even get its own node-allocated thread because that's handled by the OS.