Skip to main content

JavaScript: A Second Impression of NodeJS

When I first heard about NodeJS, my reaction was, "Why would I use JavaScript on the server when there are similar continuation-passing-style, asynchronous network servers such as Twisted and Tornado in Python already? Python is a nicer language. Furthermore, I prefer coroutine-based solutions such as gevent and Concurrence." However, after watching this video, Ryan Dahl, the author of NodeJS, has convinced me that NodeJS is worthy of attention.

First of all, NodeJS is crazy fast. Dahl showed one benchmark that had it beating out Nginx. (However, as he admitted, it was an unfair comparison since he was comparing NodeJS serving something out of memory with Nginx serving something from disk.) It's faster than Twisted and Jetty. That last one surprised me.

Dahl argued against green thread systems and coroutine-based systems due to the infrastructural overhead and magic involved. He argued that he doesn't like Eventlet because it's too magical both at an implementation level and also because he doesn't like multiple stacks. As I said, I'm not at all convinced by his arguments, but it reassures me that he was at least able to talk about such approaches. When I brought them up during Douglas Crockford's talk on concurrency, Crockford just gave me a blank, dismissive stare.

Dahl argued that by using callbacks for all blocking calls, it's really obvious which functions can block. As much as I dislike "continuation-passing-style", he makes a good point.

Dahl argued that NodeJS has an advantage over EventMachine (in Ruby) and Twisted (in Python) because JavaScript programmers are inherently comfortable with event-based programming. Dahl also argued that JavaScript is well suited to event-based programming because it has anonymous functions and closures. Ruby and Python has those things too, but Dahl further argued that it's very easy to accidentally call something in Ruby or Python that is blocking since it's not easy to know if something blocks or not. In contrast, NodeJS is built from the ground up so that pretty much everything is non-blocking.

NodeJS has built in support for doing DNS asynchronously, and it supports TLS (i.e. SSL). It also supports advanced HTTP features such as pipelining, chunked encoding, etc.

NodeJS has an internal thread pool for making things like file I/O non-blocking. That was a bit of a surprise since I wasn't even sure it could do file I/O. The thread pool is only accessible from C since he doesn't feel most programmers can be trusted with threads. He feels most programmers should only be trusted with the asynchronous JavaScript layer which is harder to screw up.

Dahl still feels that it's important to put NodeJS behind a stable web server such as Nginx. He admits that NodeJS has lots of bugs and that it's not stable. He's not at all certain that it's free of security vulnerabilities.

In general, Dahl believes you'll only need one process running NodeJS per machine since it is so good at not blocking. However, it makes sense to use one process per core. It also makes sense to use multiple processes when you need to do heavy CPU crunching. At some point in the future, he hopes to add web workers a la HTML5.

NodeJS has a REPL.

Dealing with binary in NodeJS is non-optimal because dealing with binary in JavaScript sucks. NodeJS has a buffer class that sits outside V8. V8's memory management makes it impossible to expose pointers since memory may be moved around the heap by the garbage collector. Dahl would prefer to deal with binary in a string, but that's not currently possible. Furthermore, pushing a big string to a socket is currently slow.

Dahl works for Joyent.

Although I still feel Erlang has a real edge in the realm of asynchronous network servers, Erlang is difficult for most programmers to adapt to. I think NodeJS is interesting because it opens up asynchronous network programming to a much wider audience of programmers. It's also interesting because it allows you to use the same programming language and in some cases the same libraries on both the client and the server. I'm currently looking at NodeJS because I want to use for Comet aka "real time" programming. Only time will tell how NodeJS works out in practice.


jjinux said…
NodeJS scales better than Twisted and Tornado according to
Will Moffat said…
Hi JJ, very interested to hear how your NodeJS adventures go. Keep us posted.
Anonymous said…
Hi JJ,

The latest release of eventlet has something interesting if you're looking for async network programming options in python: non-blocking zeromq support.

Here's a little example:

Which is a websocket based multiserver chat application in less than 140 lines of python.

I would disagree that eventlet is too magical - the internals are actually very sane and well put together. It only took me a couple of weeks part time to put together the zeromq hub. If anything it's greenlet where the magic lies :-)

Robin Berjon said…
Note that support for binary types is being added to JS through the WebGL work (which really needs it). I fully expect that trickle over to NodeJS sooner rather than later.
Samori Gorse said…
You should probably check out Faye ( ), which provides a Bayeux implementation for both Rack and Nodejs.
Anonymous said…
Small detail, but Python doesn't really have anonymous functions... it has lambdas, which are restricted to a single expression with an implicit return.

This might seem like a detail, but it means that in Python, you have to declare the callback before the call that uses it. In Node.js/ JavaScript, you declare them in the order they are used.

IMO it has a huge effect on readability.
Tiuskea Rakki said…
I would take some issue with calling asynchronous callback programming style "continuation-passing-style"... I guess you could say that the callback is the function that receives the result of the computation and is in that sense a sort of continuation, but CPS really means that all calls are tail calls, and there are no "returns", only passing of values forward to a runtime-selected continuation...
jjinux said…
Great comments guys. Thanks!
Brantley Harris said…
Once you get over the "magic" in Eventlet, it's absolutely marvelous to work with. One might not like "multiple stacks", but being able to code something linearly, without a network of callbacks, while getting all of the advantages and none of the disadvantages of threads is simply divine and everything that concurrent Python programming should be.

The only reason it hasn't taken off is because people can't get their damned heads out of the box that has define concurrent programming in Python for so long. Eventlet explodes that box into a thousand pieces.

And the Javascript callback routines are all fine and dandy, but they can become a real tangle after a certain amount of complexity.
jjinux said…
> Once you get over the "magic" in Eventlet, it's absolutely marvelous to work with. One might not like "multiple stacks", but being able to code something linearly, without a network of callbacks, while getting all of the advantages and none of the disadvantages of threads is simply divine and everything that concurrent Python programming should be.

Yeah, you're preaching to the choir ;) Eventlet is how we did things at IronPort for many years. In fact, there's a common lineage of programmers ;)
Anonymous said…
NodeJS appears a little hype driven by tons of web-based/client javascript developers who feel now they can just jump into being server-side engineers IMHO

Remember from Comp Sci 101, raw performance is not everything when developing Professional Software. Also, just because a language is popular doesn't mean it's suited to be a hammer for every nail (McDonald's is popular too).

Take a look at some of the NodeJS code or plethera of modules. Looks like pasta of callbacks, closures, nested complication.

Seems Eventlet's only complaint from Ryan is it's "magic"? But NodeJS "magic" is Ryans/V8's really, so it's just swapping magicians.

NodeJS seems to be really only something to appeal to people who love Javascript, when other solutions (in different languages) are far superior.
jjinux said…
Pretty decent comment. Thanks.

Popular posts from this blog

Drawing Sierpinski's Triangle in Minecraft Using Python

In his keynote at PyCon, Eben Upton, the Executive Director of the Rasberry Pi Foundation, mentioned that not only has Minecraft been ported to the Rasberry Pi, but you can even control it with Python. Since four of my kids are avid Minecraft fans, I figured this might be a good time to teach them to program using Python. So I started yesterday with the goal of programming something cool for Minecraft and then showing it off at the San Francisco Python Meetup in the evening.

The first problem that I faced was that I didn't have a Rasberry Pi. You can't hack Minecraft by just installing the Minecraft client. Speaking of which, I didn't have the Minecraft client installed either ;) My kids always play it on their Nexus 7s. I found an open source Minecraft server called Bukkit that "provides the means to extend the popular Minecraft multiplayer server." Then I found a plugin called RaspberryJuice that implements a subset of the Minecraft Pi modding API for Bukkit s…

Apple: iPad and Emacs

Someone asked my boss's buddy Art Medlar if he was going to buy an iPad. He said, "I figure as soon as it runs Emacs, that will be the sign to buy." I think he was just trying to be funny, but his statement is actually fairly profound.

It's well known that submitting iPhone and iPad applications for sale on Apple's store is a huge pain--even if they're free and open source. Apple is acting as a gatekeeper for what is and isn't allowed on your device. I heard that Apple would never allow a scripting language to be installed on your iPad because it would allow end users to run code that they hadn't verified. (I don't have a reference for this, but if you do, please post it below.) Emacs is mostly written in Emacs Lisp. Per Apple's policy, I don't think it'll ever be possible to run Emacs on the iPad.

Emacs was written by Richard Stallman, and it practically defines the Free Software movement (in a manner of speaking at least). Stal…

Creating Windows 10 Boot Media for a Lenovo Thinkpad T410 Using Only a Mac and a Linux Machine

TL;DR: Giovanni and I struggled trying to get Windows 10 installed on the Lenovo Thinkpad T410. We struggled a lot trying to create the installation media because we only had a Mac and a Linux machine to work with. Everytime we tried to boot the USB thumb drive, it just showed us a blinking cursor. At the end, we finally realized that Windows 10 wasn't supported on this laptop :-/I've heard that it took Thomas Edison 100 tries to figure out the right material to use as a lightbulb filament. Well, I'm no Thomas Edison, but I thought it might be noteworthy to document our attempts at getting it to boot off a USB thumb drive:Download the ISO. Attempt 1: Use Etcher. Etcher says it doesn't work for Windows. Attempt 2: Use Boot Camp Assistant. It doesn't have that feature anymore. Attempt 3: Use Disk Utility on a Mac. Erase a USB thumb drive: Format: ExFAT Scheme: GUID Partition Map Mount the ISO. Copy everything from the I…