Just as this story came up I was watching the video of Ryan Dahl explaining Node.js (someone had shared this link in the recent thread about the event loop)
In it, Ryan makes an important point about JavaScript being a natural fit because it was designed for a constrained environment. In particular, there is no way of doing I/O in JavaScript's traditional browser environment without providing a callback argument (I'm not counting interacting with the DOM as I/O here, and a couple of pedantic exceptions pointed out by judofyr below), and for the way in which the browser guarantees that only one callback will be executed at a time.
I think this idea of a constrained environment is very important. If blocking I/O functions are strewn about the APIs you have at your disposal, then programmers tend to default to using them.
The other point he makes is that often evented APIs are just missing from the underlying platform. Does every way of doing some sort of I/O in the universe of Python APIs have variants that take callback arguments? Even if the answer is 'yes' (which would surprise me) there is a minefield of blocking calls one would need to avoid in a disciplined manner.
...which may not be easy. Tell me: does myAwesomeFunction() do some blocking I/O under the hood? You can't tell from the name. Do the docs always make that clear, and provide an alternative with a callback?
Edited to include judofyr's exceptions — which bolster rather than undermine the point, because note that window.prompt's raison de'etre is to block for user interaction, and document.write is a RAM operation rather than disk or network I/O.
I would hardly call window.prompt and document.write i/o since they never hit disk or network (to over-simplify). They're more like manipulating an object in memory.
For real i/o in JavaScript, look at AJAX: Callback based.
You are entirely right. In my mind use asynchronous for what it is good for, but use as little as possible. Delegate app logic to a synchronous threaded worker pool unless you absolutely cannot.
The problem with other even-driven frameworks out there is that they have too much existing codebase that is blocking, which is why Ryan Dahl went with javascript. It had no preconceptions how to do things, and didn't have a large library of modules and code that it would need to interface with that caused it to block.
Python isn't slow by any means, but I think for what they were trying to do, node.js really fit their use case better. Being able to hook up so many different types of functionality all into one 'application' is really freeing especially considering how approachable it is.
I love Node, but I don't think this is particularly true. I have had no problem writing Event-driven Perl apps that talk to web users, use ZeroMQ, talk to a SQL database, talk to Redis, read from disk, and spawn external processses... with none of those operations blocking.
Look at the AnyEvent:: namespace on search.cpan... there's a quite a bit of stuff there. Everything that Node has, and more.
You should use Node because you like Javascript, not because other languages don't have as good of libraries... because other languages have as good of libraries.
We had built an event-based server in raw Python using epoll. It was fine, and Python is a great language. In my testing with a very early version of node, I found that node was between 4 and 10 times faster than Python.
