"My programming career started when I was working on the Ruby on Rails website for a snowboard company. I guess I liked how Ruby made development so much more, I guess, you could express your ideas more clearly in Ruby. And that was interesting at the time. And I think Rails was impressive in that. It gave this new structure, and probably, it wasn’t new, but I think Rails popularized the structure of model view controller. I started going to Ruby conferences in Germany, where people were talking about this new paradigm of model view controller. And one of the guys there was Chris Neukirchen if I’m pronouncing that correctly. And he developed this project called Rack, which was a simplified abstraction of a web server. So, it turned a web server into a single-function interface, where you get a request, and then you return a response."
That, combined with some freelance work that I was doing on Nginx Module, for Engineyard, got me thinking about how… let me step back a second. In Nginx, everything is asynchronous. So, when you build a module for it, you have to be very careful to be non-blocking. And yeah, I think the combination of Chris Neukirchen’s rack plus how Nginx structured its web server with non-blocking IO, led me to start thinking about how those two things could be combined.
I’m using my fingers to do air quotes, but like in the web browser, people are already making non-blocking requests when they make AJAX request and stuff.
I think Node was an idea waiting to happen and had I not done it; somebody else would have.
I haven’t worked on Node myself since like, 2012, or 2013. And Node, of course, is a big project at this point. When it first came out, I went around and gave a bunch of talks, trying to convince people that they should. That maybe we were doing I/O wrong and that maybe if we did everything in a non-blocking way, that we would solve a lot of the difficulties with programming. Like, perhaps we could forget about threads entirely and only use process abstractions and serialized communications. But within a single process, we could handle many, many requests by being completely asynchronous.
‘I believe strongly in this idea at the time, but over the past couple of years, I think that’s probably not the end-all and be-all idea for programming. In particular, when Go came out.’
Well, I think Go came out a long time ago, but when I first started hearing about Go, which was around 2012. They had a very nice runtime that had proper green threads and easy to use abstractions around that. That I think makes blocking I/O – again, blocking I/O in quotes, because it’s all in green threads at the interface of… between Go and the operating system, I think it is all non-blocking I/O.
But the interface that they present to the user is blocking, and I think that that’s a nicer programming model. And you can think through what you’re doing in many situations more easily if it’s blocking. You know, if you have a bunch of following actions, it’s nice to be able to say: do thing A, wait for a response, maybe error out. Do thing B, wait for a response, error out. And in Node, that’s harder, because you have to jump into another function call.I believe strongly in this idea at the time, but over the past couple of years, I think that’s probably not the end-all and be-all idea for programming. In particular, when Go came out.
‘Yeah, I think it’s… for a particular class of application, which is like, if you’re building a server, I can’t imagine using anything other than Go.’
And honestly, building a web server is not the easiest thing, and I think a lot of these systems kind of left to their community to make that, and thus, nobody did. Because there is nothing to use the system with. I think it’s important that when you release a software framework, or maybe any software, that you have a demo that people can sit down and use immediately. And that was one of the things that went right with Node; it was that people could download it and use the web server directly.
I had been working on Node for four years. And I had gotten to the point where I wanted it. I never wanted Node to be a massive API. I wanted it to be this kind of small, compact, core that people could build modules on top of.
And there was a couple of the main things that… key features that I wanted to support. So, extension modules were added early on; we got all the networking libraries worked out, HTTP, UDP, TCP, we could access all the file systems.
And then, kind of a big chunk, which was maybe a year of work with like, five people, was putting it to Windows and doing that properly. And that we wanted to use Windows abstractions for asynchronous IO, which is their IO completion ports. And so, that required rewriting the core library, which, the result of that was the libuv library.
We had released on Windows. And you know, it was kind of at the point where it’s like: ok. I mean, this is what I had intended to create, and I’m pleased I got the chance to follow through with it. And of course, there’s going to be, you know, an infinite amount of bugs to fix for the rest of my life, but… you see, there are enough people involved to that. I don’t need to do that necessarily, and I would like to do other things. So, that plus the fact that Go came out, and I didn’t see Node as being the ultimate solution to servers.
Node is used by hundreds of thousands, if not millions of people at this point, and I think it’s certainly exceeded any expectation of what I thought would happen with it. Yeah, it’s cool."
Rate this article