Reading back through some of the author's other posts, I see a common theme:
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.
Ok, I also cringed when reading the original post by Ryan Dahl bashing UNIX for its "complexity". I simply assumed that he had had a bad day. But this reply is simply mean and almost reeks of character assassination (very ad-hominem). "cancer", he "wrote code unchecked for years", "braindead"...
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?
And, as other less polite posters have pointed out, some of what he says is debatable. I've read a few of Ted's posts, and while he's smart and a good communicator, he is extremely narrow minded. I'm sure he has his own way of doing stuff, and can implement like a machine using his own narrow toolset, great. No-one can learn to use every tool, and some can just be a giant time-sink (cough Google AppEngine). But that doesn't mean that everyone who uses a different toolset is a complete tool.
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.
"Node is easy for one guy to setup a working website. Isn't that a good thing?"
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.
"Node is easy for one guy to setup a working website. Isn't that a good thing?"
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.
> 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!)
This sounds to me like Ted's a classic Blub programmer.
I've said it before and I'll say it again: While liking Ted's writing is a matter of taste, he makes good points.
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.
So what's stopping you putting nginx in front of node?
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.
Actually, javascript running on v8 sounds like it would (theoretically) be an excellent platform for writing an Android app. It's fast enough and has a small memory footprint compared to java.
I haven't yet used Node for a production app, but (being very comfortable with JavaScript) I have found it invaluable when prototyping concepts and ideas instead of mockups. For now, I keep falling back to Python & Django for the real deal, but I'm keeping a very close eye on Node as a contender, especially as I'm moving into more real-time app development.
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.
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.
If possible, can someone ignore the showers of vitriol for a minute, and comment on the technical merit of his criticism of Node? I ask because I'm a total noob and would like to understand what's being discussed.
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.
Non-blocking architecture is not the be all/end all solution for performance problems. By calculating large fibonacci numbers (pounding the CPU), he causes node to fall apart. Basically, there is no such thing as easy scaling, and any solution advertising such is lying.
My take is that the post is more a matter of philosophy than technical merit.
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.
What a stupid asshole. How else would you expect an event-driven server to behave when you throw Fib(40) at it? The only legitimate complaint entangled in that strewn-out plesh of vitriol is that Node's http server doesn't have some features that one might like in a web server. Putting a proxy in front of Node is not a problem, because Node's strengths (handling zillions of connections with little memory overhead on top of application state, without having to write your own event system) are not abated.
The only thing he legitimately did was build a straw man and knocked it down. 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. Not a terrible fault; any programmer who's honest with himself will acknowledge that he does this fairly often; especially when he's learning new tools. And will respond to the situation by learning from mistakes and writing better code in the future, rather than writing breathless blog rants that smell of (to use the author's language) butthurt.
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.
Guess what! You agree with Ted then. One of the big problems he mentions is the apparently simplicity of an event driven app.
"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.
I normally like Ted's posts, but in this one he either omits or doesn't seem to realize that the reason nginx scales better than Apache is that its workers are non-blocking event-loops.
If I was Yahoo I'd think twice before adopting something like Node.js, but if you're a little guy that wants to scale on the cheap and is willing to take risks because the alternative simply won't work for what you're trying to do, then just use Node.js. Django, PHP, Rails with Apache in front of them aren't designed to handle thousands of persistent connections and it would be far more expensive to scale the traditional web-stacks to handle them.
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...
"if (typeof my_var !== "undefined" && my_var !== null) { // you idiots put Rasmus Lerdorf to shame }"
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.
Right, it doesn't work when you're testing whether foo is a bound name at all. In that case you need to use "window.foo" (or this.foo in Node).
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.
This is a typical troll post coming from someone who clearly doesn't understand what he is talking about. I wonder how would he write a parallel process manager ...
A rant about software that he won't use. Clearly he has done some testing to see how things are, but why would he use something he's convinced is crap?
What a retarded post from a self-proclaimed smart guy.
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);
And the point is this blocks the server 'by design', i.e. no time is spent context switching between threads.
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
If he's going to profess CGI scripts are a superior way of doing things, I want to see proofs/benchmarks since nothing he's said makes me take his word on face value - that and his previous posts he shows he's an actual baiting, troll - so I wont be relying his advice anytime soon.
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
}
"if (my_var != null)" Throws a reference error if my_var is not defined. By checking the typeof it will short-circuit before throwing the error. It is accepted enough to be the default coffeescript implementation of "?" (the existential operator).
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.
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.