Original URL: https://www.theregister.com/2011/03/01/the_rise_and_rise_of_node_dot_js/
The Node Ahead: JavaScript leaps from browser into future
Google V8 engine spawns server world doppelgänger
Posted in Software, 1st March 2011 18:39 GMT
Voxer is a walkie-talkie for the modern age, an iPhone app that lets you instantly talk across the interwebs and listen at the same time and leave voice messages if no one is on the other end and simultaneously chat with multiple people and toggle between text and voice to your heart's content. It's a real-time internet app in the extreme, and that's why it's built with a development platform most of the world has never heard of.
Matt Ranney and his team originally conceived Voxer as a two-way VoIP radio for the military, and he started coding in good old fashioned C++. "That's what you use for a serious, high-performance military application," he says. But C++ proved too complex and too rigid for the project at hand, so he switched to Python, a higher-level language that famously drives services at the likes of Google, Yahoo!, and NASA. But Python proved too slow for a low-latency VoIP app, so he switched to Node.
Node is what the developerati call Node.js, a two-year-old development platform specifically designed for building dynamic net applications. The "js" stands for JavaScript. Node is built atop V8, the open source JavaScript engine at the heart of Google's Chrome browser. But it's not a browser technology. Node moves V8 from the client to the server, letting developers build the back end of an application in much the same way they build a JavaScript front end.
Voxer: the Node walkie-talkie
But that's only half the proposition. Node is also an extreme example of an "event-driven" system, a software architecture that's built around not threads or data but events: messages from other applications or inputs from users. In short, it doesn't wait for one thing to happen before moving to the next. If it calls a database for information, for instance, it can tackle the next task before the database responds. Whereas traditional multithreaded systems are suited to heavy CPU work, event-driven systems are meant for network applications that involve heavy I/O.
When a user connects from across the net, the Node "event loop" needn't preallocate a huge chunk of memory for whatever happens next. It allocates only a small slice of memory – a placeholder, if you will, that simply identifies the connection – and it grabs additional memory only as required.
This setup, Matt Ranney realized, is ideal for an app like Voxer, which requires unusually low latency with an unusually large number of open connections. "If you want to make something where the user gets a real-time update stream of some kind, you need to keep open a bunch of connections to the server. That's very expensive in, say, a PHP architecture. But in Node, it's nearly free. You can keep the connections open for a very long time, and the incremental cost per connection is very low," Ranney, Voxer's CTO, tells The Register.
"Node is the best of both worlds. We get JavaScript, which is uniquely suited to this kind of evented programming, but we get the performance too."
When he first built Voxer, Ranney ran a test to see how many connections he could open on a single server. "I just decided to open as many connections as I could, just to see where things would fall down," Ranney says. "With Node, I could open, well, all of them. I couldn't open any more connections without getting more IP addresses on my test machine. Node uses such small amounts of memory, it's astounding. I ran out of port numbers."
The New Everything
In certain Silicon Valley circles, Node is known as The New PHP. Or The New Ruby on Rails. Or The New Black. It's The Next Big Thing, according to, well, just about everyone who uses it. "For a while, I called it The New Rails," says Tom Hughes-Croucher, the author of the upcoming O'Reilly tome Up and Running with Node.js (preview PDF) and the chief evangelist at cloud computing outfit Joyent, Node's primary steward. "But then I realized it was getting more views on github than Rails. So now I call it The New PHP."
Ruby on Rails was the first major project hosted on github, the popular open source repository, and though Rails still has more "followers" than Node – roughly 7,000 versus 5,000 – Node is indeed getting more views. And whereas Rails is a mature language with a good seven years of development behind it, Node debuted in 2009. We're still a long way from a 1.0 release. Version 0.4 arrived just last month.
In addition to sponsoring the Node open source project, Joyent offers a hosted version of the platform, an online service that lets developers build and deploy apps via the browser. Known as no.de, the service still in beta, and it has sparked some interest in notable places. "Awwww yeah," Google App Engine engineer Ikai Lan tweeted in mid-February. "Got my Joyent node.js hosting invite."
For Gerad Suyderhoud, who organized the first Node hackathon, Node Knockout, this past summer, the platform is the next major phase in the always-rapid evolution of web development. "First there was C, which Amazon was written in," he says. "Then there was Perl, and Craigslist was written in Perl. Then there was PHP and Facebook, and then Rails and Twitter. With each of these things, they solved a lot of hard problems, but then new problems arrived. Node solves the next set of hard problems, the problems that come with all this real-time stuff."
Though Node runs more than a few live applications – including Voxer as well as Mockingbird, a web app for building site wireframes, and LearnBoost, a gradebook service for schools – the platform doesn't yet drive a Facebook-esque mega-site. But Suyderhoud, like others, is sure it will. Held at Joyent's offices in August, the Node Knockout competition attracted 500 developers, and it spawned at least one commercial application, Word2, a massively multiplayer version of Scrabble.
But Node isn't just a tool for building applications and websites. It's also a means of driving so-called cloud services – i.e., the backend services designed to run the next generation of applications and websites. Joyent uses node to underpin its Amazon EC2–like infrastructure cloud, a service that provides on-demand access to readily-scalable processing power and storage. Cloudkick, the cloud-management startup recently purchased by Rackspace, is writing a new set of server-management tools atop Node. And Rabbit Technologies, the cloud-messaging outfit now owned by VMware, is offering rabbit.js, an extension of its RabbitMQ open source messaging platform based on Node.
Ryan Dahl at Node Knockout
"With the cloud-management stuff, you have all these little agents sitting here and there, and they're not necessarily dealing with a large amount of throughput," says Ryan Dahl, the man who invented Node as an independent programmer and now works for Joyent. "Writing these little things turned out to be really nice in the [event-driven] world. You don't have to deal with different threads. You just have to receive messages and send messages."
At the same time, Node is being moved from the server side back to the client. HP uses node on its Palm webOS handsets and upcoming TouchPad tablet, using it to run background services on the devices themselves. It's yet another indication of how efficient the platform is. "It turns out, you can really scale it down," Dahl says. "It doesn't require allocating gigabytes of memory. It has a fast startup time. It has a low memory footprint. ... It's something that's small enough to run on an embedded device."
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."
Would you like to touch my V8?
Ryan Dahl set out to build his JavaScript platform atop Mozilla's SpiderMonkey, the engine at the heart of Firefox. But after about two days, he switched to Google's V8, and that's where he stayed. "V8 is just a nice, clean library," Dahl says. "It's compact and extracted away from Chrome. It's distributed as its own package, and it's easy to build and it's got a nice header file with nice documentation. It's kind of constrained. It doesn't have dependancies on other things. It seemed much more modern than the Mozilla stuff."
Google isn't officially involved in the project, but according to Dahl and other Node developers, the company has been helpful when the project requires V8 bug-fixes or additional insight. "It's an exciting project. I was at the jsconf.eu conference in Berlin last year, and there was a lot of buzz around Node," Google V8 team member Erik Corry tells The Reg. "It's a very cool use of V8 and shows what you can do when you combine open source software in new ways, not necessarily anticipated by the original authors."
Originally, Dahl called his project web.js. It was merely a webserver, an alternative to Apache and other "blocking" servers. But the project soon grew beyond his initial webserver library, expanding into a framework that could be used to build, well, almost anything. So he rechristened it node.js.
He released an early incarnation of the platform in June 2009, but few noticed until he gave a demo at that year's jsconf. His 45-minute talk was met with a standing ovation, and the project was off and running, not just among application developers but at big-name cloud outfits as well.
"[Ryan Dahl] was certainly ahead of the game in understanding the implications of [the real-time] world," says Alexis Richardson, senior director at VMware and the former CEO of Rabbit Technologies, the outfit behind RabbitMQ, who was reading Dahl's blog before Node was released. "When he introduced Node, I was extremely impressed."
A month later, Dahl was hired by Joyent.
Node in the heavens
Joyent had already explored the idea of using JavaScript on the server side, and Node seemed to fit right into its thinking. Dahl started writing code designed to drive Joyent's infrastructure cloud, and two years on, Node is "heavily used" inside the company's service. It's also a part of Joyent's SDC6 software, which allows ISPs and other outfits to build their own infrastructure clouds.
The company uses Node in tandem with RabbitMQ – an open source messaging platform for sending data across cloud services – and at VMware, Alexis Richardson and crew have built software that lets application developers do much the same thing. They call it rabbit.js.
RabbitMQ already integrates with Java, Ruby, and Python event-based systems – including Spring Integration, EventMachine, and Twisted – and Node was the natural next step. "The combination of Node with Rabbit simplifies the motion of the data. Rabbit is a data-in-motion technology as opposed to storage technology like a database, and Node gives you a handy toolkit for interfacing that world with applications," Richardson says. "Rabbit enables the motion of the data. What Node does is provide a way to program in this style, for JavaScript users."
At the same time, rabbit.js builds on Socket I/O, a Node technology for readily pushing data to client browsers. Designed by LearnBoost CTO Guillermo Rauch, Socket I/O gives developers a single interface for pushing information to WebSocket-enabled browsers as well as browsers that don't support the relatively new push standard.
"Socket I/O gives you a duplex channel, but what it doesn't do is define what you might say or hear over that channel," says VMware staff engineer Michael Bridgen, who built rabbit.js. "RabbitMQ has semantics about how you do messaging, so I thought [the combination of RabbitMQ and node] might be a sweet spot."
The idea is to extend messaging from the cloud to the browser. On the back end, RabbitMQ lets developers pass data without a database. With rabbit.js and Socket I/O, Bridgen and VMware can do much the same when an application is talking to the client, across the web. This is just the sort of thing Node is designed to do.
Node Knockout
"I think Node itself recognizes that web programming is more about network programming than it is about databases," Bridgen says. "It's about taking on some data, sending it on in that direction, and then something comes back and sending that back on again. It's about shuffling data here and there. One of the reasons that Node has been successful is that it makes that kind of asynchronous data shuffling accessible to people by couching it in JavaScript."
Rauch agrees. Node drives the length and breath of his LearnBoost app. With node, he says, you can use the same language on the front end and the back end. "That's what's so appealing," he says. "You can write your web application in JavaScript, and you can write all your back-end infrastructure in JavaScript, and you can write your client web application in JavaScript. It really is a single-stack world."
All the way to the end
In the beginning, Ryan Dahl didn't see node as a platform for "end" developers, coders building end-user applications. But he was proven wrong almost immediately. "We thought Node was just kinda about opening TCP connections, a kind of low-level thing, something you do low down in the operating system," he says. "But people starting building websites with it."
To tap this interest, Joyent built no.de, a means of using Node as a service, through a web browser. For LearnBoost's Rauch, node is – more so than other systems – tailor-made for this sort of platform-as-a-service (PaaS). "Node is really well-suited for the cloud," he says. "Running a node server uses few resources, but it's able to handle really large numbers of users."
With no.de, you essentially build a git repository with a Node server, and you push it to a virtual machine running on Joyent's infrastructure cloud. It starts up the daemon and makes sure the daemon keeps running. The underpinnings of the service are also included with SDC6, so that third parties can run their own no.de.
According to Joyent's Tom Hughes-Croucher, when benchmarking its Node setup the company has set up a 'hello world' server that can handle 8,000 requests per second from a single CPU core. "It's just saying 'hello world,'" he says. "But still." He says that some apps have been known to accomodate 15,000 concurrent users from a single server.
Because it's so efficient, Hughes-Croucher believes Node is on the verge of hitting it very big among end developers. But as Ryan Dahl points out, this is still a niche platform. "Most people are working on asp or Java or PHP," he says. "They're not looking for new platforms. They've got their company. They will use the next product from Microsoft, but they're not in search of a new runtime to use."
What's more, the concepts are very different from what developers expect in the multithreaded world. "You're forced into this non-blocking style," Dahl says. "Anytime you want to talk to this remote back end or something, you have to give a callback. You can't say 'Database give me the result and then in the next line use the result.' You have to somehow have a callback, so you get indented a bit or you jump into a different function.
"It can be very painful for people when you have to do a lot of things in serial – a and then b and then c and then d. In a typical blocking language, you would just do a, b, c, and d, one after another, each on its own line. In node, you have to jump into different functions for each of those. You have to request that the database send you some data, go back to the event loop, handle other requests, get the response, call some function that sends off the next request, go back to the event loop, handle more requests."
The flip side is that the platform should feel quite confortable to those who use JavaScript on the front end, who have little history on the server side. "For client-side people, the non-blocking style is all pretty natural. They wouldn't think about it another way."
Node Knockout code
The overarching point, however, is that Node is optimal for the new breed of real-time web apps. Yes, there are other means of building real-time tools, but Node lets you build real-time tools on the same platform that runs the rest of your site. Famously, Facebook's chat server was built with Erlang, but as Guillermo Rauch points out, the rest of Facebook wasn't.
"If you have a traditional stack with, say, PHP and Apache, doing real time is almost impossible," Rauch says. "You always have to offload your real-time communications to a different webserver or a specialized webserver you write yourself. Facebook wrote an Erlang server just for Facebook chat and they made it talk to their PHP stack. With Node, all those infrastructure complications are completely removed. You can write your real-time stack right in the same codebase as your normal web application, your database-management layer, and everything else."
So Node is neither The New Rails nor The New PHP. It's something else entirely. ®