I think the opinions expressed in this article are valid. However, I don't think the inability of current JavaScript to do async I/O without callbacks is Node'

I think the opinions expressed in this article are valid. However, I don't think the inability of current JavaScript to do async I/O without callbacks is Node's biggest problem. As others have said, it works for smaller projects (and even has some geek appeal). And as Havoc Pennington and Dave Herman have explained, generators (which are coming with ECMAScript Harmony) and promises will eventually provide a very nice solution. So Node has a path to grow out of the callback model without giving up its single threaded paradigm. http://blog.ometer.com/2010/11/28/a-sequential-actor-like-api-for-server-side-javascript/ http://blog.ometer.com/2010/11/28/a-sequential-actor-like-ap... http://blog.mozilla.com/dherman/2011/03/11/who-says-javascript-io-has-to-be-ugly/ http://blog.mozilla.com/dherman/2011/03/11/who-says-javascri... The bigger problem (which I don't see getting solved anywhere down the road) is the lack of preemptive scheduling, which is available in Erlang or on the JVM. What you see under high load with Node is that latency is spread almost linearly over a very wide spectrum, from very fast to very slow, whereas response times on a preemptively scheduled platform are much more uniform. http://jlouisramblings.blogspot.com/2010/12/differences-between-nodejs-and-erlang_14.html http://jlouisramblings.blogspot.com/2010/12/differences-betw... And no, this is something that can't be solved by distributing load over multiple CPU cores. This is problem really manifests itself within each core, and it is a direct consequence of Node's single threaded execution model. If anybody knows how to solve this without resorting to some kind of preemptive threading I'd be very curious to hear about it.