A few weeks ago I asked questions to three people using node.js in their products.  This week, I figured I’d ask Ryan Dahl, creator of Node.js, 4 questions about the history and future of his creation.  Without further ado, here is the interview:

BostInno: What were you trying to solve when you created node?

Dahl: I was often involved with writing small event based programs. I liked the design of event based servers because I felt they were easier to understand: state is kept in some struct and you go around and around modifying the state. There were no infinite while loops making blocking reads or accepts from sockets (which has always struck me as a very strange pattern). I would be able to make very low latency servers by using only non-blocking I/O.

There was a good reason why most people did not design programs this way despite the simplicity and efficiency: they needed to use libraries which were blocking. Event based program design is an all-or-nothing proposition; you can pack a lot of I/O into a single OS thread if you’re careful to never block on I/O but if you do then you lock up all of those streams you were handling. Using a thread for each I/O stream is a lot more forgiving – it doesn’t matter how slow you are in one of them. I wanted to create a system where people could only use non-blocking I/O.

At the same time I was writing a lot of little HTTP servers based around the idea of a small, well-tested interruptible HTTP parser. I was frustrated that I could not get the raw request upload stream from a web server unless I wrote an Apache or NGINX module. The interruptible parser made it easier to build a server.

BostInno: Why did you originally choose javascript for node?

Dahl: Originally I didn’t. I had several failed private projects doing the same on C, Lua,  and Haskell. Haskell is pretty ideal but I’m not smart enough to hack the GHC. Lua is less ideal but a lovely language – I did not like that it already had a lot of libraries written with blocking code. No matter what I did, someone was going to load an existing blocking Lua library in and ruin it. C has similar problems as Lua and is not as widely accessible.  There is room for a Node.js-like libc at some point – I would like to work on that some day.

V8 came out around the same time I was working on these things and I had a rather sudden epiphany that JavaScript was actually the perfect language for what I wanted: single threaded, without preconceived notions of “server-side” I/O, without existing libraries.

BostInno: Where is node going in the next 3 months?  6 months? 12 months?

Dahl: Node is a single-threaded, single-process system which enforces shared-nothing design with OS process boundaries. It has rather good libraries for networking. I believe this to be a basis for designing very large distributed programs. The “nodes” need to be organized: given a communication protocol, told how to connect to each other.  In the next couple months we are working on libraries for Node that allow these networks.

In February the second stable release, v0.4, will be made. This includes improved memory usage and a new SSL/TLS system, a built-in debugger, faster timers, many wart removals, and the new version of V8. Hopefully in the next 6 months we’ll release a 1.0 version of Node. The idea is to constrain what goes into “core” and not allow it to grow too big – so there will not be endless stream of feature additions. 1.0 will look pretty much like Node does now. There are a lot of bugs to fix still.

BostInno: Is there anything you wish you had done differently with node?

Dahl: Yes – many things. For example, I wish I had not used the CommonJS module system. It’s far too complex and wildly different from how the browser works. I wish I had not used the WAF build system, it works – it’s okay, but it introduces more WTFs than necessary. I can perhaps dig out from under WAF at some point but it would be a monumental undertaking.

A big thanks to Dahl for answering the questions.