We dubbed it “our Christmas,” the day when all our good engineering deeds would pay off and we’d be rewarded with a bounty of happy active users for our mobile app, Avocado.

Up until this point we’d enjoyed steady and predictable growth, but with only two weeks’ notice we realized a few big, coinciding promotions would bring us a 30x increase in traffic and a membership boom for which we weren’t yet prepared.

Scaling for a “Christmas” moment is scary; it forces you to confront all the design decisions you may have made earlier when bootstrapping your app. No matter what the hidden weaknesses are, a massive group of new users will find them.

With only two weeks, how could we scale our infrastructure to meet demand and not fall over?

Preparing for scale

This is a document of how we screwed up. And then how we fixed our screw-ups. Please learn from us.

At first, we thought we knew where our weak points were. Well, until we ran some tests and found our problems were in a completely different place.

We’ve been using Amazon’s Web Services. Here’s the initial configuration of our deployment:

1 frontend server (stored: API, web presence, socket.io, HAProxy, stunnel/SSL encryption)
1 Redis server
1 MySQL server
1 batch server (running miscellaneous daemons)

Our API server was using Node.js since it’s lightweight, fast, easy to code for, and has a large community with some solid libraries we use (and some we have written and shared).

Given the results of early tests and under limited resources and time, we understood where we needed to focus: new user signups — clearly our most complex process. We put our energies into finding the pain points and where the system would die if we had a sudden influx. This was an important business decision: You can let a few normal day-to-day activities fail, but you don’t want new user creation to fail.

Better testing

Smart scaling required us, as a wise man once said, to check ourselves before we irreparably wrecked ourselves. In other words, we tested, tested, and tested some more.

Early tests weren’t good enough so we created a replica environment: entire duplicates of our database and existing server and partitioned them off so nothing would affect our production environment. We ran through some common use cases like account creation as well as messaging and uploading images. We saw where Avocado failed and at what rates.

Pro Tip #1: We used much smaller EC2 instances in our test environment than in production. Not only does that provide limited resources all-around to more easily find problems, but it’s considerably cheaper as you pay for the amount of hardware you use on AWS.

Pro Tip #2: We built test scripts as well as used a tool called jmeter to simulate tens of thousands of user signups per minute.

Our testing process: Run the scripts, find weak points, re-run the scripts. We then experimented to see what would happen if, for instance, we added a second server or if we took advantage of all the CPUs on a given server.

We started to see things immediately. Any time we had thousands of users signing up at one time, things would grind to a halt and connections to Avocado would take ~30 seconds to complete.

What we discovered: Any time Node.js spawned off a separate process, the system would take a hit. At the time, we were spawning off a Python process to send verification emails and another for image resizes (required when a user uploads a photo to their activity stream). When that happened, we’d see a big ol’ CPU spike. We realized it was those processes that were slowing everything down.

Well, it was the processes. And the fact that we had everything on just one box.

We also noticed slow database query response times. We saw in the test environment that a handful of MySQL queries were showing up in MySQL’s slow query log (for instance, if we queried to see if a certain email address had received an invitation to join their “boo” on Avocado).

Pro Tip #3: MySQL query optimization can be something of a dark art but speeding up queries can be as easy as adding additional indexes to a couple tables.

One last thing: SSL encryption/decryption was a major load on the CPU as well, but we didn’t know to what degree it would impact the system under heavy user traffic in production.

What we changed after testing

Our first fix was to rewrite the email system, previously in Python, in Node.js so it wouldn’t need to call up another process. Moving to a node.js mailing library meant we could send 3x to 5x the number of emails in a period of time as it would take to call the external python program.

Next, we put stunnel (SSL encryption handler) and HAProxy onto their own EC2 server so we wouldn’t overload our core services.

We had a few possible solutions for the image resizing problem found in testing where spawning ImageMagick processes from node.js proved to be a huge resources hog. We explored the option of leveraging some faster libraries and third-party image resizing services.

But we ended up not rewriting any code or using any services. Either may have worked, but we didn’t want to do last minute code changes a day before our big promotion. So instead, we deployed four new EC2 instances whose sole purpose was image resizing. We took these down after the promotion.

Currently we’re back to just resizing images on our normal frontend servers (the servers that serve the API and Web page/client). For the future, we’d like to leverage a service that we can upload images to and request whatever size we want as we need them, thereby offloading the hardware intensive operation of image manipulation to someone else.

During “Christmas”

On the second day after “Christmas” began, we were woken up early in the morning by a notification that our server response times had slowed to a crawl due to traffic. The frontend server’s resources were maxed out. This, admittedly, was not our favorite way to start the weekend. #startuplife

We deployed a second frontend server and routed half the traffic to that server.

To review: At this point, we now had:

2 frontend servers
1 HAProxy/stunnel server
1 Redis server
1 MySQL server
1 batch server (running miscellaneous daemons)
4 image resizing servers

From that point onward, we kept an eye on servers and rolled out new EC2 instances as traffic increased. (We maxed out at 15 EC2 instances.)

Prior to adding all those servers, we came across another issue in testing that we waited to fix until we actually needed it: We realized that the larger EC2 instances had multiple CPUs available that would go mostly unused on our API servers due to the fact that node.js is single threaded. The HAProxy server was only pointed at one instance per box. We waited to deploy a fix because the solution was somewhat experimental — we didn’t want a “guess” to go to production. Yeah, it turns out we should’ve gambled on that guess.

All the while, whenever we would update the HAProxy configuration to handle our latest scaling solution, Avocado would go down for 1 to 2 seconds as our HAProxy restarted, thus loading the new config. Our next task was to create a redundant HAProxy server to prevent any down time.

In response, we used the Elastic Load Balancer to route traffic to the two HAProxy servers. The Elastic Load Balancer also handled the SSL encryption which took a huge load off of the proxy boxes. This allowed us to downsize the proxy boxes considerably, thus saving money in EC2 instance costs.

Everything seemed good. For, like, five minutes. Then there was socket.io.

We discovered our socket.io servers began to seriously eat up resources. Up to this point, we had a single socket.io server instance running on one of our two frontend servers. Which meant if we ever needed to update the frontend server, even if it had nothing to do with socket.io, our socket.io server would go down. It would only be a blip, but it’d still result in downtime. Downtime = sad users.

Scaling socket.io to multiple servers is tricky because if a user is connected to one socket.io server, they need to stay connected to that same one for the entire session – another socket.io server won’t have their credentials if they’re suddenly moved. So, we used something called “sticky sessions” to keep users connected to the same server for the life of their session. (When you home screen the app, we close the socket.io connection, and when you open the app again, we create another socket.io connection for the user.) Sticky sessions sets a cookie for the life of the session so it knows what socket.io server to send you to every single time. HAProxy will see that cookie and send you to the right socket.io server.

On that note, we’d like to say that while WebSockets are the new hotness (and while socket.io takes advantage of it), mobile apps should be warned, Websockets will not work on some cellular networks worldwide.

Instead, we had to use XHR-polling with socket.io, which uses HTTP requests to simulate a real-time connection. Furthermore, Amazon’s Elastic Load Balancer didn’t support WebSockets, so we had to use XHR-polling regardless.

Once that issue was resolved, we scaled out to two socket.io servers. After this initial scaling, we moved the socket.io server to its own box – inside of that we could have 8 socket.io servers (one per CPU), so we had a total of 16 instances of socket.io servers.

I’m sure at this point you’re saying, “16 socket.io servers?! You’re doing something wrong.” And in thinking that, you’d be right. So, we changed something else to improve our performance: database connection pooling.

Prior to this we had one connection to the database per server instance. Any time a process wanted to talk to our database it had to get in line. The process happened so quickly that the line wasn’t very long, but since we only had a single connection per server instance we ended up using a lot more resources than necessary.

For example, our socket.io servers were eating up 60 percent of the box’s CPUs across all 8 cores because of only having one connection to the database per socket.io server instance. When we added the connection pooling, we added anywhere from 2 to 10 connections to the database per server instance.

We didn’t do this connection pooling before mostly due to lack of time and because we didn’t want to make major changes to our database code with only three days before the promotion. The connection pooling meant that usage went from 60 percent of CPU to 3 percent. Response times were dramatically improved all around.

Going international

Our “Christmas” event took us global. And we hadn’t adequately prepared for that. Users in other parts of the world were connecting to our servers all the way in NorCal. And that meant sloooow connections. We have since launched servers throughout the world, relying on Amazon to route traffic based on latency.

And that’s all part of our…

Post-Christmas planning

We’re still in the afterglow of this growth and while things are slightly less hectic, we also have quite a few other big events planned, and each of those mean more scaling.

We expect to be using auto-deployment strategies. For example, Amazon will deploy new boxes automatically based on certain metrics, letting us deploy new servers when their average CPU usage exceeds a certain percentage.

One concern we’re talking about though: if you do auto-scaling wrong you might accidentally deploy 100 boxes… and then you’re paying for 100 boxes. So we’re cautiously proceeding here.

Biggest lesson learned: It would have been great to start the scaling process much earlier. Due to time pressure we had to make compromises –like dropping four of our media resizer boxes. While throwing more hardware at some scaling problems does work, it’s less than ideal.

Generally, it’s hard to know in advance what you’re going to need unless you know exactly what growth to expect. So plan for the worst, hope for the best, and good luck out there.

TL;DR: Plan ahead. Test your servers until they fall to pieces. Eat your veggies.

P.S. We’re hosting an Android Hack Night during Google IO this year; come by and chat us up if you want to learn more about what we did.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

But it’s also not often that someone invents an open-source game development platform that can make Minecraft-style games that will, with a little luck, soon be running on web browsers everywhere: laptops, Android phones, and iPhones.

Twenty-two days ago, Max Ogden was a bored developer whose latest startup, Gather, was not, shall we say, making a lot of hay. So he was looking for something new to occupy his time.

“I came back from Europe in the winter working on a bunch of little indoor projects — it’s been freezing here in the Bay area,” Ogden told me today. “Then I saw the Minecraft documentary right after Christmas.”

He had given the wildly popular sandbox builder to his 10- and 11-year-old nephews for Christmas, and they loved it, so he started to think about building something for it — a mod perhaps, or an extension of Minecraft. And was startled to find that Minecraft was totally closed source, with no API (though one is coming soon). Instead, he discovered that developers who want to mod Minecraft hack it, decompile the code, build their mods, and then release them … to be broken with every new version of the game.

A forest in Voxel.

So he came up with the idea of building not just Minecraft, but the toolset to build any Minecraft-like game, all inside the browser, using common old Javascript and OpenGL, an industry-standard toolkit for building interactive 2-D and 3-D applications.

“OpenGL has been around for a long time, but Chrome became the first browser just last month that lets you take over someone’s mouse pointer, which is totally needed for games,” Ogden said.

Having found his project, Ogden did nothing else for the past three weeks, staying up late, “going crazy,” and cranking out code. He found numerous little snippets of code that others had worked on that helped, speeding the process, and brought in a friend, James Halliday, to help solve some particularly tough problems.

“In about two days of working with James, it all came together,” Ogden said. “We had something that looked like a game, and we looked at each other and said: ‘Holy cow, that was quick.’”

The result that looked like a game was Voxel.js. It’s not precisely a game itself, but a game-building toolkit for modern browsers. You can try early examples of game environments built with it already, right in your (Chrome) browser, including one with a virtual drone simulator.

A Minecraft skin

“Kyle Robinson, who runs hackathons for AR quadricopter drones, built a virtual drone simulator for it,” Odgen told me, marveling. “It has a command line, you can tell it to take off, spin, and it has a little camera to ‘see’ the terrain that shows up like an iPad in the game.”

Which is all very meta: watching a landscape of a virtual world via a virtual drone that you control in a game running inside a browser on your computer. It sounds impressive, until you hear that another acquaintance of Odgen is planning to run Voxel.js on a Raspberry Pi running Firefox OS (coming soon) on a real AR quadricopter videoing the actual landscape while also running the game and viewing a virtual landscape.

Just try to wrap your head around that.

All the code is open source, and Odgen is welcoming any and all hackers to make contributions, adding modules like water, better physics, or creatures. Seven already have. All of which could soon have the game-building environment running on iPhones as well as Android smartphones. While Android should be relatively easy as soon as Google updates mobile Chrome to support OpenGL more fully, iOS is another story. It turns out that Apple supports OpenGL in mobile Safari, but for iAds only.

“So you can run WebGL on iPhone … if you make your own browser,” he said.

Fortunately, a project named Impact is working on a solution, rendering Javascript to iOS’s native Objective-C language.

All of which means that a Minecraft-like game built with Voxel.js could conceivably run in a browser on an iPhone. And on an Android smartphone. And in your web browser on your laptop. And, if you really, really, really must, on a tiny little $35 Raspberry Pi, flying high on a quadricopter above the drunken old ladies of Oakland.

Which, frankly, would be awesome.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

The past 12 months have been an exciting ride over here at DevBeat. We’ve had thrilling announcements, head-scratching corporate maneuvers, and more than a little bit of developer drama.

But as we prepare to take on 2013, we don’t want to offer just empty reflections on the year that’s passed. Rather, here are the big lessons we learned from the top developer news stories of 2012.

As always, we welcome your own reflections, stories, and lessons learned in the comments.

The Node hype cycle peaks

The year began with Node.js creator Ryan Dahl backing not-so-slowly away from the technology’s day-to-day operations inside Joyent, hinting on Twitter that he was a bit Node’d out. But as Node was passed into the hands of other caretakers, it was also gaining traction at larger companies and within larger applications. Walmart started using it. Google and Mozilla talked about how it can scale, and LinkedIn used it for its revamped mobile suite. And Yahoo used it to build a better mobile browser.

The story: “Also, let’s point out the obvious: For all these open-source programming technologies (PHP, Ruby, and now Node), there’s a killing to be made in offering enterprise-grade services and support for the more popular choices among them. And Node is nothing if not popular; late last year, Node eclipsed Ruby to become the most-watched repo on GitHub.”

The moral: Node is cool, sure, but it’s also grown-up enough for the enterprise and scaled apps.

The open-source hardware trend comes of age

After a good couple years of banging on its Open Compute Project, Facebook saw its project take flight this year, with new supporters in high places. And it wasn’t just Facebook; other companies started talking about open-source hardware and support for hardware hackers. From startups like Circuits.io and Upverter to the big guys with data centers to spare, everyone seems to be well on board with this trend — except Google, oddly enough.

The story: “‘Open Compute might evolve into a broader focus over time,’ said Facebook exec Frank Frankovsky. There’s a possibility that the same open-source workflow that’s being applied to this data center hardware might someday be applied to other networked devices and even mobile devices. Can you imagine, for example, how the community might work together to solve issues like cellphone battery life? ‘We might spread our wings,” Frankovsky concluded, ‘but for now, we want to stay focused on data centers, servers, and storage.’”

The moral: We should all care a little bit more about the energy it takes to process a click. And the answer isn’t fewer clicks; it’s collaborative work on energy-efficient hardware.

The lean startup ethic backfires

The tale of Curebit isn’t a pleasant one to recall. The young team of Y Combinator/500 Startups acolytes were doing their best to build a company the lean way, but they ended leaning a little too far toward outright theft. After getting caught red-handed stealing images, code, and even background music for their demo video, they were forced to publicly apologize, and their reputation was badly tarnished by the whole ugly episode.

The story: “On Twitter, some of the Internet’s more colorful personalities are currently battling it out in a war of colorful words. After the discovery, Ruby on Rails creator and thievery victim DHH called the Curebit team ‘fucking scumbags’ and Grant himself ‘a person of poor moral character.’”

The moral: Yes, Virginia, there is such a thing as a moral absolute. Even if you’re a cheap bastard.

The continuing war between responsive mobile web apps and nativists

No topic has been bandied about with more rancor than the mobile web — specifically, whether HTML 5-based mobile web applications can or ever will compete in terms of design and performance with native mobile applications.

After open-sourcing Ringmark, a first stab at a testing suite and standards for mobile browsers, Facebook seemed to be leading the charge to defend mobile web apps. And it had Mozilla, LinkedIn, Adobe, and a slew of others in tow. Then it released an all-native iPhone app, with Mark Zuckerberg saying that his company’s bet on the mobile web was all a huge mistake. It was basically the mobile web debate in a nutshell.

Like Facebook, we’re all still working and hoping for a better mobile web next year. And this time, we’re looking toward Mozilla’s die-hard mobile web guys to lead the charge.

The story: “You would think, given their identical aspirations, the three titans — Facebook, Yahoo, and Google — would pool their boundless resources to fast-track the mobile web from the janky, derided ghetto it is to the elegant utopia each of these parties sees in the near future. Yet they remain divided rather than collaborating, which means consumers lose and innovation stagnates.”

The moral: The mobile web is still a far-off ideal, but we’ll get there someday.

Twitter gives Ruby on Rails the kiss-off

Back in the summer of 2011, Twitter started quietly moving away from Ruby on Rails and toward Java/Scala. The “Ruby can’t scale” dictum had already grown tired in developer circles by then. But when Twitter faced its biggest challenge of scale to date — the 2012 presidential election — it held up beautifully. And Ruby on Rails was nowhere in sight. In talking with the company’s architecture demigods, we learned that Twitter’s capability to stay afloat during record-breaking traffic cost the company quite a bit, but its new architecture was the primary reason no fail whales were sighted that November night.

The story: “While Twitter used to see brief spikes during major media events, Twitter infrastructure VP Mazen Rawashdeh wrote today on the company blog that election night was a sustained, hours-long onslaught of activity. … ‘The bottom line: No matter when, where, or how people use Twitter, we need to remain accessible 24/7, around the world,’ said Twitter infrastructure VP Mazen Rawashdeh. ‘We’re hard at work delivering on that vision.’”

The moral: Dude. Your app is not Twitter-scale, and it probably never will be. Relax.

Twitter finally shuts down its API

And speaking of Twitter, the microblogging-service-that-could finally delivered on a two-year-old promise to stop giving away free candy vis-a-vis its API and the host of traffic-stealing Twitter clients built on said API. Since its first (and only) developer conference in 2010, Twitter had been gently pleading with developers to not build Twitter clients that duplicated the core Twitter experience. And it put teeth in those requests by buying up the Twitter clients it liked — namely, Tweetie and Tweetdeck. So when Twitter finally turned the garden hose off, so to speak, no one was surprised … right?

The story: “Twitter has put the kibosh on unofficial consumer clients for Twitter; the only loophole is for apps that have 100,000 users or fewer. The Twheel team has just decided that to keep the app alive, they’re going to take that loophole. And in an Internet economy where eyeballs equal money, 100,000 users or fewer still meets our definition of ‘doomed.’ You can’t raise funding on 100,000 users, and you can’t sell ads against 100,000 users — not enough ads to support a whole company, anyhow.”

The moral: This should have happened a long time ago, but better late than never — at least for Twitter’s business.

The “learn to code” craze

By far, our favorite ongoing story of the year has been normal people learning how to code. It’s been equally exciting to watch the crop of code-teaching startups spring up, get funding, and acquire huge numbers of users — and even revenue. From Codecademy to Treehouse to Bloc to Code School to Hackbright, we love how nerdy developers are showing everyone “the man behind the curtain” and proving that anyone — even women, even underprivileged kids, even poor folks — can improve their circumstances or understand the Internet better with a little effort and a little intelligence.

The story: “Jalen Rose is a year-old institution located in the northwest part of Detroit, where high school diplomas are not the norm in many students’ families and social spheres. Currently, only 32 percent of Detroit high school students graduate in four years. In a recent conversation with Treehouse founder and web guru Ryan Carson, we learned that Carson sees Treehouse (and coding education in general) as a world-changing stepping stone for underserved kids who can’t afford to — and maybe don’t need to — go to college.”

The moral: The world is a better place when users become builders and learn that code is not magic.

Image credits: konstantynov/Shutterstock, Ioannis Pantzi/Shutterstock, Jolie O’Dell/Flickr, Rafael Edwards/Flickr, lightpoet/Shutterstock

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

A certain kind of developer loves to hate on PHP. They are really going to hate where PHP’s custodians are taking it next.

PHP was created by Danish programmer Rasmus Lerdorf in 1995. In 1997, Israeli programmers Andi Gutmans and Zeev Suraski rewrote the parser, creating the base for PHP 3. By 1999, they had built the Zend Engine, which is still the interpreter for PHP.

Update October 18: Andi Gutmans just gave us more details about where PHP is going in mobile.

Gutmans and Suraski continued their partnership with Zend Technologies, a commercial entity that creates add-on products and services for PHP developers, particularly developers in the enterprise.

Today, after multiple massive iterations to the codebase, 35 percent of web traffic is handled by PHP, says Gutmans. Wikipedia says 75 percent of websites use PHP. Facebook, Wikipedia, Yahoo, and Photobucket are all built in PHP. WordPress, the most popular blogging platform in the world, runs on PHP and probably accounts for half of that 35 percent. Most of the other major content management systems, such as Drupal and Joomla, are also built in PHP.

No respect?

Still, the language can’t seem to get any respect and has been derided for years by programmers coding in C, Java, .NET, Python, or Ruby. In terms of trends, PHP as a search term has been dropping for years, and the mobile app revolution has led to the revival of Objective-C and Java.

So is the programming language that powers so much of the web disappearing gently into the night?

Not if Gutmans has anything to say about it. VentureBeat talked to him about PHP and the future, and he’s more bullish than ever, especially when it comes to the mobile-focused ace up his sleeve.

Riding the U.S.S. Enterprise

“All dynamic languages are gaining share from Java and .NET right now,” says Gutmans. “We’re getting a lot of benefit.”

Source: Wikipedia

Andi Gutmans

So the noise around trendier technologies like Ruby on Rails or Node.js doesn’t especially bother him. Mindshare is nice, of course, but market share is nicer. And market share is what Gutmans is focused on, especially in the enterprise.

“From a maturity point of view,” Gutmans told me, “I don’t think any other dynamic language right now has the full tool set. Our competition is Java and .NET … never with other dynamic languages.”

While he likes what Ruby on Rails is doing, and thinks there are some things there that PHP can learn and grow from, Gutmans points to PHP’s massive support in packaged solutions like WordPress, Drupal, and Magento.

“We’re better off than we were eight years ago … today we’re the only ones who have really hit the mainstream enterprise,” says Gutmans. “We do believe that the momentum and the size of PHP will continue. We don’t see it slowing down right now.”

Gutmans speaks with the enthusiasm of a founder; of course, there are other companies catering to the PHP-related needs of the enterprise. But Zend remains one of the biggest and best-known, especially due to its provenance.

And he’s got a point: Two-thirds of developers in a recent study reported spending half their time in PHP. And in a recent study by Rails developer Marc Gayle, half of all developer job postings on Craigslist call for PHP developers. When I talked to Gayle, he surmised the reason might be PHP’s super-popular content management systems.

“I think that is skewing the results,” he said. “But I can’t be sure.”

And a mysterious mobile story, coming soon

When it comes to mobile apps, Gutmans sides with the likes of JavaScript creator Brendan Eich in a firmly held belief that the web and web languages will eventually catch up and win out over native stacks.

But, he hinted to me, PHP and Zend will be providing client-side app-enabling tools.

Gutmans declined to comment further, saying he would only announce the full details at Zend’s conference in late October. However, it sounds like PHP will have a mobile app story of some sort, in spite of being the web’s predominant server-side language.

What that looks like and how it will be distributed is still mysterious. But a strong mobile story, says Gutmans, will only help PHP continue to grow.

It’s hard to argue with that.

photo credit: Red Bonzai

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Platform-as-a-Service startup AppFog has acquired leading Node.js PaaS Nodester in a move that gives AppFog even greater versatility for the 60,000 developers using its service.

AppFog’s PaaS offers developers an incredible range of languages to work with including Java, Python, Node, .Net, Ruby, PHP, MySQL, Mongo, Django, and PostgreSQL. However, AppFog was missing WebSocket support while Nodester did offer it. So AppFog is buying Nodester to fill in the blanks and extend its reach even further to the many developers excited about Node.js.

“This adds needed breadth and depth to our Node.js support,” AppFog CEO Lucas Carlson told me. “It’s a slam dunk and makes perfect sense.”

Carlson said the number of developers selecting AppFog for their PaaS of choice has substantially increased as of late. “A year ago, we had 10,000 developers,” Carlson said. “A month ago, we had 40,000 developers. Today, we have 60,000 developers. It’s exponential.”

AppFog is smart to jump on Node. As my colleague Jolie O’Dell noted, it’s the most hyped-up programming technology since Ruby on Rails and the most popular repository on Github. Notably, PaaS provider Engine Yard launched its platform-as-a-service offering for Node just a week ago.

Ideally, with Nodester in its pocket, AppFog wants to be the most powerful and flexible Node supporter in the PaaS arena. Take a look at the AppFog-provided chart below to see some comparisons of AppFog versus Heroku, Google, Microsoft, and others.

Portland, Ore.-based AppFog has raised $9.8 million in funding to date. Investors include Ignition Partners, Madrona Venture Group, First Round Capital, and Founder’s Co-op.

The terms of the AppFog/Nodester deal were not revealed. You can read a lengthy interview with AppFog’s Carlson here.

Photo credits: AppFog

CloudBeat 2012 is assembling the biggest names in the cloud’s evolving story to learn about real cases of revolutionary cloud adoption. Unlike other cloud events, customers — the users of cloud technologies — will be front and center. Their discussions with vendors and other experts will give you rare insights into what really works, who’s buying what, and where the industry is going. Register now and save 25 percent! The early-bird discount ends September 14.

Node, the JavaScript-based programming technology, has for some time been web startups’ favorite flavor of the month, and now it’s becoming more accessible to enterprise-level applications, thanks to the fine folks at Engine Yard.

Engine Yard Cloud is a commercial grade, highly configurable platform-as-a-service for Ruby on Rails and PHP apps; starting today, it’ll also support Node apps.

The addition of Node.js to the happy Engine Yard family is a great sign that the Node Trend Train is still chugging along at top speed and that Node is, as we and Node core contributor/Rackspace engineer Paul Querna have been saying for ages, ready for the big time.

The Node-meets-cloud offering, aside from being a mashup of two insanely popular trends, also makes good business sense as older companies are harnessing newer tech to get their various jobs done.

“We’ve been using Node.js on Engine Yard Cloud to develop a production app for NW Natural, the largest independent natural gas utility in the U.S. Pacific Northwest,” said Patrick Ezell, principal of digital shop COPIOUS, in a statement on the news.

“The combination of Node.js and the Engine Yard PaaS enables us to deliver an innovative, high-performance app that scales seamlessly across desktop, laptop, tablets, and mobile.”

Also, let’s point out the obvious: For all these open-source programming technologies (PHP, Ruby, and now Node), there’s a killing to be made in offering enterprise-grade services and support for the more popular choices among them. And Node is nothing if not popular; late last year, Node eclipsed Ruby to become the most-watched repo on GitHub.

“As the leading PaaS provider, Engine Yard is proud to demonstrate its ongoing commitment to the developer community by supporting the latest technologies and offering a choice of frameworks and infrastructure as a service options,” said Engine Yard ops VP Bill Platt in a statement on the news.

“We continue to provide our customers with a superior platform so they can build high-performing Web applications that engage customers more effectively. Our platform provides the reliability, flexibility and deep expertise across Ruby on Rails, PHP, and Node.js, empowering enterprises and developers to focus on innovation that drives business growth.”

Top image courtesy of Ioannis Pantzi, Shutterstock

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Hell has frozen over; someone actually made an infographic about Node.js.

Ok, ok; we’re exaggerating a little bit. But we really don’t get too many infographics around here for developer topics; that alone is unusual.

But this is Node, man, the most hyped-up programming technology since Ruby on Rails (and then some), and its popularity cannot be denied.

Engine Yard just launched its platform-as-a-service offering for Node today, and they released this infographic along with it. It’s got a lot of the stats you already know if you’ve been following the Node news around the web, all packaged in a groovy color scheme with some nifty graphics.

Check ‘er out (and click to see the gigantor-sized version):

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

An aspiring hardware hacker at Twilio has used his company’s own telephony APIs as well as Node.js and Arduino to build the charming robot you see in the clip above.

We just about overloaded on developer buzzwords there, so let’s back it up a bit.

The bot was built by Twilio developer evangelist Jonathan Gottfried, to whom we say, nice work, Jon! There’s no quicker way to developers’ hearts than showing them how to build and code a robot, and no better way to evangelize for your company’s software than by using it in said robot in an actually interesting way. Twilio overlords, give this man a raise!

“Robots have fascinated me for as long as I can remember,” writes Gottfried on the company blog. He then proceeds to go into great, and we mean great, detail on how the bot was made “using Twilio, Arduino, Node.js, and the RN-XV WiFly module.”

The result is a robot you can control from your phone’s keypad. The post includes step-by-step images and lots of code snippets.

You might be asking, “Why, why in heaven’s name, would anyone use Node for such a task?” The Hacker News army asked the same thing, to which Gottfried replied, “It was the easiest way I found to set up a simultaneous HTTP server and TCP socket to the bot.”

In the HN thread, Gottfried also said, “The hardest part for me was getting the Wi-Fi module to work,” and, “It’s pretty fun to play with, honestly. Hasn’t tried to kill me yet….”

That’s about to change. We’ve seen the next step — and it’s a really awesome, significant step — in mobile browsers, and it was made by none other than Yahoo.

Today, Yahoo launches Axis, a new way of getting around the web, both on mobile and in your typical desktop browser. Axis is available as a standalone web browser on iOS devices now (other platforms such as Windows Phone and Android are coming soon) and as an extension for Chrome, Firefox, and Safari.

Yes, the tech press loves to hound Yahoo about its executive troubles and its oldster status, but the fact remains that the company still employs some of the best, brightest engineers I’ve met, and it is very much focused on creating bigger, better mobile products.

To explain Axis, we have to start with search — something that many have assumed Yahoo had given up. “Far from being outside the search game, we’re very much invested in it,” said Ethan Batraski, Yahoo’s director of product management for search, in a meeting with VentureBeat last week.

Bing has lately powering the Yahoo portal’s web search, but this has freed up Yahoo’s intellectual and engineering workforce “to rethink search… as a human experience in three steps,” said Batraski.

Those three steps — the query, the results, and the destination page — have long been locked in a lather-rinse-repeat loop, with users navigating back to a results page when the destination page is lacking, or refining their queries when the results page seems off.

“No matter how much Google or Bing tries to innovate on that experience, it’s pretty much the same way it’s been for the past decade,” said Batraski. And on small-screened phones and tablets with non-optimal wireless connections, that experience is as painful as a first-world technophile could imagine. Axis does something different, bringing queries closer to the objects they represent and bringing more data onto the results page for quicker, simpler, lower-bandwidth decision-making

Here’s how it works: You enter your search term, and Yahoo does some heavy lifting (not Bing-powered). You have the option of selecting a specific object that your query is related to; for example, if you search for “Roots,” Axis might give you options to refine the search for “Roots” the TV miniseries or “The Roots” the band. In that way, it’s quite similar to Google’s newly launched Knowledge Base. It can also direct you to “instant answers,” kind of like what Bing does these days.

That’s when things get really nifty. Axis serves up thumbnails and page previews as results instead of just a list of links, and the results are still available as you navigate through destination pages. Any time you need to get back to the results, you just pull down on the screen, and a horizontal slider of results from your last query appear at the top.

This is one case where a picture is worth a thousand words, so check out the images below (captured on an iPad) to get a better idea of how the mobile browser navigation works:

You can also see demo videos from Yahoo over here.

The main point is, you don’t have to go back and forth over a painfully slow connection to do normal web search; the results are just a finger-flick away at all times, and they’re stored in a convenient, visual slider that won’t hog the already small screen. It’s brilliant and long overdue.

Naturally, the browser also brings the features you’d expect from a modern app: tabbed browsing, gorgeous image search, bookmarks, social sharing options for every page, etc.

In addition to the usual suspects in mobile devices, keep an eye out for Axis on gaming consoles and smart TVs, where search and web browsing are equally painful for similar reasons.

Batraski said he got the idea while on vacation. “I was sitting in Bermuda on a chair with a margarita, and it dawns on me: There’s no real need for a results page. I’ve never been a big fan of it. So by building it into the browser, it’s the most utilitarian way of getting to content.” Six months later, the apps were built.

On feature of particular note is the desktop-to-mobile sync option for open tabs. Firefox for Android and Chrome for Android also have this feature, but until now, it hasn’t been an option for iPhone and iPad users.

That brings us to our next point: It’s absolutely fascinating to see this innovation in mobile browser tech making its debut on iOS. Mozilla has been blocked from putting its Firefox mobile browser on the iPhone and other Apple devices, and we’re pretty sure Google wouldn’t even have bothered to ask, given Apple’s history with outside mobile browsers. But for some reason, this Yahoo browser is the exception to the rule.

“Yahoo has a really good relationship with Apple,” said Batraski. “We power their weather and finance apps.” Batraski also pointed out that, while Axis for iOS uses the Safari web view API, “it’s a complete different browser, and it runs separately from Safari.”

Of course, techies will be quick to pick up and play with the mobile browser and related extensions, but what about the rest of the world?

“Any time you show something this different, it takes users time to adopt,” said Batraski. “Right now, we’re seeing a lot of traction with tech-forward users, where they really understand this makes the experience a lot more efficient.”

As for the less digitally minded masses, he said, “This is not the first time Yahoo has been in the browser business,” referring to the company’s Yahoo-tools-stuffed Firefox and Internet Explorer bundles, which currently claim “well over 100M users.” Axis will be built into Yahoo’s new browser bundles, and the company expects to see mainstream adoption start there.

Of course, any good idea begets other, eerily similar good ideas from competing companies. Batraski said he won’t be surprised to see Google or Microsoft lift the Axis interface and user experience for their own purposes. “I won’t be pissed off; I almost expect it,” he said.

“When they see it, I think they’re going to be really peeved: ‘Why didn’t I think of that’ It’s likely to cannibalize their search experience, and I don’t think they’re ready for that.”

Another interesting note is the browser’s architecture. Yahoo has been churning out some interesting mobile web-focused, Node.js-based tools called Cocktails, and it’s now clear why: The Axis team needed these tools to build the browser and extensions.

“Axis is the first fully Cocktails app we’re going to launch,” said Batraski. “We run off Manhattan as the app server, and then use the Mojito layer for a number of modular applications.”

Top image courtesy of David Hammonds, Shutterstock

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Guess how much of LinkedIn’s new iPad app is actually mobile web and not native.

Go ahead — guess. We’ve had a lot of fun asking people to guess this over the past couple days. They’ll start with 40 percent and edge up to 70 percent, but no one comes close to the real figure: 95 percent.

Yes, only one screen in the entire LinkedIn iPad app is actually native. The rest is good ol’ HTML5-based mobile web technology, running in the browser and leaning heavily on Node.js.

We were shocked to hear this 95-percent figure from Kiran Prasad, who heads up LinkedIn’s mobile development team. Shocked, but not appalled — after all, Prasad was the engineering heft behind the company’s recent slew of gorgeous mobile apps, which were also heavily reliant on the mobile web.

But the new iPad app had struck us as so surprisingly sexy during our initial review that we had to know more about how Prasad and his team of four (yep, just four devs built this app) packed so much punch into a web app for a tablet.

Especially as Silicon Valley tech companies pick sides in the web-versus-native war, it’s fascinating to see the presumably conservative LinkedIn lean toward the more progressive side of mobile technology. But this is a stance this team has taken for a while now, and LinkedIn is currently one of the mobile web’s biggest supporters and strongest case studies.

LinkedIn and the mobile web

“Last year, we had just launched three different phone apps. We were starting to invest more in HTML5,” Prasad told VentureBeat yesterday.

“We had a 60/40 split where about 60 percent of any app was in HTML5.”

LinkedIn’s big news at that time was how it had employed Node.js in its at-scale mobile apps — what seemed to many to be a pretty big gamble for the company. But the other part of the story was how Prasad and his team combined native and mobile web functionality in iPhone and Android apps, creating hybrids that bridged the divide in the native-versus-web mobile debate.

Now, Prasad said the company relies on mobile web technologies more than ever. “Because we made that full investment, being able to get the mobile web on a tablet was really doable,” he said.

Of course, being able to have greater developer efficiency was a draw, but Prasad said that would never have come at the expense of creating a beautiful, responsive app that would be a pleasure to use.

“We always focus on user experience and app speed as a number one priority,” he told us. “If the performance wasn’t there, we wouldn’t have gone with the web.

“But with the iPad having the faster processor and being a more powerful mobile device, we felt like the web-based version could give us the performance we needed.”

In the end, Prasad continued, it came down to the little things: Did onscreen buttons depress and pop back up quickly when tapped with a fingertip? Was scrolling snappy? Did crossfades occur smoothly and without any lag?

“We did users studies in-house, and I don’t think people noticed a big difference. Nobody said, ‘Oh that’s native,’ or ‘Oh, that’s web,’” said Prasad. “As long as we can make the experience fast enough, nobody can tell the difference. It still feels right.”

And a lot of that performance, Prasad said, came from removing unnecessary design wankery (our verbiage, not his) — the rounded corners, the omnipresent gradients. By making things simple, clean, modern, flat, and even print magazine-like, the LinkedIn app only got faster and better on the performance side, as well.

“Our focus on trying to get a simpler design is actually helping us make things faster. It’s a good feedback loop,” said Prasad.

Here are some screenshots of those super-speedy mobile web pages for your reference. The first slide shows the sole native page:

Now, with more Node.js

In addition to seriously beefing up the company’s mobile web investment, Prasad is also leaning more heavily on Node.js — and with more confidence.

“We’re still full-on Node. We are excited that it can scale,” he said. “Over the past few months, we’ve made performance tweaks so we can scale even more. On four boxes, we can now handle 20 times the load we were handling before.”

Prasad said the company used to use nginx, an open source Web server and a reverse proxy server, due to the engineering team’s concerns about the stability of Node. “It was there to make us feel comfortable,” said Prasad. “If any of the nodes went down, nginx would report the errors.”

Today, however, Prasad no longer feels the need for the security blanket. “In the tablet version of the server, we’re still using Node, but now the clients are talking directly from the load balancers to Node, there’s no nginx.”

In addition to experiencing a growing confidence in the technology itself, Prasad et al. are also contributing to Node’s growing ecosystem of tools — stay tuned for those to be open-sourced.

“Some of the changes we’ve made are Node modules we’re going to release back into the community,” he said. “Some of it is application-specific… But overall, the tools for Node are becoming better.”

“Responsive design” just doesn’t work

Finally, Prasad wrapped up with an impassioned statement on a new trend in mobile applications: responsive design.

The core concept of responsive design is that the designer/developer would create a single design that can scale up and down fluidly across scores of different devices — laptops, tablets, TVs, mobile phones, etc. Many advocates exist for this solution to widespread connected-device fragmentation, and these advocates have founded companies and launched tools specifically to make responsive design simpler and faster.

But Prasad thinks it’s all wrong. Responsive design might work for uncomplicated, one-off websites, he said, but for applications or networks (such as LinkedIn is), responsive design is actually bad.

“We’re looking at the ‘entrenched’ use case [for desktop users], the coffee-and-couch use case [for tablet users], the two-minute use case [for mobile phone users],” Prasad said, rapidly outlining a few of the ways people are interacting with digital information and highlighting how unique each of those scenarios can be — and how different are the needs they present.

“You can’t take a mobile app and just scale it up to tablet or desktop,” he said. “A lot of responsive design is building one site that works everywhere, and that works for websites. But it’s bad for apps… You have to come up with a completely different design because of the use case.”

Top image courtesy of Yuganov Konstantin, Shutterstock

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Today, Yahoo is open-sourcing Mojito, a bit of software that uses JavaScript and Node.js to run a single codebase on both the client and server side.

Mojito is one of a few Node-centric projects Yahoo’s been brewing. Collectively called Cocktails, they embrace cutting-edge technologies and platforms in a way that is surprising if you haven’t been following developer news from Yahoo over the past couple of years.

Yahoo started dabbling in Cocktails a while ago. Bruno Fernandez-Ruiz, Yahoo’s platform vice president, has called Cocktails “a bunch of tricks to make web applications feel native.”

Today’s release, Mojito, is a first step in that direction.

“There are some JavaScript frameworks out there, and some of them focus on the server side, some run on the client side,” said Fernandez-Ruiz in a recent phone conversation with VentureBeat. “And we’ve been saying for some time that we want people to be able to run the same code on the client side and on the server side.”

From the Yahoo developer blog:

• Mojito is all JavaScript, that’s good. JavaScript is the single most widely available programming language today, and that’s something worth taking advantage of.
• Mojito is a true MVC framework, that’s better! MVC is a battle-tested design pattern, having proven its usefulness in desktop apps, in server-side apps, in, today, rich client-side applications. Those who ignore MVC… often reinvent it.
• But the best part of Mojito is its ability to “blur” the client/server boundary, to let you write you code that runs on the client, or the server. Or both.

The reason, said Fernandez-Ruiz, is all about performance and how mobile web pages are rendered for smartphone users. It’s about speed, and it’s also about experience. “The reality is, if you go around looking at websites on an iPhone, you realize that many web pages just don’t work well,” he said. “Things are partially loaded, sometimes you get blank pages. Most of the time, this is because JavaScript that is downloaded never gets to run on the client … On the desktop, you can get away with murder, but on mobile, it’s another story.”

When mobile users are constantly testing the limits of their 3G networks, the exec said, it adds up to a really crappy experience for everyone.

Mojito is part of Yahoo’s concerted effort to help developers work with mobile users and with mobile networks in mind.

Mojito is just one Cocktail. Manhattan is another; it’s a Node.js hosted environment for Mojito. Apps can be wrapped in a native shell and shipped to the iTunes App Store or the Android Market or simply run in a browser, and Manhattan helps to speed up the user experience access across high- and low-speed networks and to run apps on platforms that don’t have full HTML5/CSS3 support.

Other Cocktails under development right now include Greyhound and Screwdriver; Yahoo has no official word yet on what those products will do or when they might be available to outside developers.

“We have been approaching some developers … to get feedback about our technology stack,” said Fernandez-Ruiz. “There’s a lot of documentation and support to make it healthy, you can’t just dump the code on Github. We have a good track record of open sourcing things and keeping them alive.”

Manhattan will be opened up for use by attendees at this week’s JS Conf. Fernandez-Ruiz said Yahoo plans to gather input and feedback from those developers and use it to determine the next steps for Manhattan.

In the meantime, Mojito is open and available for anyone to use. Fernandez-Ruiz said he hopes developers will take a look a Node, at Mojito, and at their mobile work with new eyes open to the inherent performance benefits these technologies have to offer.

“It’s time to revisit the web, to take a look at mobile networks where people are constrained and where battery life has limits,” he said. “Node.js is, in a way, like a browser that runs on the server. The browser on the mobile phone isn’t that powerful, so Node.js becomes more important.”

“If you look at OSI stack, this is like networking stuff, how you get routed,” Fernandez-Ruiz said. “Your objective is to create network servers that are efficient and low profile, very lean, something that lets you work very close to the kernel. For embedded devices that are partially connected — TVs or car devices, too — Node.js is very interesting.”

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Dahl, who started working on the Node project in 2009, stated in a Google Groups post Monday, “After three years of working on Node, this frees me up to work on research projects. I am still an employee at Joyent and will advise from the sidelines but I won’t be involved in the day-to-day bug fixes.”

Node.js, which was recently named Technology of the Year by InfoWorld, is a system for server-side JavaScript programming. Today, the wildly popular technology has the most-watched repository on Github, making it even more popular than Ruby on Rails.

A status update Dahl posted during the recent Node Summit hinted at a bit of burnout; Node has been one of the most-hyped technologies over the past year or so, and we can’t blame him for wanting to focus on other projects. Maybe something that has absolutely nothing to do with JavaScript.

Also, Node is moving from its infancy into a slightly more mature state and has plenty of capable developers on its team of core contributors; the timing seems right enough for Dahl to step aside somewhat. As a Joyent spokesperson noted in an email to VentureBeat, “This is a natural evolution for a rapidly growing open source project.”

And Node is still in good hands. Schlueter is an Oakland-based programmer who shares Dahl’s current employer, Joyent. Joyent continues to sponsor the development of the Node core even as the company creates enterprise-level support solutions to entice larger companies to use Node.

“Our energy will now be largely focused over the next few months on improving the third party module system experience including a website for browsing modules, a new addon build system, and binary installations from npm,” Dahl continued. “Isaac is in the unique position to bridge the gap between core and external modules to ensure a pleasant experience.”

We’ve contacted Dahl and Joyent for a more detailed statement and will update this post when more information is available.

Image courtesy of franksvalli

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Quizlet is a site you might never have heard of unless you were a teen or an educator, yourself.

The flashcard-focused site helps millions of students who need to memorize information and prepare for tests by making learning both fun and effective.

The teenage founder, Andrew Sutherland (pictured), built the product to solve a personal problem. “I was puttering along with my dad with some call-and-response type quizzing,” he wrote. “‘Man, I love doing this’ was NOT what I was thinking. So I put my thinking cap on, and the first line of code for Quizlet was written that night.”

Of course, the first line of code for Quizlet predated the creation of Node.js, the server-side JavaScript technology that’s on every developer’s fingertips these days. So we got in touch with the Quizlet team to find out why they made the switch.

“We decided to use Node because it was the best technology to enable our new multi-player learning game at our scale,” wrote Quizlet CEO Dave Margulius in an email to VentureBeat.

He explained that “at scale” for Quizlet means around 600,000 visits each day, including heavy bursts of traffic during in-class and after-school hours. All told, the site sees 6 million unique visitors each month and has been doubling in size every year since its public launch in 2007.

“[Node is] also perfect for the collaborative nature of Quizlet,” Margulius continued. “We’ll be doing more and more with it. Also the innovation momentum behind node right now is really compelling.”

When we think about Node, real-time apps and games are two of the verticals that immediately come to mind — those are also two important components of Quizlet’s product.

“Our game, which involves for example a whole class creating sentences out of the same word at the same time and then rating them (with a special teacher view available too), is all real time,” wrote Margulius. “Node can support the speed and number of connections we need to make the game work with minimal latency.”

In an email with VentureBeat, Sutherland chimed in with some words of support for young would-be founders and developers.

“When I started Quizlet, I built it out of my bedroom after school and on weekends while going to high school,” he said. “With all the open source tools available, I was able to figure out the servers, the design, the database, etc. Now it’s even easier with Github and StackOverflow. So really, it’s a matter of pushing yourself.”

He also gives some advice that we’ve heard before from many successful startup founders and investors: Build tools that you, yourself would use; attempt to solve your own problems.

“I built Quizlet not because I wanted to be running my own cool startup, but because I had an idea of a tool that would be helpful to me,” Sutherland wrote. “I was Quizlet’s first user, and many of the best things on there came not from any sort of research or brainstorming, but using the product for my classes and iterating on it.

“So my advice to other students would be to just build something that’s useful and relevant to their lives, and if it’s good you might just find that it’s relevant to a lot of people. It turns out… students think [Quizlet is] a useful tool for themselves, and they tell their friends and teachers about it.”

Check out this interview with Quizlet founder Sutherland, courtesy of Joyent, the company that supports Node.js development and enterprise solutions:

Quizlet is entirely bootstraped and has “significant seven-figure revenue” from advertising and paid products, Margulius tells us.

And if you’re looking for a job, Node-ophilic devs, Quizlet is hiring. “We’re in aggressive innovation and growth mode right now, hiring engineers, building several cool new products, of which the Node.js based multiplayer learning game you saw is one,” said Margulius.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

At the Node Summit today, a bevy of “big boy” company executives gathered to chat about Node.js, the server-side JavaScript technology that’s been taking the developer world by storm.

Representatives from Google, Yahoo, Mozilla, and startup i.TV were on hand to talk about using Node when instability is not an option.

One overarching note: Everyone onstage said they used Express, the Sinatra-like Node.js framework. However — and definitely stay tuned for more news on this — Yahoo said that due to multiple issues its engineers experienced using Express, the company will be open-sourcing its own Node framework within the next few weeks. We’ve already pinged the company for more details and will write a separate update on that subject as soon as we know more.

Yahoo and Node

Yahoo’s developers started playing with Node.js in early 2010. “we’d been trying to figure out server-side JavaScript for a while,” said Bruno Fernandez-Ruiz is Yahoo’s platform vice president, referencing the home-brewed query language Yahoo uses, known as YQL. When the company’s devs found Node, he said, “They were using it for things like file uploads.”

Eventually, the company decided to make a bigger investment. “We wanted to maintain the same code base on the client side and the server side,” said Fernandez-Ruiz. “Node.js was the way to go. We invested over 12 months in this.”

And at the end, the company released Cocktails, a project intended to eliminate the multi-language scenarios that introduce complications for developers. One Cocktail, Mojito, uses JavaScript and Node to run a single codebase both on client and server side. Another is Manhattan, a Node.js hosted environment for Mojito.

“The use of JavaScript and the fact that Node was growing was interesting, and the latency was good,” Fernandez-Ruiz said. “The fears that it won’t stay up… it has required a lot of hand-holding, when you’re going beyond a reasonable number of requests… It’s freaking hard engineering.”

Google and Node

Ask a Googler what the company is doing with Node (I have!), and you’ll get the same answer every time: No comment.

But given the company’s longtime focus on JavaScript and its well-tended garden of competing products, it would be utterly facile to assume that “No comment” means “Nothing.”

Googlers are definitely working on Node projects — perhaps even something big that will be released to the public in the near future. They’re just not ready to talk publicly about what that might be.

Ilya Grigorik, a Googler who uses the professional title “Instigator,” said that while developers within the company do use Node, “There are parallel efforts in Google, as well.” That would be Dart, a new language for structured web programming that Girgorik said “takes something like JavaScript and makes it more object oriented.” Google also has Go, an experimental programming language focused on speed and efficient programming.

“I think there are a lot of interesting alternatives to Node,” Grigorik said.

However, Google isn’t truly pitting its own languages against Node. Node has a huge community and a lot of support from developers — it’s the most popular repo on Github, after all. “Of course, Google doesn’t have the same commuity in the web space,” Grigorik admitted.

And on top of its own programming language projects, said Grigorik, “Google has built a lot of apps that are very heavy in JavaScript… Gmail is something like 450,000 lines of JavaScript.” All that means that Google is likely less anxious to find an entirely new language for its most popular web apps and more likely to find more and better ways to work with JavaScript itself.

The Googler also said that while “a lot of people tend to focus on [Node's] performance, what’s more interesting is the set of constraints it imposes on a developer and what it enables… You can’t shoot yourself in the foot in any way.”

Finally, for a company like Google, “No problem is small,” Grigorik said. “One of the interesting things about building services at scale is figuring out how much you can squeeze out of one CPU core,” he said.

“When you’re building a set of services at planet scale, you don’t have one data center. Disasters would happen,” he said, continuing, “[The Node community] could do a lot to assist with that.”

Finally, Grigorik concluded, “We’re approaching it from all angles… it’s a hard problem to solve, and it’s a real problem.”

Mozilla and Node

Mark Mayo is a principal engineer at Mozilla; he’s working on BrowserID, a cross-platform sign-in technology.

“Mozilla is using Node,” Mayo began. “It’s a big deal when you’re going to expose a service to a browser that has half a billion installs.”

Mayo continued, “We concretely decided to do Node for two reasons: One was the memory footprint… Browser ID was designed out of the gate to support half a million users, that was going to be financially difficult [at the pre-Node memory footprint size].”

The other reason, Mayo said, was all about cryptography. “We had to pioneer a bunch of crypto in JavaScript… it was advantageous to be able to use the same language on the server side as we as the client side.”

Mayo, who was formerly the CTO of Node sponsor Joyent, did express frustration over the fear, uncertainty, and doubt about Node in the enterprise crowd. “Stop saying that Node is a nascent technology or that it’s immature,” he told the Node Summit audience. “It’s at a point where it’s stable.

“That being said, we have had some challenges,” he concluded, noting that the transition from v0.4 to v0.6, which presented some pretty significant changes, was a battle for Mozilla.

Although Mayo said “the invisible state of the debug” was disconcerting (“It’s almost impossible to know what your Node program is doing at all times, which is scary”), he finished by saying that for the Mozilla team, “It’s super empowering for the whole team” to have everything in a single repository of JavaScript, no dependencies or other languages required.

Node at iTV

i.TV is a small startup with a big userbase. Its TV guide app is the most-downloaded in its class, and it also powers AOL TV. The company’s platform is all Node-powered.

“We needed massive scale, and for engineers work on both the client side and the server side,” said CTO Sean Hess from the summit stage today.

One thing Hess noted that we’ve heard from a lot of companies that make a whole-hog switch to Node is that the technology doesn’t come with all the tools you’d need right out of the box.

“There isn’t yet a set of best practices for application code organization in Node,” Hess said. “It’s not baked in like with Rails. We had to invent all this tooling ourselves.”

But Hess said that he and his team didn’t mind the extra work. During the “exploration” phase of coding, as he called it, they got to experiment and test new ideas without bothering with organization too much.

“You do end up with a robust code base, and it happens at a good time… at a time when maintenance isn’t important yet,” Hess concluded.

LinkedIn and Node

Another large company using Node.js is LinkedIn. When the professional network launched its gorgeous (and fast) new app, VentureBeat sat down for an exclusive chat with Kirin Prasad, the company’s mobile chief, who said that Node’s performance benefits were undeniable.

“On the server side, our entire mobile software stack is completely built in Node,” said Prasad. “We use a ton of technologies at LinkedIn, but for the mobile server piece, it’s entirely Node-based… Node showed us huge performance gains compared to what we were using before, which was Ruby on Rails.”

When we asked Prasad about his concerns with moving an at-scale application to a somewhat new technology, he admitted that LinkedIn did have some misgivings. “We did an analysis of a number of platforms — Ruby, Node, Java, Scala. We’ll continue to use it and see how it does. That’s how we’ll make our technology choices.

“In our culture, we’re encouraged to try new technologies. No one’s going to shoot you in the head for trying something new.” And at least at large tech companies such as those onstage for this talk, we’re sure that aspect of engineering culture is universal.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

At Node Summit today, Walmart executives talk about why the real-world retail giant has chosen to work with this relatively new, extremely trendy technology.

Any time a big company makes a decision — any business decision — it is balancing two factors: risk and profit. In its presentation, Walmart executives made it clear that the benefit of using Node.js was far greater than the risk — an assertion many other large companies (and providers of Node support systems) have been waiting to hear from a household name like Walmart.

Walmart’s vice president for mobile engineering, Ben Galbraith, and Dion Almaer, Walmart’s vice president for mobile architecture, took the stage to discuss the largest retailer in the world’s decision to use Node in its mobile applications.

In a nutshell, Walmart is able to serve some very sophisticated features to mobile users on the client side using Node. It’s saving mobile shoppers a ton of time by customizing content based on device type and browser capabilities.

“We’ve been fascinated for a long time by end-to-end JavaScript,” said Galbraith, who said his team wanted to create “a website that would be rich and dynamic… on devices that weren’t too powerful.”

Now, on Walmart’s re-engineered Node-powered mobile app, all the front-end code gets executed on the back end.

“We’re really excited to have a viable back end for that,” he continued. “That’s why Node really excited us, and at Walmart, we’re doing a lot with that kind of architecture right now.”

“We rely on services all over the world,” Almaer continued “We do not control all of those services. Node allows us to front all these services… and scale up very nicely. It’s perfect for what we’re doing in mobile.”

And of course, large-scale Node projects come in handy when you’re recruiting, Galbraith pointed out, since curious hacker-types are eager to work with the latest technologies. However, Almaer warns that many applicants with JavaScript knowledge will also claim Node expertise — and those two disciplines, while related, are hardly equivalent.

While the mobile team did consider using HTML5 for Walmart’s mobile apps, they found it wanting. “We haven’t seen people create what we want for retail in an HTML5 app,” said Galbraith. “For us, hybrid is more interesting in something like what the LinkedIn app has done… it’s the same UI across all platforms, but it has a native experience.”

(Galbraith is referencing LinkedIn’s Node-powered mobile app, which skillfully blends native-running shells with web-based pages and content.)

As previously noted, Node is a relative newcomer — especially to the enterprise, where legacy systems still rule the roost. While Node.js, an open-source technology, recently became the most popular repository on Github, its adoption has been understandably slower in larger companies.

Joyent, the foremost sponsor of Node programming and a provider of Node support for the enterprise, has good reason to promote the technology’s stability and worth to large businesses. In a recent conversation with VentureBeat, Joyent engineering VP Bryan Cantrill said, “Node.js is not simply a new programming environment or the latest shiny object, but rather a profound shift in server-side programming towards event-oriented systems…

“We believe that Node.js is a programming mega-event on the scale of Java or Ruby on Rails. [It is] not merely a new way of expressing existing ideas, but rather a new way of thinking about how software systems should be built.”

Even Node’s core contributors are beginning to say that the technology, though still new and hype-driven, is ready for the big-time — and if Walmart’s mobile app isn’t the big time, we don’t know what is.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

But is Node just as good a fit for web agencies and developers that build dozens, scores, or even hundreds of sites a year?

Making the switch away from tried-and-tested platforms such as Ruby, PHP, Python or .NET for a fresh technology barely out of its infancy, especially when it’s not your product and when you’re working for global brands that simply can’t fail, is a risky proposition.

So why would you want to use Node.js? As a high-volume web agency, here are the reasons we chose to go with Node and the tips and tricks we learned along the way.

Why we chose Node.js

» It’s JavaScript!

Every developer also knows at least some JavaScript. Introducing Node.js, then, is relatively easy.

Everyone in a given web shop knows the basics and just has to learn about the event loop, callbacks and to how to use async flow control.

At our own agency, as people got to know Node, we actually saw that our browser-side JavaScript code improved in quality and structure.

» Code re-use at every level: browser, back end & database

JavaScript is the language of the browser, but JavaScript also powers many of the new NoSQL databases. We tried a couple of them for building content management system and quick fell in love with MongoDB.

MongoDB uses JavaScript for querying data, which means at the very worst that we can copy and paste code and use it in different layers of the system. What might be written as a parser for the browser might be used to format a report executed on the database.

Taking this one step further, we are standardising the include mechanism to actually reuse code and modules across the layers. This means all layers can include the same file, massively reducing the maintenance needed of code and cutting down the time required to write tests.

» Strong, responsive and enthusiastic community

IRC, meetups, bloggers, Twitter and Github are all alive with the chatter and support of Node.js. But not only are they alive; there is an excitement which you don’t normally see on this scale.

So for our developers and many others, this is an invaluable resource when bugs, issues and obstacles do occur.

» Large productivity gains in HTML & CSS using Jade & Stylus

HTML and CSS guys love working on Node because using Node means we’ll be using Jade and Stylus by TJ Holowaychuck. We loved HAML and SASS before Node.js, and now we can’t imagine using anything  other than Jade and Stylus.

» Performance and scalability

We have found that Node.js scales really well. The non-blocking event loop allows for a phenomenal amount of traffic compared to our old, highly-optimized PHP stack running through Apache.

On our first project for a national newspaper, we used a front-end nginx proxy for load balancing to the various node instances and were ready to add extra instances during the peaks caused by TV and national newspaper advertising. The peaks came but the load on the first instance stayed low.

The single Node.js instance hardly broke a sweat, despite seeing one of the highest requests per seconds we’d ever seen.

With PHP and PostgreSQL we could scale up, but it felt really hard and gave us many sleepless nights. Using Node.js with a MongoDB backend scaling up is quick and easy; but because Node can handle more traffic, you don’t need to as quickly.

» Wealth of hosting options: No.de, Joyent’s SmartMachine, Heroku, Nodejitsu

We host our production sites on our own private cloud, but for smaller companies there are many cost effective and easy to setup hosting providers. We’ve got a couple of new Node.js projects in development and will be deploying them on Joyent’s SmartMachines.

» Make your developers famous

I always try to ensure our developers work on open-source projects in contracted hours as much as possible. Encouraging them to start projects that benefit the community as well as the business.

When building projects for our clients, we look for modules that have common functionality which could be packaged up and made into open source projects:

For example, Gzippo is connect middle-ware developed by one of our staff to perform gzip compression of static assets.

We like to manage compression and expiry times of static assets in our Node.js layer because it gives us the freedom to either serve directly from Node or to stick a caching proxy in front.

This way it is served from the caching proxy for all other requests and keeps all the configuration in the Node app, meaning you only need node.js on your development machine to work on projects and do QA using Pagespeed or ySlow.

» Developer happiness

There is something intoxicating about coding JavaScript on the server side; throw in the event-loop and it’s heaven for developers. They just can’t get enough of it!

Maybe it’s because we’ve been coding PHP for such a long time, but Node.js has really inspired our developers. If you were to ask any one of them, “How do you find coding in Node.js?”, you can bet your bottom dollar you’d hear “I love it!” right back.

A sample Node development stack

This is a snapshot of our ever-evolving development stack. There are a couple of staples, but for the most part if we find something better we can just switch it out.

• Node.js

0.4.12 and 0.6.6

• Binary management: n

Point releases often break backwards compatibility. We manage our version using the excellent tool n, also by TJ Holowaychuk.

• Flow control: Async.js

Anyone wandering into the world of Node.js quickly make a choice how they are going to handle flow control. There are a number of methods out there. We’ve stuck with one of the most popular Async.js and depend on it in nearly all modules.

• HTTP, routing and view rendering: Express.js & Connect

The de facto standard Node.js web application framework is the Sinatra inspired Express.js which builds on top of the Connect middle-ware framework by Sencha Labs.

• Presentation: Jade & Stylus

We use Jade as our template engine in the view layer to generate the HTML, and we use Stylus for creating CSS. If you’ve not checked them out then you should, they are a compelling reason for using Node.js. Here is an example of the sort of thing that our designer are doing with Stylus.

• Homebrewed Node modules: Serby on Github
• We’ve built a number of Node modules which we reuse from project to project. Validation, data mapping, et cetera — Basic utility stuff that epitomizes our style of development.
• Logging: Winston

We use Winston writing to files and also pushing log data to the excellent Loggly cloud logging service, which consolidates the logs from each of our node.js instances.

• Testing: Mocha

There are a lot of testing frameworks for Node.js. Knowing which to chose it hard. We looked at a few and made the decision to go with something very simple, in this case Expresso and Should.js. New projects are now using Mocha, the successor to Expresso.

Conclusion

We are on our fifth large project with Node.js (for us, “large” is around 150 worker-days) and are continuing to support the previous projects whilst developing a handful of small and medium-size projects in between.

Less than a year has passed since we adopted Node.js, but the project stats are already looking really good. Initially, the projects we undertook did take longer as our developers learned the intricacies of Node and as we found our feet with the hosting, editors and tools needed to develop and deploy a large scale applications. However, our last project in node was actually under budget, something that rarely occurs at Clock.

Once you get used to event-based async programming, settle on a set of standard development patterns and an architectural style. You quickly start to reap the benefits of working solely in JavaScript. This makes Node.js not only fun but extremely effective to program in.

Paul Serby is CTO of Clock, a UK web agency, where he directs technology choices, architects software, manages large development projects, writes code, makes tea and preaches the virtues of good software design. Clock developed Sun Perks, one of Britian’s largest consumer facing Node.js implementations for News International. Followed shortly by another ground breaking service, the Eat Out Dining Card for The Times. Both leveraging Node.js and a whole host of young and exciting supplementary technology.<

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Hanging out with Paul Querna, a longtime Node.js core contributor and Rackspace’s systems architect, is more fun than a basket of kittens.

In this video interview, he and I chat about how far Node has come in a relatively short period of time. In fact, Node recently became the most popular code repository on GitHub, eclipsing Ruby on Rails in its number of watchers.

We also discuss whether the “OMG Node is the next Ruby!!!” hype has any merit.

Check out the clip above, and stay tuned to VentureBeat for ongoing coverage of the fabulous apps and interesting communities around Node.js.

Check out DevBeat, VentureBeat’s brand new channel specifically for developers. The channel will break relevant news and provide insightful commentary aimed to assist developers. DevBeat is sponsored by the Intel AppUp developer program.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

With 11,460 watchers as of this writing, the Node repo now has more attention than Rails, which has 11,274 watchers.

For all you who’ve been trumpeting that Node would become “the new Rails,” your rantings have just become a wee bit more justifiable.

While Node is still a couple years away from the mass adoption and enterprise acceptance that slightly older technologies have seen in recent years, the fact that its popularity is rapidly growing is now obvious and indisputable.

Bootstrap, Twitter’s open-sourced front-end tool suite; jQuery, the JavaScript library; and Boilerplate, an HTML5 template, round out the top five most-watched Github repos.

Currently, Github lists 239 contributors to the Node.js core. There have been 232 clones in the past four weeks alone, and the Node repo has had 851,456 pageviews over the past three months.

The Node repo has been around since early 2009; Github cites February 15 as the date of Dahl’s first commits. The development of Node is sponsored by Joyent, the company that employs Dahl and a few other Node core contributors, as well as offering Node-related support to enterprise-level companies that want to adopt Node.

“Node’s popularity on Github demonstrates that the world sees what Joyent has always believed: That Node.js is not simply a new programming environment or the latest shiny object, but rather a profound shift in server-side programming towards event-oriented systems,” said Bryan Cantrill, Joyent’s VP of engineering, in a conversation with Venturebeat today.

“We believe that Node.js is a programming mega-event on the scale of Java or Ruby on Rails. [It is] not merely a new way of expressing existing ideas, but rather a new way of thinking about how software systems should be built.”

In addition to garnering its fair share of watchers, the Node core also saw a surge of commits recently. Since the summer, both the number of commits and contributors have picked up significantly:

Ryan Dahl, Node’s creator, still remains the most consistent and active contributor to the Node core.

If you’re one of the estimated five developers who hasn’t dipped her or his toes into the Node-infested waters, check out How to Node, a tutorial blog on getting started with Node.js. You can also check out the text from Up and Running With Node, an upcoming O’Reilly book on the topic by former Joyent employee Tom Hughes-Croucher.

Check out DevBeat, VentureBeat’s brand new channel specifically for developers. The channel will break relevant news and provide insightful commentary aimed to assist developers. DevBeat is sponsored by the Intel AppUp developer program.

July 9-10, 2013
San Francisco, CA

Early Bird Tickets on Sale

Facebook is finally launching its iPad application and will be doing so at Apple’s October 4th event, rumored to be the release of the iPhone 5.

According to Mashable‘s sources, the social network may also introduce its latest iPhone app, potentially revamped in HTML5, at the same event.

The app has been long-awaited. In July, iPad-wielding Facebookers were given a taste of what may come when screenshots of the app were leaked. The app has been in development for over a year and just this morning Jeff Verkoeyen, the former iPad app lead engineer, quit out of frustration.

Verkoeyen said on his blog that the app was “feature complete,” or the step just prior to release for testing, since May. His frustration stemmed, however, from Facebook’s decision to push the release date back on more than one occasion. He has since removed the information about the app from his post, according to Business Insider.

The push back may have stemmed from Apple and Facebook’s shaky relationship, potentially due to a rumored Facebook product code-named “Project Spartan.” The product is supposedly an HTML5 web app aimed at allowing Facebook to circumvent Apple’s app store. But it seems that with all the labor put into this iPad app-baby, it will actually be born. The mobile and social giants may even partner on “Project Spartan,” according to Mashable’s sources, who also note the “Project Spartan” moniker is not used internally.

Facebook may also release a new iPhone app built in HTML5 at the event. LinkedIn recently redesigned its own iPhone app using HTML5 and coding language Node.js. The new app was very well received upon release.

We have reached out to Facebook and Apple for comment and will update upon hearing back.

So runs a wry joke we recently read about Node.js, the somewhat suddenly popular server-side programming technology that’s been all the rage among developers in our acquaintance.

If you’re ready to join the cargo cult too, initiation is just around the corner.

Node Summit is coming up January 24 and 25 in San Francisco, so mark your calendars, book your plane tickets and train your eyes to the Bay Area sky in search of the Node-shaped beacon.

We got in touch with Joyent, the company that sponsors the development of Node.js. While they said the summit should be valuable for developers and investors, they also highly recommend that businesses sign up to attend, particularly companies planning large-scale or data-intensive real-time web apps or companies that have already done so and want to show their wares.

“This would include telcos, mobile operators and device makers, PaaS providers, Internet companies and enterprises with big data challenges,” said a Joyent spokesperson.

Sessions at the summit will cover “a range of areas where Node.js is relevant, including PaaS, Large Scale Web, Mobile and one or two others.

“We have invites out to industry experts and executives who are working on future computing challenges, who can talk about the need for technology that addresses these challenges and who can show why this is important for the target audience,” said the rep.

So far, Node-focused meetups and hackathons have been zeroed in on the technology itself. So the Node Summit team wanted to create a space to zero in on the business benefits of Node.js, including the efficiencies that companies are already seeing and hypothetical or theoretical benefits that haven’t yet been implemented.

“The Node.js project has evolved to the point that we are seeing large companies like LinkedIn start to deploy major applications using Node,” said our Joyent spokesperson, “and we are seeing significant interest as a result of this. We at Joyent were talking about holding such an event when we met up with Charles Beeler and Andy Jenks, and we decided to join forces.”

The summit is being produced by Joyent, El Dorado Ventures’ Charles Beeler and EMC Ventures’ Andrew Jenks. Both of the venture firms are also making financial contributions to the event.

Tickets should be available within the next couple months. The summit doesn’t yet have a website online, so interested parties should follow the above-linked Twitter account for more information.

Relevant vendors might be present, and the organizers are also planning to have a day of the summit “dedicated to a startup showcase (think LaunchPad)… about 30 startups leveraging Node.js in a significant way. These companies will each have a space to demo their stuff and meet with investors, and some will be invited to present on stage, as well.”

We’ll definitely be at the summit to report on Node news, and we’re particularly excited about the startup showcase. Stay tuned for more information as it becomes available.

Check out DevBeat, VentureBeat’s brand new channel specifically for developers. The channel will break relevant news and provide insightful commentary aimed to assist developers. DevBeat is sponsored by the Intel AppUp developer program.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

Our written interview with LinkedIn’s mobile development chief did so well that we thought we’d record a video interview with a true Node expert: Tom Hughes-Croucher, a Joyent employee who’s writing an upcoming O’Reilly book on getting started with Node.

Joyent employs several Node-focused employees, including Node.js creator Ryan Dahl. The company, said Hughes-Croucher, is sponsoring the development of this open-source technology, and it’s providing enterprise-level support for the companies that want to integrate it with a robust safety net.

In the interview, we talk about Node in the enterprise, Node’s performance benefits, where Node falls flat and a great deal more. The one thing we didn’t get time to talk about is Hughes-Croucher’s book, so be sure to pre-order your copy. You can also peruse preview chapters online free of charge.

On another note, you may notice that we’ve been doing a bit more video posting lately. Being in the heart of the Bay Area, we’ve got access to tons of great developers, web designers, UX folks, entrepreneurs, investors and more; and we’re doing our best to wrangle them into the VentureBeat studio on a regular basis. What kinds of people should we be interviewing next? Who would you most like to hear from? Give us some suggestions in the comments, and thanks for watching.

Check out DevBeat, VentureBeat’s brand new channel specifically for developers. The channel will break relevant news and provide insightful commentary aimed to assist developers. DevBeat is sponsored by the Intel AppUp developer program.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---

The app is two to 10 times faster on the client side than its predecessor, and on the server side, it’s using a fraction of the resources, thanks to a switch from Ruby on Rails to Node.js, a server-side JavaScript development technology that’s barely a year old but already rapidly gaining traction.

Also, the development time was unusually fast.

“It was fast by all standards,”  LinkedIn’s mobile development lead Kiran Prasad told VentureBeat. “I’ve worked at startups and big companies like Yahoo, and yeah, it was fast.”

Part of the development speed was due to the fact that the team knew ahead of time exactly what needed to be built. “We really, soundly knew what we wanted to do at the beginning,” said Prasad. “To build a product when you have two years’ worth of data on user behavior makes it a lot faster.”

Using HTML5 for the mobile web & native apps

One part of the development speed was due to the way the team used HTML5 in the web app and reused a bunch of the same code in the native applications for iOS and Android.

“There’s this battle between HTML5 web apps and native apps. But we’ve interspersed HTML5 in the native app, where web-based content excels. The things that are hard to do in HTML5 are a scrolling infinite list, so we went native with that.”

The reuse of HTML5 code across all three applications (mobile web, iOS and Android) will speed up iterations of the app, too. “We can grow our feature set more quickly without having to do a whole new client build,” Prasad said.

In addition to HTML5, the team also used a handful of lesser-known free and open-source tools, such as Backbone and Underscore, in developing the apps.

“The way our mobile web app works is it’s all rendered on the browser side. The value of that is you send less data back and forth, so it’s much faster.”

Also, the app is insanely lightweight. “If you take our entire app and you combine all the framework pieces and zip it, it’s under 50K,” said Prasad.

“We don’t use the browser’s caching system, so once you’ve brought the app down, unless we’ve changed something in the app, the most you have to download is 1K. So especially for international users, it’ really important to not make a bunch of extra traffic.”

To speed up performance on the mobile web app, Prasad told us, “Connections are all stored locally, also for speed and so if you’re offline, you can still access them.”

How Node rules the roost — unless you’re crunching data

We quizzed Prasad about his team’s use of Node.js, the Joyent-sponsored, server-side Javascript technology that’s been all the rage among many startup-centric developers we know.

“On the server side, our entire mobile software stack is completely built in Node,” said Prasad. “We use a ton of technologies at LinkedIn, but for the mobile server piece, it’s entirely Node-based.

“One reason was scale. The second is, if you look at Node, the thing it’s best at doing is talking to other services. The mobile app has to talk to our platform API and database. We’re not doing massive data analytics. Node showed us huge performance gains compared to what we were using before, which was Ruby on Rails.”

The improvements the team saw were staggering. They went from running 15 servers with 15 instances (virtual servers) on each physical machine, to just four instances that can handle double the traffic. The capacity estimate is based on load testing the team has done.

Still, Prasad admits Node isn’t going to be the best tool for every job. “We have a recommendation engine that does a ton of data crunching; Node isn’t going to be the best for that,” he said.

But with a technology so relatively new (Node didn’t truly take off until mid-2010), is LinkedIn concerned about bring a somewhat untested technology to an already at-scale app?

“There’s definitely that concern,” said Prasad, who himself has been using Node since January 2010, before he worked at LinkedIn.

“We did an analysis of a number of platforms — Ruby, Node, Java, Scala. We’ll continue to use it and see how it does. That’s how we’ll make our technology choices. In our culture, we’re encouraged to try new technologies. No one’s going to shoot you in the head for trying something new.”

On the other hand, getting to play with a trendy new technology is like candy for most developers, and Prasad said the opportunity was definitely a hiring incentive. LinkedIn brought some V8 engineers on board, and the company’s Ruby on Rails developers converted

“If you look at the community of Node devs,” said Prasad, “there are a lot of transplants from the Rails world.”

To learn more about the bottlenecks and tech issues the team encountered while working with HTML5 and Node, stay tuned to the LinkedIn engineering blog for a series of technical posts.

Check out DevBeat, VentureBeat’s brand new channel specifically for developers. The channel will break relevant news and provide insightful commentary aimed to assist developers. DevBeat is sponsored by the Intel AppUp developer program.

---

Big Data and Predictive/Real-time Analytics startups: Are you looking to jumpstart development & accelerate market traction? Sign up for the SAP Startup Focus program to receive technology, support, resources and community to help you develop new applications on SAP HANA, a cutting edge database platform. Get started here, and enter promo code “VB2013″ on the form.

---