The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about t

The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client. Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core. Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.