RD: I was a contractor and I was doing various little C projects usually involving server and event driven software and I realized that I was doing this same code over and over. C is a nice language to work in, but I wanted something I could script in the same way that I was programming these servers.
RD: A little. I used to work a lot with Ruby on Rails – so I’d often be dealing with front-end code. Back then I wrote a little Ruby web server called Ebb that was meant to be a faster Mongrel. That code was the starting point for Node.
OP: So, did you follow the whole discussion around EcmaScript 4 and EcmaScript 5?
OP: Any particular ones in mind?
RD: What’s this called? Destructive assignment? If you have an array on the right and a list of variables on the left, and they can be define that way. That would be nice to have.
OP: That’s included in Rhino, but not in V8
OP: So let’s move on to Node itself. what is the most difficult design decision you made with regards to the project?
OP: The hello world app would have one more indentation.
RD: Right, so in terms of difficult design decisions, I wanted Node to be browser-like. Maybe it didn’t use the same methods but the same structures could be ported easily, aliasing methods to the browser ones. Originally Node achieved that—it was totally browser-like. Originally, it even had a ‘window’ object. I slowly backed off that API as it became clear it wasn’t necessary to have the server-side environment be exactly the same. So I went with the CommonJS module system which was rather reasonable; the CommonJS people had put a lot of thought into it and I didn’t really want to worry about modules so much. So yeah, require is blocking and there are some other minor things that are blocking in Node. Generally this pragmatic approach of being non-blocking 99% of the time, but allowing a few synchronous operations here and there has worked out well. It probably doesn’t matter for a server-side program if you load modules synchronously.