Just because lots of people say "non-blocking, good concurrency, event-based model" without understanding it doesn't mean it's not correct. With a single-threaded, event-based model, you can get an awful lot of concurrency at reasonably consistent latency without ever thinking about threading issues or managing thread pool size to balance memory and concurrency -- and often with less memory, too.<p>Yes, there are downsides: it's not a natural model for many people; you do still have to consider <i>many</i> complex concurrency-related issues; and control flow libraries are usually needed to make complex code much more readable. But these are either easy to deal with or intrinsic to the complex problem at hand, and the above still stands: once you understand how to program with this model, the "default" implementation usually scales very well.<p>Yes, Node was not the first to do this, but that's not relevant to anything.<p>Besides all that: I'd put Node's postmortem debugging and dynamic tracing capabilities up against any other dynamic environment.<p>As a side note: it's enormously condescending to tell people that a very broad technical choice is not only wrong for <i>their</i> technical problem -- without even knowing what it is! -- but that they're also part of some mass delusion for even thinking that there's anything to it. I hate arguing about this stuff. You keep trashing Node, and we'll keep using it to build large distributed systems.
If you read the interviews with Ryan Dahl, one big reason he chose javascript for his scripting language after considering a number of other options was that javascript did not already have a huge body of blocking libraries.<p>If you're trying to script a nonblocking system where everything is nonblocking all the way up and down the stack, you're going to end up creating a parallel ecosystem to the normal one, and confuse people by not allowing them to do the normal things they would do in language X.<p>Javascript didn't already have a huge blocking ecosystem.<p>And speaking of ecosystem, that's another really good reason to like node. The stream programming that is coming out of the community is brilliant, and the focus on constructing large projects by writing thin modules that use other thin modules ('onion oriented programming') is fantastic.<p>I've been doing a lot of Scala recently, and it's extremely noticeable that despite the languages power to do things in many different ways, the Scala community frequently seem to choose a strangely convoluted path filled with hidden magic going on behind the scenes where every new library you depend on feels like learning a new language from scratch.<p>It might well be that the Go community is also as good as the node community for some of this stuff, but the community and library ecosystem is a definite plus point.<p>Personally I've never had a problem with Javascript coding. It's perhaps easier to write stupid code in it than a lot of other languages, but I know it well enough to know where to be disciplined, and it almost never surprises me now.
This is the article I'm going to refer people to to explain the problems that I have with nodejs. All of these (absolutely true) observations aside, I really like how the the nodejs trend has brought concurrent async-style thinking into the mainstream of web programming.<p>By "all of these observations aside," I mean that I <i>hate</i> working with it personally, and I'll be using Erlang/Webmachine thank you, but I learn new ways to think about modern problems every day from many of the great people that are part of the nodejs juggernaut.
Sarcasm is pretty heavy in this article, but I think it's a little overly negative...<p>He makes a lot of comparisons with Go, but Go was created after Node. Many of the languages he notes as possible replacements for the non-blocking rant are obtuse (I love Haskell, but there's no way it's not obtuse)<p>[EDIT] - turns out they were made pretty much at the same time 2009... Learned something today, I guess. Felt like Go came after node to me but I guess it didn't<p>Also, I must be the only one that doesn't really mind callbacks. Maybe it's stockholm syndrome.<p>I also think node should get kudos for at least seeming different enough to prompt the move from enterprise customers. Any move away from burdened "enterprisey" software is worth praising I think. Not because java is bad/lame by default, but instead because it might prompt other companies to lust after something new that might be better (whether it's python, node, go, or haskell is irrelevant)
I agree with a lot of the arguments in the article, but I do feel a very negative opinion about Node.js. I don't believe Node.js is that bad.<p>The 2 points I always hear from Node.js are:<p>1) Node.js is fast. It is really not that fast. It all depends on what you are comparing it to.<p>2) It is easy to learn. It is not easy to learn. The difference between browser javascript and V8 javascript are considerable. Not everybody will pick it up as easy as you imagine, specially if you are choosing Node.js to allow frontend devs work on backend code. It is a very different mindset.<p>I like the idea that is Node.js, but I don't think it is mature enough to take over the backend. I think there are other more mature languages right now that do the job without making programs look like spaghetti code.<p>I think people should take this article with a grain of salt, and keep getting their hands dirty in Node.js. I think it has a future in the cloud.
Why is it that most of the articles which pop up complaining about node's concurrency options don't even mention streams? For most data-manipulation tasks, FRP-style composition of higher order operations on streams turns out to be the best choice; not callbacks, promises, etc. Not even bringing them up in a discussion of concurrency in node makes it hard to take the article seriously.
I love your ending :) "Does your local Node.js Meetup group need a presenter? I am available for paid speaking engagements. Email me for more info."
I prefer <a href="http://silkjs.net" rel="nofollow">http://silkjs.net</a><p>It handles each request in a forked subprocess so it's a lot more straight forward.
We learnt that Node wasn't cancer, but it also wasn't a good technology either. Still, it was useful in keeping the clueless muppets away, lest they fuck up other tech ecosystems.
These articles always seem to boil down to only one thing- "I'm bad at callbacks".<p>I mean, really, is there any other criticism here? There is a valid point about the true nature of Walmart and Paypal's rewrites, but that's pretty tangential.<p>There's kind of a thing about some completely rookie mistakes in error handling, but that's really not relevant to anything, and again, tie into the "I'm bad at callbacks" thing.<p>I'd really be interested in some criticisms of node that aren't variations on stories of the author's past difficulties with callbacks, as most people who use node have no problems with them.<p>EDIT: Downvotes? Please, point out to me the part of the article that is not about callback troubles.