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.
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.
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.