Is HTML5 Ready for Prime Time vs. Native? (Mobile App Development)

Since I originally posted this in 2011, the landscape has evolved. I still think it’s a question worth asking, but my overall answer has shifted from a qualified yes to a qualified no.

In my last post I compared frameworks for building app-like mobile experiences with Web technologies: Sencha Touch, jQuery Mobile, jQTouch, and Titanium Mobile. For my own app, Pints, I went with Sencha Touch. But in truth there isn’t a clear winner: for a simpler, more page-based app I’d probably go with jQuery Mobile. (David Kaneda wrote a nice comparison of jQTouch and Sencha Touch — both of which he created. Much of what he says about jQTouch applies equally to jQuery Mobile.)

Each of these frameworks can help you toward the same goal: a cross-platform, native-like experience built on Web technologies. The fundamental question is: is that goal realistic? My answer is a qualified yes.

Putting the App in Web App

If you’d rather avoid app stores (and in particular Apple’s opaque submission process), HTML is your only choice. Users will access your app via their mobile browsers, and can add its icon to their home screens.

In the olden days (e.g. last year) this involved significant compromises. Like any website, your app’s UI and data reside on a web server, and must be re-downloaded every launch — a performance problem at best, and an insurmountable obstacle when a user’s connection is weak or nonexistent (e.g. in San Francisco or New York).

HTML5 changes all that. The WebKit-based browsers built into iOS and Android provide multiple ways to keep your app’s UI and/or data offline:

  • HTML5’s offline application cache can store your HTML, CSS, and JavaScript on the device. After the first load (effectively an install), it’ll launch without an Internet connection, just like a native app.
  • The HTML5 localStorage feature lets you store any JavaScript variable you want in a persistent way, so they’re available permanently — like cookies, but easier and more flexible.
  • If localStorage isn’t enough, there’s a full-fledged SQLite database built into WebKit.

Taken together, these HTML5 features eliminate perhaps the biggest functional advantage of a native app. But app stores go beyond functional advantages: they provide exposure, and a way to charge for licenses easily.

App Store Deployment

Thankfully, it’s easy to deploy a Web app inside a native wrapper. The easiest way to do this is via PhoneGap, which also provides access to device functionality not available to the browser alone. It takes the form of a project template for iOS, Android SDK, Blackberry, webOS, Windows Mobile, or Symbian; from there you use the native tools (e.g. Xcode) to compile and run your app. Your HTML, CSS, and JavaScript are included in the app package and run locally (though you could certainly serve them from a Web server as you would with a Web app).

With very little Cocoa knowledge it’s also possible to roll your own wrapper. That’s what I did for Pints/iPhone, not only in the hopes of increasing performance but also to customize its behavior. I’m more than happy to share that wrapper; most developers, though, will find PhoneGap meets their needs.

Thus wrapped, your app is ready to submit to the app store of your choice, just like a native app.

The Down Side

So there’s little a native app can do that an HTML5-based app simply can’t. But “do” doesn’t equal “do well” or “do easily.” Here are the major drawbacks to the Web approach.


Native apps perform better than HTML-based ones. More accurately, it takes more work and expertise to achieve decent performance in a Web app than great performance in a native one. A month ago I was ready to give up on the Web approach altogether: page transitions and list scrolling were embarrassingly slow, and Pints was hanging for 10–15 seconds every time its database changed.

Today Pints performs pretty well. Interact with it long enough and you’ll notice a stutter, but it’s perfectly acceptable. Getting there took time and patience. I needed a better understanding of Sencha Touch and its idiosyncracies: some features simply don’t perform well (yet). I had to develop a clearer picture of mobile WebKit and its nuances. A post by Thomas Fuchs (of Scriptaculous fame) got me started and gave me hope. From there, it was a question of trial and error: determining what impact various techniques had on performance and trading that off against features and visual design. The results were significant.

Thomas advocates avoiding frameworks altogether. It’s worth considering, but a good framework gives you a lot; I’d rather spend some time optimizing than start from scratch building my own page transitions, list controls, fixed-positioned toolbars, etc. That said, there’s currently no mobile-specific equivalent to jQuery or YUI, i.e. a lower-level library that provides common functionality without going overboard on UI elements and other objects. (jQuery Mobile is equivalent to jQuery UI, not jQuery itself.) Such a library would be most welcome. That aside, I have no doubt that framework developers will continue to learn and improve performance, even as browser vendors speed up their engines and device manufacturers accelerate their products.


Web app development tools have come a long way. IDEs like Aptana, Coda, and Espresso are far better than their equivalents a few years ago. And the ability to do real debugging via Firebug or Safari/Chrome’s debugger is frankly game-changing.

That said, these tools are still behind their native counterparts (as well as those for Flash and Silverlight). The gap is closing, but of course each native platform’s vendor has a vested interest in its tools. And truth is, so many of us are so used to Web development anyway that it’s hard to make this feel like a disadvantage. And it’s worth noting that at least on the iPhone, it’s easier to create a custom look for your app via Web tech than native.

The Verdict

So should you build your app using Web technologies? Here’s my advice:

  • If you’re invested in native technologies already and don’t need to expand to new mobile platforms, stick with native.
  • If your app is extremely complex and highly interactive (and especially if you don’t need to customize the look & feel heavily) — or if any performance issue is going to drive you nuts — consider native.
  • In most other situations, at least consider Web.
  • If you’re targeting multiple platforms, or your expertise is largely Web-centric — and if you’re willing to spend some time optimizing — then I certainly recommend Web technologies.

And one final note: this isn’t an either/or decision. Any native app can contain a Web view. If you need native for only part of a cross-platform app, there’s no reason you can’t code other parts of it in HTML.

Originally published at on February 26, 2011.