Node.js is Cancer
teddziuba.com
teddziuba.com
Author picks out a software developer whom he considers is Doing It Wrong (TM), and tells them they're Doing It Wrong (TM).
The author seems to think that the world would be a better place without Node.JS, evented IO and server-side JavaScript, and rather than putting together a concise (or coherent) argument about the pros/cons, he decides to go after Ryan Dahl himself. I'm tired of the number of S and F-bomb dropping, rockstar programmer mentality-wielding morons who clog up the innovation space, and have nothing to contribute but FUD and nay-saying.
We're developers. We create. We find itches and scratch them. Node.JS is the result of Dahl scratching his itch, and a lot of us see merit in the project. Some very smart people (I'm tipping my cap to the people at Joyent, here) are actively addressing Node's rougher edges, so we'll see constant improvement. It's still relatively young (especially compared to the holy UNIX), and so what if it doesn't solve all of your problems; there's room for everyone to play in the web server scene, even JavaScript.
You probably shouldn't be trying to beat nginx or apache with node.js. That is a solid point. A couple years ago, I would have said you probably shouldn't try to beat Apache. I'm not saying it can't be beat; I'm saying you're not Igor Sysoev.
Javascript probably isn't the best language for an important scalable application on the server. It's getting better. But there's a reason Google and friends have to make some serious improvements. Don't get me wrong, I Love Javascript. It's one of my favorite scripting languages.
I love PHP as well (another language Ted just took a stab at). But I won't pretend PHP will some day be the best way to make an Android app. Sure, if someone added a PHP interpreter to Android, I might consider prototyping with it. But when it's time to shoot for production, it's going to be Java. Obviously.
Our languages are tools. Ted happens to think Javascript is the wrong tool - and in most cases outside of the browser - he's probably right. I'm using it for a pretty large project right now. I have pull requests to a few npm modules and few new npm modules to add, and a few thousand lines of code tying them all together.
But once our concept is proven, I assure you, Node will probably be the first thing to go. Not from my toolbox, just from the project that will have already outgrown it. It's not the right tool for the job when we scale beyond a couple servers. But for right now, while figuring out what goes where and why, there is none better.
For now, when building serious apps, Node is the first thing to go; in the near future, it may be the first thing to introduce.
If you're worried about the maturity of its library, availability of good developers, or just that JS is an ugly language (and Coffee-script is too boutique), or Java is just faster, that's a good reason. Though there are lots of people who use the slow and ugly PHP (which seems to get good milage - Facebook and Wikipedia are doing OK with it).
I don't like JS, so I wouldn't use Node, but that doesn't mean it's crap.
Yes, an async framework is not the panacea for everything. That has been known for a long time with similar frameworks for Python/Java/... It makes some things easier/faster and other things harder. But why act like this?
One minute, he's ripping into Tornado, because it's under-engineered. Then he thinks Twisted is over-engineered. Next, Node.js is crap, because it doesn't do things his way. Then there's NoSQL, which he hates, because it's not MySQL. No idea what he thinks of PostGres, he probably thinks it's got too many features.
Point 1: A Scalability Disaster Waiting to Happen. No, node.js is not a scalability disaster, and even if it is, doesn't Ted advise developers not to worry about scalability as they are only going to get ~3 long-term users in the first year?
Point 2: Node Punishes Developers Because it Disobeys the Unix. Um, you can put it behind nginx, and that buys you a lot of "separation of concerns". Honestly, he mostly seems to be insulting node.js programmers, suggesting that they don't bother to create full production systems - quote "let's be honest with ourselves here, if you're a Node developer, you are probably serving the application directly from Node, running in a screen session under your account." This seems to be really the core of his concerns - Node is easy for one guy to setup a working website. Isn't that a good thing?
Point 3: It's Fucking JavaScript. Which I guess is good if you are a JS expert.
He swings between two extremes - everyone using simpler tools than him is a retard who needs to man up and learn to program, and everyone using more dangerous tools should stop beating their chest and actually implement (premature optimization, guys!) In the case of node.js, he seems to believe both points, which I suspect is because he just doesn't like the toolset.
This sounds to me like Ted's a classic Blub programmer.
Having not played with production Node.js, I'm no expert. But the impression I get from the post is not that. Aside from his attack on javascript syntax (which I agree with, but can be fixed by using coffeescript) his real statement is that perceived simplicity leads to problems. If node is easy for one guy to set up a working website, did we just enable one more badly written and unstable website? We've seen countless examples of bad websites getting hacked and personal information being exposed. As a person browsing the web, I have no way of knowing whether a site is run behind nginx or directly from node. If I give them personal information, I sure hope it's behind nginx. I trust nginx to be more mature and secure than node. But if a new programmer isn't told up front that running directly from node is a bad idea, my overall browsing experience just got a littler riskier.
Maybe. Maybe not.
Many people on this forum have had to rescue or rewrite systems that were built in Access. Access is easy for one guy to set up a database. Isn't that a good thing? Sometimes yes, sometimes no.
Ditto for Excel nightmares.
That said, a prime distinction between Excel/Access and something like Node (and I'd throw Rails in there too, given all the "it's so easy" love it got a few years ago) is open (and open source) and it's easier for the community to work around the issues that come up, release new versions quickly, and fix the bad parts faster than with closed solutions like Excel/Access.
But... just because something is easier to use doesn't mean it's the best tool for all use cases - really nothing is best for all use cases. :)
Haven't done much with Node beyond Hello World stuff - tried to install and use zombie, but couldn't get it to work.
Build a straw man argument picking a useless example exploiting a known design limitation of a particular design choice and use it to tarnish everything about it.
Unfortunately this doesn't tell node devs anything new, fuels node haters and presents deceptive information to devs unfamiliar with event loops or the scalability problems inherent with Blocking IO.
Just think about this:
A poorly designed application will perform badly on any framework. While many programmers understand more sequential application bottlenecks, event driven bottlenecks can be hard to understand for "less expert programmers".
Ted thinks Node.js doesn't adequately inform new developers of its pitfalls, and it is developing a "Node.js makes everything faster" mentality.
Just take time to do things correctly and Node.js (like any other tool) can be a great design decision. Just understand that you need to write good code to get the promised performance improvements.
Additionally, proxying behind nginx or some other server is a good idea.
Hi, Hrishi. There is a grain of technical merit in two of his three objections, but he trollishly overstates them. I've had to think about some of the same questions lately, so here are some thoughts. If anyone has a substantially different perspective, I'd like to hear it.
By the way, the most interesting thing about his critique is that he doesn't even touch on the most common objection to Node, that async callbacks don't compose well and so break down under complexity. That one's been argued to death on HN, though, so I'll follow his example and leave it out of this.
Let's consider the criticisms in reverse order. #3, about Javascript, we can dismiss as a vacuous language flame. #2 is about separation of concerns. He argues that web servers should be separate from web apps, and Node confuses the two by doing web server stuff (handling HTTP requests) and app stuff (whatever your app does) in the same context. Now you either have to put a "real" web server in front of Node (in which case there's the question of what value Node's adding) or use a relatively immature web server (Node itself) as your front end. There is a good point about modularity here. But is the line between web servers and web apps always so clear-cut? If his argument were completely true, CGI would be perfect for everything. Most people wouldn't agree with that. Moreover, you wouldn't see complex configuration languages and extension APIs for web servers, the kinds of things that arise when the lines start to blur (and are not very pleasant to work with). So the question is just how separate the concerns really are. This surely depends on the application. Separation of concerns is a good thing until interactions between modules become unduly complex, at which point one sometimes gets a big simplification by unifying them.
For example, in the project I'm working on, there are resources that need to be requested by the browser and sometimes also by the (app) server in order to complete some computation. You could divide this work many different ways, but it sure is convenient to just write Node handlers to do whatever I/O you need in the course of completing a request. To have the app server go back to the web server would be awkward, and so would having two different ways of fetching the same stuff.
#1 is about blocking. He refutes a blurb that says "nothing blocks in Node" by showing a trivial example that indeed does block Node by doing a long computation in an event handler. (One wonders why he didn't go full retard and just put an infinite loop in there.) This is a deliberate misreading of the blurb, which obviously meant not "nothing blocks" but "no I/O blocks". So, a straw man. But dig deeper and there is a valid point nearby. If you have long computations to do while fulfilling a request (where "long" is defined as "taking longer than you're comfortable having all other requests to this server wait"), then for Node to work well, you have to farm those computations out to other processes. This is doable, but adds complexity. You start to move out of Node's sweet spot.
What's the sweet spot? If writing your server code in Javascript is a win for you and your app is I/O bound (more precisely, if there aren't any long-running computations as defined above), Node looks pretty good. If in addition the app server and web server have more complex interactions than just "here's your request" and "here's your reply", it starts to look really good. An example might be a web chat app.
As things get more complex, the judgments get trickier. In our case, we do have long-running computations. Bad for Node. But we also have webserver-like needs in our appserver, a lot of I/O that we don't want to block on, and Javascript is a big win for us. So on the whole Node wins. Take away the point about Javascript, though, and it probably wouldn't.
Alternatively, we could interpret the article to be based on the assumption that it's common for people whose knowledge of how computers work is so poor that they believe everything north of the southbridge happens instantaneously to be put in charge of making major design decisions for high-traffic sites. But that seems less charitable to me, since it replaces a simple straw man with something approaching delusional paranoia.
"Because nothing blocks, less-than-expert programmers are able to develop fast systems."
That's bit he has a problem with. From your post:
"If a programmer doesn't know how his tools work well enough to foresee any potential gotchas and take steps to avoid them, that's a fault in the programmer rather than the tools."
Both of you are saying that a programmer needs to know his tools well. Ted says that Node.js doesn't encourage people to understand the limitations of an event driven framework well enough.
All you good programmers out there: Keep using Node.js. It is a great tool and does things well. But don't pretend that it's the snake oil to make everything faster. The design decisions YOU make have the most impact on the speed of your application.
As some Joyent guy was saying there's real resources behind Node.js, it isn't just a cool hack made by some promising Jedi but it needs to fit your use-case. If you're designing a real-time web app and you have a limited budget then go for it, I don't think there's anything better out there now (except for Tornado, Twisted, which is just a matter of taste) unless you're Yahoo, Google, etc...
Someone doesn't know about the "foo == null" idiom (it's true if and only if x is null or undefined).
Not to mention the fact that the "typeof foo == 'undefined'" thing is overly defensive "best practice" that people keep needlessly repeating, IMO. If someone is stomping all over important fields of the global object, there's nothing you can do.
JavaScript has its issues, but this one isn't fair.
(preface: I am by no means a javascript guru)
Really? Double equals in javascript? I thought that was a no-no due to the type coercion that "==" does.
I get a reference error when I crack open a console and try your example idiom.
And yeah, it's double equals. The coercion is exactly what allows "== null" to do the right thing in the presence of undefined. Contrary to popular belief, "0 == null", "'' == null", and "[] == null" are all false in JavaScript. "foo == null" doesn't test for falsiness, it just checks whether foo is null or undefined.
I guess he didn't look at node for long enough to realize that it's a low level platform, not an http web framework.
a rant about a software he doesn't even use....
First he completely misrepresents the point that Node performs well and scales is because it doesn't Block I/O, i.e. the biggest bottleneck in scaling highly concurrent applications.
It's hard to actually pull out any facts or points to dispute since he sounds like a whinny troll on a rant, hand picking disingenuous examples that are obviously going to trip up event loops, something everyone programming against an event loop already knows. A clearer example would simply be:
while(1);
If for some reason he really needed to calculate high fibonacci numbers on a web server he could simply memoized the fibonacci function, and get back your stellar response speeds (on a 2yo Macbook air):
function memo(f) {
return function (x) {
f.memo = f.memo || {};
return (x in f.memo)? f.memo[x] : f.memo[x] = f(x);
};
}
fibonacci = memo(fibonacci);
~> time curl http://localhost:1337/
fib: 165580141
real 0m0.023s
user 0m0.009s
sys 0m0.005s
And in his quest to poison JavaScript he choses an code example that no one actually uses, since it can be expressed in the more concise equivalent:
if (my_var != null) {
// you idiots put Rasmus Lerdorf to shame
}The OPs point wasn't that you couldn't write faster code with non-blocking I/O. His point was that just having non-blocking I/O isn't always going to make things faster. Sure, most applications get lucky and have faster implementations, but it is important to understand what is happening behind the scenes in order to avoid hanging yourself. He thinks the Node.js community has not emphasized that understanding at all and the hype around Node.js is leading to badly written applications.