I think Python has made me sufficiently lazy that now every Java method I create ends with throws Exception.

Where Did Node Go Wrong?

And, did it?

My opinion is that node.js isn’t the kind of thing I should be using for the work I am currently doing, mainly because I don’t think it’s mature enough, and because it’s simply too difficult to use in real-world problems and gain the efficiency it claims.

(I’m even talking about it here because there is a misguided push where I work to ship production code on top of node.js. So I have a vested interest in explaining, in detail, why I think this is a bad idea, because I actually would rather babysit a bunch of Java code instead of this abomination.)

Anyway, where did the fanciful notions of efficiency in node.js come from? Let’s go take a look.

So, we nerds remember back in the day this website called Slashdot. For the children just joining us, it was kind of like Reddit: there would be a story or a link, a bunch of comments under that, and a swarming horde of nerds at their computers clicking on the links posted there. Generally, for your average gee-whiz I put up a website website, the huge amount of traffic this link generated would crash the web server. We called this “slashdotting,” as in, “my site got slashdotted!” There’s variations of this nowadays, when someone links to a WordPress site or to a Tumblr: “fireballed,” “reddited”.

So people have been consumed with the problem of serving thousands and thousands of connections over the network, most prominently on port 80 and serving HTTP traffic. Dan Kegel maintains an excellent web page that explains the problem, the C10K problem, and the various ways of handling it. In particular, anyone who’s interested in this topic likely has read that page, as well as this wonderful slide deck that presents the issue well.

The tl;dr of that? If you want to scale to 10,000 or more clients, your server can’t use a thread or a process per connection, because it just doesn’t scale (not even on Linux, which is kind of astonishingly good in all the benchmarks). You’re better off using an API that tells you when there is activity on a socket and non-blocking I/O in a single, or in a handful, of threads.

I’m not certain of the timelines here, but people have taken this advice to heart, and have written servers that use an async I/O notification system to handle clients, instead of giving Apache more and more RAM. I remember seeing thttpd as a cute, simple example of the idea. Today we have some pretty sophisticated servers executing this idea. Generally, these servers can beat Apache at serving large numbers of clients.

So, nonblocking, asynchronous I/O is a good idea, and has been proven.

The idea then, is: if we wrap a fast JavaScript interpreter (and yes, nobody is arguing that V8 isn’t a state-of-the-art piece of software) around an event loop that uses a scalable I/O polling mechanism, we can write very-high-performance socket servers in JavaScript!

Well, it kind of works. The toy servers that node people have written and benchmarked do go fast, and they don’t take a whole lot of code, but they’re also trivial. Here’s the key point, in case it hasn’t sunk in yet: node, by virtue of using asynchronous I/O in an event loop, does not equate to an efficient platform for all uses.

Yes, you know what? Writing a non-trivial, highly scalable server in node is just as hard as it is in any other language! Even more so, in my opinion, because its callback hell makes code that much harder to understand and maintain.

Maybe I’m wrong, and that this is the new paradigm, and people will write some kick-ass servers in it. I might just be too old and set in my stubborn ways. But I’ll still stick with anonymous nested interface implementations over callback spaghetti, thank you very much.

(Also, one final aside. I’ll start having better confidence in node once its users start speaking like adults. I gave up on a project after reading this in the fucking README:

Think this is sexy?

Contacts.all({httpAuth: base64("coolaj86:secret"}).limit(30).render();
// all - makes request to two servers to get contacts
// limit - takes the first 30 contacts
// render - some function to render the contacts

So do the ladies. Now read up on the API.

I miss Slashdot sometimes. Not a lot, though.)

Programming can be phenomenally boring sometimes. Right now, I’m going through code to update it for an API change in a third-party library I’m using, and it basically amounts to making almost the same change, over and over and over and over again. And it’s not easily turned into a regular expression, so it looks like it’s all by hand from here out, no automation.

In the end, though, I’ll have this crap up to date with more robust error checking. Clearly a worthwhile endeavor.