On Tue, 2011-10-04 at 09:11 -0600, Richard Esplin wrote:
> I have never played with node.js, but I hear lots of hype. Today twitter directed me to this article:
> http://teddziuba.com/2011/10/node-js-is-cancer.html >
> Anyone have an informed opinion on the thesis that Node.js is cancer?
tl;dr No, node.js is not a cancer, but it also not a general purpose
It's a shame that such a low content blog post is getting so much
attention. The author obviously took very little time to understand what
node is and where it might fit in a larger architecture.
(1) The author points out that performing CPU intensive work will block
the entire node process. Borrowing the author's own tone: no s***,
Sherlock. That's one of the first things taught in any decent node.js
introduction. Not hard to deal with.
(2) Some mumbo jumbo about Unix and CGI. Honestly, I have a hard time
finding a coherent thought in this part of the essay.
First he claims, without citing any proof, that the preferred solution
is to "use [node.js] to serve production traffic". Depending on what
you're doing, that might be true. For example, if you're building a chat
server there's really no point in repeatedly proxying through something
else. But for serving static media, I would disagree. Except during
development, I've seen no recommendation to deploy node.js alone.
In the next paragraph he claims that if you google for advice, most
people recommended putting nginx in front of node.js. This is the exact
sort of architecture he seems to be advocating in the previous
paragraph, yet somehow by this paragraph it becomes unacceptable.
Apparently because node.js requires multiple processes to take advantage
of multiple cores. I guess he hasn't noticed that many people still use
the Apache pre-fork engine without catastrophic results.
He make a big deal that node.js is built around HTTP. In other words,
instead of using mod_wsgi or mod_jk you'd use mod_proxy to connect
Apache to a node backend. I'm not sure how this is equivalent to cancer,
but there you have it.
it's not really a point worth debating.
(4) Node.js is definitely not a competitor to Java. Nor is it an exact
competitor to Python/Ruby/Perl. It's more a a competitor with Erlang,
but only if you squint and tilt your head.
Some things in node.js are a much bigger pain. For example: Writing
non-blocking code without syntactic sugar is painful. ORMs are in their
infancy, and it's not clear the node community will ever care enough to
create a great one. V8 is obviously designed for desktop use, not big
Some things are much, much easier. V8 trashes Perl/Python/Ruby for
performance and memory usage. Node's creator is committed to keeping it
small and understandable. There's little danger of accidentally doing
blocking work in what should be a short, asynchronous architecture. The
potential for reusing validation code in both the front end and back end
Low CPU, asynchronous, long connections like chat is a pretty obvious
use for node. But so are infrastructure tools. Of all the CSS generators
I've evaluated, Stylus is most beautiful. Using node.js to integrate
uglify-js and JSLint or JSHint into your deployment process
just makes good sense.
And that's just the tip of the iceberg. Right now Node.js is
experiencing a cambrian explosion of interesting new libraries,
frameworks, and tools. I haven't personally shipped anything based on
node.js yet, but it's definitely a technology worth keeping track of.
The opinions expressed in this message are the responsibility of their
author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG.
List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list