On Node.js

Posted: April 8th, 2011 | Author: | Filed under: Uncategorized | 2 Comments »

I’ve been meaning to write a blog post on Node.js for a long time, but it wasn’t until now until I found an excuse to make myself sit down and write it. This afternoon the author of Node.js, Ryan Dahl, gave a talk at Facebook. It was pretty well attended, with around half of the audience having used Node.js beyond “hello world.”

Pythonistas could think of Node.js as the JavaScript equivalent of CPython, Twisted, and setuptools packaged together in a single binary residing server-side. It includes a package repository (npm), and is all about event-driven I/O. That means that every time you make a call that would block, you pass a callback to it, kind of like how Twisted’s Deferreds work.

Anyway, going into the presentation I was cautiously positive about the technology and had a pretty negative opinion about the Node.js community. I’m an avid reader of Hacker News and the Node.js spam is almost unbearable. But to his credit, Ryan acknowledged that in his presentation and on his Twitter.

What strikes me about Node.js is that it’s not particularly innovative. On the surface, it’s just a reimagined Twisted Python – but Twisted’s Deferred functionality is much cleaner in terms of error handling with errbacks and flow control with DeferredList. The syntactic advantages JavaScript has with anonymous functions are, to a degree, mitigated with inlineCallbacks() (the developers of Node.js had no solution to nested “callback hell”).

With that said, I’m totally stoked about Node.js, and I think it’s going to explode in growth. JavaScript has matured so much in recent years and there is a powerful set of best practices that turn it into a rather nice language, especially when coupled with Node.js’s implementation of CommonJS.

The design of Node.js is beautiful, largely because of JavaScript’s anonymous functions. JavaScript just seems like a better fit for this sort of framework than Python is. Additionally, one of the lesser-advertised features of Node.js is that it exposes a lot of V8’s internals to the JavaScript side (i.e. raw I/O buffers instead of strings), which results in awesome performance. Before the talk, I had no idea that Node.js was tied to V8 for any particular reason; now I know.

There’s also a ton of JavaScript developers who could be enlisted on the server-side and develop the client and the server without switching mental gears between languages. During the talk, Ryan cited a bunch of interesting npm packages, and apparently the library is extensive.

And finally, Node.js can do things that Twisted can’t – it explicitly forbids any blocking calls, which makes it a lot more difficult for developers to accidentally block the main thread. All of the Node.js packages are designed with this in mind. In contrast, the Python world needs all dependencies to expose a nonblocking API. Because of this, I think Node.js could revolutionize parallel I/O in a similar way that garbage collection revolutionized memory management.

As for me, I’m really excited. I plan on using Node.js for “real projects” in the future, but I’m holding out for V8 to support “use strict”. I am growing to like JavaScript, but until “use strict” comes out with its support for strong dynamic typing and lack of semicolon insertion, I’m going to stick with Python for my real projects.


2 Comments on “On Node.js”

  1. 1 Rasjid said at 8:06 am on April 8th, 2011:

    As a Python programmer looking for a good way of dealing with Javascript, I came across CoffeeScript (http://jashkenas.github.com/coffee-script/) the other day. And although I’ve not had a chance to use it yet, I like what I see. Apparently it plays well with node.js, and I think it will deal with most if not all of your Javascript concerns.

  2. 2 Ian Bicking said at 8:49 am on April 8th, 2011:

    There are generally blocking equivalents to the non-blocking calls. Like Python a degree of metaprogramming is available by executing code at import (or require)-time. Those operations are all generally sync (unless you just enjoy pain).

    But it’s one of those places where Node is different from a browser because there’s no sync at all in the browser (so e.g. require() won’t work)


Leave a Reply