I disagree with this. Handling one blocking operation is as easy as handling n blocking operations. Yes, you have to handle them, or they will block.
The alternatives are to run everything in its own process, which uses too much RAM or to use threads, which are very difficult to reason about. (Did you really acquire locks in an order that guarantees you will never deadlock? Is your date formatting library threadsafe?) Finally, there is threads and STM, but STM adds overhead and retrying transactions wastes resources.
None of those solutions are very good, and node is in the same place: it is another not very good solution to concurrency. Right now, nobody in the world can come up with anything better. To do concurrency right, you have to be very careful, and those caveats apply to all the other concurrency mechanisms. node's event model is basically equivalent to the other mechanisms; fatal if done wrong. Doing one thing in one place makes the process model work. Not having any state shared between application operations makes threads work. Event-driven systems are a compromise between the two: you can share state between logical threads of execution, but the order in which state updates occur is deterministic.
Every model has its strengths and weaknesses, and node has strengths and weaknesses.
The alternatives are to run everything in its own process, which uses too much RAM or to use threads, which are very difficult to reason about. (Did you really acquire locks in an order that guarantees you will never deadlock? Is your date formatting library threadsafe?) Finally, there is threads and STM, but STM adds overhead and retrying transactions wastes resources.
None of those solutions are very good, and node is in the same place: it is another not very good solution to concurrency. Right now, nobody in the world can come up with anything better. To do concurrency right, you have to be very careful, and those caveats apply to all the other concurrency mechanisms. node's event model is basically equivalent to the other mechanisms; fatal if done wrong. Doing one thing in one place makes the process model work. Not having any state shared between application operations makes threads work. Event-driven systems are a compromise between the two: you can share state between logical threads of execution, but the order in which state updates occur is deterministic.
Every model has its strengths and weaknesses, and node has strengths and weaknesses.