(Comment repeated from proggit, where this was also posted.) Don't get me wrong here, I love coding in Javascript and have often entertained the idea that serv

(Comment repeated from proggit, where this was also posted.) Don't get me wrong here, I love coding in Javascript and have often entertained the idea that server-side Javascript would be fun. I also totally buy the need to get away from thread-per-request for many web serving scenarios, Comet being a perfect example. However when I see someone going so far with this as to say "all APIs must be non-blocking" I have to wonder if they would be better served by using a language where threads were less expensive. I know closures make this kind of thing a lot less of a pain than back in the day when we were programming against OSs with no threads and async APIs were often a necessity, but to mandate this style is basically asking developers to manually rewrite all of their logic into continuation passing style. It's a bit, well... naive is the kindest word that comes to mind. BTW, I don't think it's a coincidence that all of these event-driven web frameworks are for interpreted languages with crappy thread support.