No, not “because I said so.” The best reason to pay attention to node.js is the audience that is paying attention to it. Joe Shaw’s pointer the other day was just the latest in a string of node.js mentions. By now you’ve probably heard that the folks from Heroku recently – as in two weeks ago yesterday – announced experimental support for the project to a shortlist of their users. Less visible are projects such as the Gilt Group funded real-time web analytics project Hummingbird (that link’s courtesy of Jeff Waugh), currently a trending repo on Github, fanout.js – a node based pubsub messaging server (that one’s via Dion Almaer), or others like nodewiki, a wiki built from node and Redis.
What is node.js? For the technical audience, Joyent’s Ryan Dahl’s (the original author) presentation is an excellent place to start. Wikipedia describes Node.js is an evented I/O framework for the V8 JavaScript engine (yes, the one that ships with Chrome), while Dahl’s deck describes it more prosaicly as a “set of bindings to the V8 javascript VM” that allows developers “to script programs that do I/O in javascript.” Conceptually, it’s not dissimilar to EventMachine or Twisted, but node.js takes the concept further as Heroku’s Adam Wiggins covers here.
A few reasons you should be paying attention.
- It’s Opinionated Software:
Implicit in node is a fundamental rejection of traditional I/O. It’s pushing an asynchronous agenda with its event loops, based on the assumption that concurrency cannot be achieved with a thread per connection. Having just recently suffered through a Daring Fireball induced meltdown of RedMonk.com as Apache spawned dozens of threads, each waiting for the connections to complete, I’m sympathetic to this perspective. While I’m skeptical of the claim that the reasons the approach isn’t more common are predominantly cultural and instrastructural – debugging large asynchronous applications would seem to be a real challenge – the benefits clearly outweigh the costs for a large number of developers. I also find node’s architectural decision to restrict multiple thread access to C bindings rather than Javascript – throttling access to experts, at least in theory – interesting. - It’s Fast:
Speed is a feature, remember. And by all accounts, node.js has this one in spades. Even as we’re told in Ryan’s presentation that it’s a “silly benchmark” that should be taken with a “grain of salt,” node’s ability to field more requests per second than nginx – even with much higher memory consumption – is startling. Because nginx itself is not slow. The focus on performance, at a very fundamental level, is clearly paying dividends. - It’s Javascript:
Well, 15% of it is, anyway. And from a developer’s perspective, the engine is Javascript as are the standard libraries. The evolution of people’s thinking with respect to Javascript has been interesting to watch. Beyond the hype around its central role in the Ajax browser based application revolution, it’s become if anything more important over time. It’s the second most common language on Github (next to Ruby), and is being often portrayed, alongside HTML5, as the last, best hope to save us from a future of proprietary web interfaces. E.g. Gordon, the Flash runtime written in Javascript. The really interesting question to me, however, is whether or not we’re going to see more server-side applications like node.js written partially or totally in the language. If Ted Leung’s correct, and I certainly trust his judgment, the answer to that question is yes. - It’s Aimed at Important Problems:
Designing scalable applications is hard. But the speed at which node.js applications can be built, whether that’s messaging/proxy/web/etc servers or user facing applications like wikis, is impressive. It would be inaccurate to say that it trivalizes developemnt, and I suspect that as applications built on node grow in complexity the fundamentally different architectural approach it takes will introduce as yet unanticipated problems, but the class of problems that node.js is aimed at are important. Scalability isn’t just a challenge for Facebook or Twitter, nor is performance solely the province of Google. Those qualities are going to be at a premium for all applications going forward. - It’s Community Supported:
The visibility of the project we covered above; here are just the Twitter pointers to the Github repo. But just as interesting has been the support. The project is 70 contributors strong already, and the contributions as depicted in the graph above are non-trivial in their substance. And at 174 forks, node.js is only 59 behind jquery. The project is popular, in other words, and with most of it MIT/BSD licensed, the barriers to adoption and contribution are few.
