Node Isn't...
There seem to be a lot of misconceptions about what Node is and why it’s worth using. This article should help clarify what Node is, particularly for newcomers who are interested in Node but haven’t seen much beyond the hype. In many ways it warrants the hype, and I’m enjoying working with it, but it’s not what many people think it is.
So, let’s take a look at what Node isn’t:
The Only WebSocket Solution
Node is a good solution for writing servers. It also works well with WebSockets. However, there’s no WebSocket support out of the box. True, there are great libraries for Node like Socket.IO-node, but Node isn’t necessarily the answer to WebSockets for current projects.
Somehow people have got Node and WebSockets inexorably linked in their minds. If you haven’t written much server-side JavaScript or Node before, and you’re thinking of using Node for a project that would benefit real-time communication or fast updates, you might be OK with your current platform. If you’re using PHP, Ruby, Python, Perl, or anything else, there are probably libraries that will help write low-latency server-side processes. People have been writing amazing code with Twisted and EventMachine for years.
A Magical Multi-Threaded Scalability Solution
Run a Node process and look at the process list in top. You’ll see that it uses one thread on one CPU. Node doesn’t magically scale code to use lots of threads and every processor.
Node’s homepage itself spells out why Node is good at concurrency without necessarily being concurrent in the typical sense of the word:
Node tells the operating system that it should be notified when a new connection is made, and then it goes to sleep. If someone new connects, then it executes the callback. Each connection is only a small heap allocation.
This is in contrast to today’s more common concurrency model where OS threads are employed. Thread-based networking is relatively inefficient and very difficult to use.
Furthermore, users of Node are free from worries of dead-locking the process—there are no locks.
This is good for a lot of the work we do when building web applications. This may not always be the ideal solution. Certain types of problems that benefit concurrency may better suit threads, because operating systems and modern processors can parallelize threads across multi-core processors.
It’s possible to take advantage of multi-core machines using projects like multi-node — this simply runs more than one Node instance so the operating system utilises each core.
One of the things that makes a lot of web applications perform poorly is IO. Using Node’s evented IO approach gets a lot of bang-for-buck out of hardware. I’ve written a few Objective-C projects that take advantage of threads for things that wouldn’t work as well in Node, but these instances are much rarer than times when evented IO would have helped improve performance.
Tim Caswell wrote a great post to the nodejs Google Group about this in Nodejs for Concurrency.
The Only Server-Side JavaScript Solution
Readers of DailyJS might be surprised that I point this out, but I keep meeting people who think Node is server-side JavaScript. There are other incredible projects out there, like RingoJS and Narwhal. RingoJS in particular evolved from Helma, which was already well-established. It also has some great features, like instant reloading.
Conclusion: How to Get Started with Node like a Pro
Before using Node for your next project, make sure it’s the best solution. It’s wonderful for a diverse range of applications, but make sure you’re clear about what its advantages are.
