If you’re anything like me, you’re probably pretty sick of the whole node.js debate. Node has been called cancer (which Ted Dziuba called it in a rant which isn’t linked here because it has now been removed from his personal web page). It’s probably been called much worse. It’s been sardonically labelled as bad-ass rock star tech in an admittedly hilarious video. You’re probably even sick of talking about how stale this discussion has become.
Fortunately, the node community couldn’t be bothered with any of this malarkey. They’ve been quietly adding something like 50 to 100 new modules a day to the Node package manager (NPM) library. Node hasn’t even seen a 1.0 release yet–actually, they just released version 0.8.0 on June 25th–but it has already come light years as a framework and now has a developer ecosystem surrounding it that could well be unparalleled in the open source community.
Now, there are signs that the discussion surrounding it is maturing as well. This article by Shravya Garlapati, discussing LinkedIn’s use of node, came into my Hacker News feed the other day, and it’s really a breath of fresh air.
Why? Because it’s the kind of piece that I wish people had been publishing about node all along. It treats node as one tool among others and discusses its potential benefits and drawbacks; it sidesteps the borderline-religious posturing that we’re all so tired of and cuts straight to pros and cons and to simply trying to provide helpful information; and it gives us an example of a large-scale app making extensive use of node and tells us how they were able to make node more readily scalable.
I’ll mostly let the article speak for itself, as it’s quite insightful and thorough (even offering code samples). But I’ll list the tips that struck me most and why:
- Don’t use node.js for static assets. According to Garlapati, LinkedIn uses nginx for delivering CSS files and images and relies on geographically-distributed CDNs to cull static files from servers around the world. For small-scale apps, node will probably work just fine, and the author would probably agree. But for larger apps with loads of hefty CSS files and bulky JPEGs, this strikes me as sound advice. In general, node’s non-blocking I/O strikes me as better suited to asynchronously managing lots and lots of smaller tasks, not passing around big BLOBs (binary large objects).
- Avoid synchronous code. This tip reminded me of a post that I read from node core contributor Felix Geisendörfer on appropriate and inappropriate use cases for node. He advises strongly against using node for things like “simple CRUD/HTML apps” on the grounds that there is simply no reason to use node to the exclusion of other frameworks for those purposes, which are easily served by Ruby, PHP, and others. If you find yourself needing to do lots of things that wouldn’t directly benefit from non-blocking I/O, then you should seriously consider either using something else or using node more selectively than you have been.
- My intention here is not to unqualifiedly endorse any of the above recommendations. I’m sure they will generate plenty of principled disagreement (as they already have in the comments).
But if you’re a node developer or interested in node, please make sure and (a) take her arguments very seriously, particularly in light of the scale and success of LinkedIn, and (b) use articles like this as a model for future node-related discourse (in lieu of this).