Node Isn't...

Alex R. Young





tutorials node essays

Node Isn't...

Posted by Alex R. Young on .

tutorials node essays

Node Isn't...

Posted by Alex R. Young on .

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

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

  1. Read the homepage, carefully!
  2. Read the V8 Design Elements
  3. Read great posts on the Google