Not Everyone Is Facebook: HTML5 Will Still Thrive

Talk about the quote that was heard 'round the world.

"The biggest mistake we've made as a company is betting on HTML5 over native," said Facebook founder Mark Zuckerberg at the TechCrunch Disrupt conference in San Francisco. He called Facebook's HTML5-driven app "one of the biggest mistakes if not the biggest strategic mistake that we made."

And before you could say W3C, everyone and their brother lined up to shout, "HTML5 sucks! Native mobile apps forever! See? Zuck said so!"

The truth, as always, is a little more nuanced. For starters, Zuckerberg's HTML5-bashing was highly qualified, as a fuller excerpt of his words reveals:

"It's not that HTML5 is bad. I'm actually, long-term, really excited about it. ... We built this internal framework that we called FaceWeb, which was basically this idea that we could take the infrastructure that we built out for pushing code every day, not having to submit to an app store, to build Web code on the Web stack that we have, and that we could translate that into mobile development. We just never were able to get the quality we wanted .... "

What Zuckerberg is talking about here is nothing less than the core problem at the heart of all mobile app development, something his team stubbed its toe on harder than most. There exists a plethora of ways to write mobile apps, all of which come with their own kind of pain.

Anyone who wants to develop a mobile app has three major choices:

1. Go native. If you don't know how to write a platform-native smart phone app, you've got to stop and learn the tools: Objective-C for iOS, Java for Android, C++/C# for Windows Phone (with HTML5 sprinkled on top). Fine if you have a big dev team and tons of money to throw at the problem--as Facebook does--but tougher when there's only 24 hours in a day and only one of you.

2. Go mobile Web. Create your app as an HTML5 page, and either deliver it through the phone's browser or in a client that works as a browser.

This was Facebook's solution. Their team created a platform-native app which was little more than a wrapper for HTML 5 , which they could then inject with content directly. That way, they could concentrate on developing the actual guts of the mobile experience--the HTML5 itself--instead of getting sidetracked with minor revisions on the client wrapper.

It was a great idea, but the end result was about as snappy as an uphill winter molasses race.

3. Go third-party. This is where you use a third-party app-creation framework like Adobe Flash/Adobe AIR or a system like Appcelerator. You have to retool somewhat to use their tools and their workflow, and the results vary depending on what you're trying to accomplish and what framework you picked. But it frees you up from the burden of having to port by hand.

HTML5 is a big lure for app authors, in big part because it's the second incarnation of the promise of Java. You really can write once and run (almost) anywhere, and with far less of the sprawling mess of sidecar libraries and superfluities that made programming in Java such a headache.

Okay, see that "almost" I stuck in there? That's because the capabilities of browsers all vary, and that includes the behavior of wrappers like the one Facebook devised for its own HTML5 deployment, apart from the speed issues. You can expect some functionality to be consistent between mobile browsers, but as soon as you try to do anything really ambitious, you augur headfirst into a wall of unimplemented APIs, inconsistent corner-case behaviors, and JavaScript weirdness.

Facebook has done its own work to help mobile Web apps behave consistently. Earlier this year it released Ringmark, a suite for testing the capabilities of mobile browsers to determine what functionality they can support. This includes mobile-specific features such as touch-driven actions (what happens when the user pinch-zooms?), or device orientation events such as what should happen when the user rotates the phone. This way, developers of a Web app can get an idea of what mobile browsers currently in the market can and cannot do, and they can program accordingly. Or they can realize HTML5 isn't the best way to deliver what they want to build, and go grab a copy of XCode or the Android SDK.

My long-term money, and Facebook's as well, is on HTML5. Not because it's the best technological solution--heck, I can't stand programming in it myself--but because it's the most widely-recognized starting point. It doesn't give the most powerful base to build on, but it provides the lowest barrier to entry, and one of the fastest ways to get something into people's hands.

Now the results just need to be as appealing to end users as they are to programmers.