This time I'll argue the other side. A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do someth

This time I'll argue the other side. A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality. An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).