Are you able to wrap your head around asynchronous programming in Node.js? Or do you prefer synchronous programs?
Async can handle a lot more requests than using a threaded model, each thread has an overhead of several megs of RAM. In Java, if I remember correctly, it's around 2MB per thread you start, so for each user accessing your site, you create a thread for the user, a thread for this a thread for that and soon you chow up all the available memory.
Using the asynchronous model, you have one thread that is shared between many users and by using it in a non-blocking way, you can do a lot of processing with that single thread - NodeJS uses a single thread for its event loop. Java, in frameworks like VertX and the latest servlets, Scala with Actors, Dart using Isolates and its own event loop decided to take it a step further, start a number of threads and let each of them have an event loop - this means each event loop can potentially max out a CPU core.
To get the same benefits in NodeJS, you'd need to start multiple NodeJS instances, usually one per core. I'm not an Erlang expert, but I believe Erlang-based frameworks are doing the same as NodeJS on a Single Thread.
As Tibor said, Async is the way forward! Ain't nobody got time for blocking IO.
I think the question is not on performance, but on programming ... Do developers have to do more work to understand and properly use Async programming? My answer would be yes.
Idea Incubator
Jeff Skelton
Burrito Enthusiast
I've done both extensively. Synchronous programming with C# and asynchronous with NodeJS. I can completely understand how the patterns that asynchronous programming impose can cause confusion for someone who doesn't have that background. Callback hell is real and I have been there. It sucks... There are many packages available in the npm ecosystem to help us deal programming in this manner that said. My personal favorite is a hybrid approach of q and async's lovely waterfall function. For example:
It might look a little weird at first if one is not used to the pattern but, if you really look, it allows us to better reason about the order in which functions are being executed and control the flow of logic in a saner way. Returning a promise instead of a callback allows us to better chain the wrapper function elsewhere in our code. There are a ton of valid approaches though. This is just what I've come to after much trial and error.