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
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
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
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
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
Tim Caswell wrote a great post to the nodejs Google Group about this in
Nodejs for Concurrency.
Readers of DailyJS might be surprised that I point this out, but I keep
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.
- Read the homepage, carefully!
- Read the V8 Design Elements
- Read great posts on the Google