>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?
This is not the question.
The question is:
1) is Node.js type tech good for my particular project (enterprise project or not).
2) is Node.js a well designed example of it's kind of technology?
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.
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.
The cries of triumph for Node being used in the enterprise are meaningless.
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.
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.
>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.
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.
Only Node needs that because it's a one trick pony and single threaded at that, so a blocking operation kills everything.
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.
In response to question 1: yes, it often very much is, as the examples that I raise in the article show. It could well be the case that there are better technologies for this kind of thing according to certain metrics, but those technologies don't have anything even remotely approaching the Node community driving them. In open source anything, that is decisive. Erlang is more mature, yes, but the community is small and highly insular. Tornado, Netty, etc. also do non-blocking I/O and the like, but they simply don't have the same inertia behind them. That inertia could be precisely what makes Node stable and acceptable for ever-broader enterprise usage. But overall, my claim is more sociological than technological.
I'm personally ignorant of Go because I haven't used it yet, but Node being single threaded isn't as big a deal breaker as you'd imagine. If you use it like other environments, you'll code yourself into a corner, but if you instead rely on forking and interprocess communication on the same machine or communication between node processes on separate servers, you end up with an acceptable concurrency model. The single threaded nature of Node generally promotes horizontally scalable designs.
I want to try Go myself, but node isn't as awful as you think.
This is not the question.
The question is:
1) is Node.js type tech good for my particular project (enterprise project or not).
2) is Node.js a well designed example of it's kind of technology?
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.
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.
The cries of triumph for Node being used in the enterprise are meaningless.
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.
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.
>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.
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.
Only Node needs that because it's a one trick pony and single threaded at that, so a blocking operation kills everything.
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.