><i>The question is no longer if Node is enterprise ready. The question now is the following: what major digital enterprises will end up being the last hold-outs?</i><p>This is not the question.<p>The question is:<p>1) is Node.js type tech good for my particular project (enterprise project or not).<p>2) is Node.js a well designed example of it's kind of technology?<p>IMHO the answer question 1 is: rarely (most web apps don't need such tech or only need it for a small part of what they do) and the answer to question 2 is no.<p>Go is better designed for the same kind of work (evented, million user app with no callback spaghetti and good memory/performance characteristics). Erlang too, and is also more mature. Ditto for Tornado, Play/Scala/Netty, et al.<p>The cries of triumph for Node being used in the enterprise are meaningless.<p>For one, it is not. It's only used in the more adventurous part of the enterprise, the one that also adopts lots of other things. In the main, the enterprise goes for .Net/JVM business as usual.<p>But more importantly, the enterprise has also adopted extremely BS technologies. From CORBA, to ActiveX, to JavaEE, to SOAP, to XML-for-everything. Didn't do the enterprise any good, and the technologies languished eventually any way.<p>><i>But what makes Node special is the Node community, which is not only incredibly vibrant but also, more important, the only developer community that was built from day one around asynchronous, event-driven application logic as a core principle.</i><p>That's BS too. You don't need a "community that was built from day one around asynchronous, event-driven application logic as a core principle" if you can run things out in a different thread/goroutine etc.<p>Only Node needs that because it's a one trick pony and single threaded at that, so a blocking operation kills everything.<p>Which is bad, because there are tons of useful libs and services that you could use and STILL be asynchronous and event driven, even though they are not.