[silentbicycle]

This response misses the point, which is just that it's trivial to show that you can write blocking code in node. Any program that does significant computation will still block and pause all network IO (without setting up side processes, etc.). "The stupid fibonacci benchmark" is just a cliche way to chew up the CPU.

My main beef with node.js is the hype, to be honest. Many of the people who are really excited about it seem completely unaware that this kind of thing is hardly new. Tcl has been based around an event-loop for ages! Erlang was made in the mid-80s, and has a very mature (and thoroughly integrated) event-loop-based architecture. Also, its focus is on fault-tolerance / error handling in a multi-node system. I don't know what progress Node.js has made there, so far.

[maratd]

Virtually every request made to the server is blocking. The point of a server request is to retrieve/store data, process it, and respond. That's a blocking operation by definition. I can't respond before processing the data. I can't process it before retrieving it. You get the picture.

The neat thing about node.js isn't that it's "non-blocking" ... every major HTTP server out there is "non-blocking" in the same way. The neat thing is that it's JavaScript. I can use the same language on the server side as on the client side. I can use the same libraries, etc. reducing my code footprint. Reduced code footprint = less maintenance, fewer bugs, easier coding.

[silentbicycle]

Indeed. I think that's a big part of the actual reason for its popularity. This "ultra scalable" stuff has helped to draw attention to it, though.

[count]

Heh, wasn't VB5/6 also event-driven?

[silentbicycle]

I'm not familiar with it, but that would make sense. GUI systems are often built around event loops.