Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

Chip off the old non-block

Ryan Dahl originally built Node because he wanted a faster webserver, a webserver suited to modern web applications. A former math student turned independent coder, he had developed an interest in event-driven systems – what he calls "non-blocking I/O" – and he built an event-driven Ruby webserver known as Ebb. But Ruby didn't offer the sort of performance he was looking for.

Though the server was event-driven, any performance gains were minimized because the system had to interact with traditional multithreaded or "blocking" systems. "I got frustrated with trying to make [Ebb] fast," Dahl says. "I knew that you could get this very large performance gain if you did all non-blocking I/O. The real problem of this is that it's an all-or-nothing proposition. You can either do all non-blocking or you do all blocking and use threads. If you want to get into this non-blocking I/O, it becomes really difficult because you have to interact with a lot of other systems which usually don't present a non-blocking interface."

So he set out to create a completely new platform, a platform that would redefine the way people build applications. He started with a C library. But then he realized that C isn't as popular as it once was, and he moved to Lua. But this too proved problematic. Lua was laden with all sorts of "blocking" libraries.

"There was already a Lua culture around the blocking stuff," he says. "What I was really looking for was kind of a clean slate. If you're going to write a new platform, you might as well go the whole way. Lua was somehow not as exciting because there were already libraries that were blocking."

About six months into the project, he had his JavaScript epiphany. At the time, Wikipedia listed 100 odd JavaScript server-side projects, but none had really caught on. There was very little precedent for how you would, say, open a server, create a new socket, connect to a user, resolve a DNS address, talk to user, open a file. "There's was no culture around that stuff," Dahl says. "There's was no idea of what that should look like. So you could just define it as non-blocking and you could give it to people and they would say 'Oh, OK'."

Yet JavaScript is familiar to an army of client-side developers. It's not an entirely new language. "You don't have to switch mental gears when doing client work to doing server work," Voxer CTO Ranney says. And as both Dahl and Ranney point out, the existing client-side language is suited to event-based programming. JavaScript offers a high-level of abstraction, including support for closures, which come in quite handy for callbacks in an event-driven system.

"[Node] should be extremely familiar to people [who built client-side JavaScript applications]," Dahl says. "In the same way that a client-side programmer would set up a callback for a website button – 'Here is the button. When somebody clicks on it, call that function' – a Node programmer sets up a server. Instead of somebody clicking on a button, it's somebody connecting to a server. 'When someone connects to the server, call this function'."

Node says 'hello world'

An event-based system is hardly a new idea. Similar platforms are already available for Ruby and Python – EventMachine and Twisted, respectively – but in choosing JavaScript, Dahl took the idea to new extremes. On top of it all, the big browser makers are engaged in a never-ending arms race to make JavaScript as fast as possible – and Google is among those leading the way. "When I found Node, I thought it was perfect," says Ranney.

"It's an event loop, the right way to make a high-performance server. It's JavaScript, a high-level language. It has great support for closures, which you need for the callbacks in an event-based system. And you've got Google behind V8 in the JavaScript arms race."

Agentless Backup is Not a Myth

Next page: Would you like to touch my V8?