On the 20th floor of a San Francisco skyscraper, a handful of developers are working on a new technology that’s changing the way real-time web apps are built and how they scale.
This technology, called Node.js, is being hailed as “the new Ruby on Rails” by some in the developer community. But it’s not a magic bullet, nor is it appropriate for all programming scenarios.
Joyent, an SF-based cloud software company, is sponsoring the growth and development of Node. It employs Node creator Ryan Dahl, hosts events and creates tools for the growing Node community. Recently, Mashablevisited Joyent to see demos from three startups that are using Node to build web and mobile apps for consumers.
In the process, we learned a lot about how and why Node works for the real-time web — and how Node is changing the way the developer community creates the Internet as we know it.
What Makes Node Different
We asked each of the three startups giving demos at Joyent: Why choose Node?
The common wisdom among many developers is that there is no single right language or framework that should and must be used for all web apps. But based on what we heard from these startups, Node is increasingly being seen as a “best solution” for a certain type of application.
According to Tom Hughes-Croucher, a recent Joyent hire who is writing the first O’Reilly book on Node, “Node has popularized event-driven programming.” With event-driven programming, Hughes-Croucher explains, “The actual amount of resources you use is much smaller, and you can get a lot more out of fewer servers.”
In traditional languages and frameworks, the communication inside the app between the web server and the database is the most time-intensive part of the transaction. Node makes a much smaller footprint on your web server. It allocates web server resources on an as-needed basis, not pre-allocating a large chunk of resources for each user. For example, Apache might assign 8MB to a user, while Node assigns 8KB.
“The way that Node is more efficient on servers is by not allocating resources to things while it waits,” says Hughes-Croucher. “Say you have to talk to the database, and that’s going to take 50ms to respond. Instead of assigning all of the processing resources for that 50ms wait, it just uses a placeholder. When the database responds, then it allocates the resources needed to process. That means it’s totally possible to do a lot more requests at once, because you only allocate the server resources when you need to use them, not while you are waiting on databases.”
Node’s Explosive Growth
Unlike PHP or Ruby, Node has yet to appear as the technological face of a popular, mass-adopted web service like Twitter, WordPress or Facebook.
Rather, Node took off in the imaginations of programmers, organically becoming the quirky new tech that was on the tip of every tongue. First, devs asked if you’d heard of it; then, they started asking if you’d tried it or built anything with it.
As you can see from these GitHub reports, both the number of committers and the number of commits to Node core really took off, and there are no signs of Node’s growth slowing down in the dev community.
Click the image to see full-size charts, which we obtained from GitHub.
Commits and committers to Node on GitHub peaked in the fall of 2010, but developers’ conversations around Node have really just started to pick up steam since the beginning of 2011. Here’s a graph showing Twitter conversations around Node; you’ll notice a few spikes throughout the fall of 2010, and more consistent conversations occurring in 2011.
“If you look at Rails and Node on GitHub and compare the traffic,” says Hughes-Croucher, “Rails had 270,000 views over the past three months. Node has 325,000, and it’s only going up… it’s exploding.”
There have been “it” technologies in the past, and the current vogue is Ruby on Rails. So what makes devs think Node is the heir apparent?
“Node is going to become the next big thing for a few reasons,” said Hughes-Croucher. “Everyone wants to do way more powerful apps — things like Google Instant and Facebook. People are expected to support millions of users on a ton of devices in real time. These are the expectations people have of applications now. And if you did that with traditional frameworks, it would take forever, and the hardware would cost millions of dollars.
Node for Real-Time Voice
Igal Perelman is the VP of product for Voxer, an iOS app that aims to “make audio sexy again.” It functions a bit like a walkie-talkie, a bit like a group IM app and a bit like a social/location consumer app.
“There is a huge reason why kids love to use walkie-talkies. It’s fun and immediate,” said Perelman. “We took that basic use case and improved it a lot.”
The user pushes a button, starts talking, and the message is immediately sent to the app user on the other end. Both parties can listen and talk simultaneously. Chat requests come through as push notifications, allowing the users to choose whether or not to join the chat.
Users can also re-listen to messages in case they need clarification or missed part of a message, like rewinding a video. Another cool feature: The app supports group chats with unlimited numbers of participants.
Finally, it’s entirely free.
Voxer uses Node because the low latency allows for near-instant transfer of audio data. Says Perelman: “Node was very crucial to this, because the audio needed to be live. And Node allows us to maintain a large number of connections with very low latency. It was a quite easy decision.”
Voxer’s VP of technology, Matt Ranney, told us (via the app itself, of course), “This is our third iteration trying to do live voice. We first tried C++ for performance reasons, but it was too complicated, too hard to wrangle. Next, we chose Python. It was great, but unfortunately, the Python virtual machine is incredibly slow.
Node for Gaming
One of the hackathons we followed this year was Node Knockout, a 48-hour contest to see who in the world can build the best, most complete, most interesting Node apps on a very tight deadline.
The popularity winner for the 2010 contest was Scrabb.ly, a massively multiplayer online version of Scrabble. The game plays in real time, and the map of all the tiles is sprawling to gargantuan proportions.
The team built the game in two days and has since made a company out of the project.
On the flipside, “Rails Rumble [a similar, Ruby-on-Rails-flavored hackathon] has been around for four or five years, and only one company has come out of it,” says Fortnight Labs and Node Knockout co-founder Gerad Suyderhoud. “We had a company in our first year. Because Node is such a great technology for real-time web apps, you see a lot more games, so the results are a lot more fun.” The next Node Knockout is in August 2011.
Suyderhoud and co-founder Visnu Pitiyanuvath’s entry in the 2009 Rails Rumble was Lazeroids, but they discovered that building a real-time game in RoR was “too hard.”
When it comes to real-time games, says Suyderhoud, “There’s really not a lot that’s competing with [Node]. The other technologies just aren’t as good at doing real time. They’re backed in older frameworks. Node was designed from the ground up for real time and to be easy to use. Other technologies would take forever to do the same things.”
And as far as community is concerned, Suyderhoud says, “it’s amazing how inclusive it is. I’ve never seen such good support. For Node Knockout, it was some people’s first time using Node. We didn’t provide a lot of support, but we got really lucky. A lot of people who had no vested interest and were not participants stepped up and helped people solve their problems over the weekend, in chat channels and over Twitter. I was definitely not expecting that.”
Node for Collaboration
Mockingbird is more a tool for web designers than a true consumer app, and it allows devs and designers to rapidly create wireframes. The interesting thing about Mockingbird is that this Node.js app is already making serious money for its creators.
Basically, Mockingbird is a tool for collaborative drawing and real-time communication between designers and clients. It took the founders just months to take the app from concept to a working beta.
“We’ve been around since November of 2009 and launched our paid product November 2010,” says CTO and co-founder Saikat Chakrabarti. “We’re doing much better than we thought. We thought we’d be struggling entrepreneurs for a long time, but we’re very much in the green.”
The app currently has 60,000 users and hosts more than 100,000 projects.
Says Chakrabarti: “I tried to do the app in Twisted and Tornado at the time, and Node was by far the easiest… A lot of people and companies are very invested in this.”
Node for the Future
Time will prove whether Node is that next big thing, but one thing was agreed upon by all parties at this roundtable demo session: Node needs a Twitter, a Facebook or some other big, consumer-friendly, mass-adopted app to make the mainstream tech community take notice.
However, as soon as middle managers get wind of Node, it runs the risk of developing a bubble. An employment bubble would surely be followed by an employment crash, which would likely be perceived as the “downfall of Node.”
A misunderstanding of the technology is also a risk. Former Twitter engineer Alex Payne’s claim that Ruby was slow continues to haunt general conversations about Ruby to this day.
It’s not our intention to inflate anyone’s expectations of Node. And we’re certainly not advocating its use for all programming projects. However, we do think that Node is an interesting, accessible and efficient technology for real-time applications, and we’d love to see what comes of this framework.
We’ll especially be keeping an eye out for “the Twitter of Node” — both to critically examine how the framework performs under pressure and to keep an eye out for hype.
Stay tuned for Mashable‘s ongoing coverage of Node, including one-on-one interviews and code snippets to get you started.
Series Supported by Rackspace
The Web Development Series is supported by Rackspace, the better way to do hosting. No more worrying about web hosting uptime. No more spending your time, energy and resources trying to stay on top of things like patching, updating, monitoring, backing up data and the like. Learn why.