Brace yourselves, because I'm turning the old fuddy-duddy up to max for this post. Alternative linkbait titles for this post are "Why HTML5 mobile apps suck" and "Get off my lawn!"

When I started coding in PHP in 1996, the alternatives were Perl and C. It was generally regarded as "easier but slower" than both of these alternatives^[1]. At the time there was an argument from Perl and C coders that the sacrifices in efficiency weren't worth it for the ease of development: websites needed to render fast, and scale to what was then considered high traffic.

How PHP won

Ease of development turned out to be the killer feature of PHP. Today it is pretty firmly the dominant language of web development -- there are lots of fast-growing competitors, notably Javascript, but the installed base of PHP apps is gigantic. In fact, it's one of the most popular programming languages overall, depending how you measure these things -- only C, Java, and C++ are more popular, and when you consider that basically all non-web programming is taking place in those three, it makes PHP's dominant place in the web sphere even more clear.

Today there appears to be a similar argument emerging about HTML5^[2] compared to Objective-C apps for iPhone or Java for Android^[3]. And there is no question in my mind that HTML is the "easier but slower" option -- writing efficient, performant Objective-C requires knowledge of memory management, alien to programmers coming from web-centric languages (and Java), and the mere task of rendering something to the screen, a first-class operation in HTML, requires piles of boilerplate and usually a specialized IDE to get right in Obj-C.

Why HTML can't compete

Some people are pointing to the earlier victory of PHP and, more broadly, the triumph of web apps over desktop software as proof that HTML is bound to triumph over native languages. But there is a crucial difference between the older PHP vs C contest and the one now ongoing between HTML and Objective-C, and it's the end-user experience. A website written in PHP (or for that matter Python, Perl or any other scripting language) is, once rendered, indistinguishable from one rendered in C. The buttons, rendered client-side, click equally fast, pages scroll at the same speed. Your only performance hit is at render time, and caching can take care of much of the difference, which even 15 years ago when the first battle was being fought was only the matter of a handful of seconds.

That's not true of an HTML application versus an Objective-C application. Try out Maps on the iPhone. It's fast, responsive, a joy to use. Now go to Google Maps in mobile Safari and try it out. Even on the fastest wifi, one of Google's biggest products (which I'm assuming therefore gets lots of engineering attention) is visibly slower to render screens and controls. Buttons don't click as reliably. Scrolling is jerkier. And as soon as you get off wi-fi, the need to load both the app code and the data means the experience degrades faster and much more noticeably. On a weak signal, Maps is merely slow while Mobile Maps becomes literally unusable -- event handlers don't load in time, the JavaScript gets confused, and the app grinds to a halt.

This is a nontrivial difference that does and should affect your choice of development platform. It doesn't matter if you can develop your app faster: if it is a noticeably poorer experience for the user, somebody who spends more time building a better product simply by replicating all your features in Objective-C will eventually steal your users. Simply put, Objective-C makes better apps than HTML can.

...at least, not yet

Right now, a highly-optimized HTML app can out-perform a badly written Obj-C app, but your scope for optimizing an Obj-C app is so much greater that there's ultimately no contest. My friends who are professional iOS developers speak of shaving tens of milliseconds off render time; an HTML developer cannot go any faster than the maximum speed of Webkit, and while it's a triumph of mobile engineering, it's still nowhere close to native UI in rendering speed.

Smart people like Andrew Betts of the FT think optimizing your HTML app makes more business sense than focusing on a multiple platforms: it's more future-proof, it avoids platform fragmentation across iOS/Android/whatever-Microsoft's-mobile-platform-is-called-this-week. Each bit of optimization happens across all platforms, goes the thinking, so it's more bang for your buck. And eventually mobile platforms will catch up... right?

In the PHP vs. C debate, the ultimate decider was Moore's law: computers got faster, and memory got cheaper, faster than apps grew in complexity, and now the performance difference between PHP and C is negligible simply because both numbers are so small -- the majority of rendering time is now client-side, a sea-change that happened so slowly that it took developers years to notice they were spending time optimizing the wrong things.

Place your bets

The question for you as a developer right now is: in the lifetime of my app, is Moore's law going to take care of the performance hit I accept by using HTML? Is the benefit of launching on the big three^[4] platforms simultaneously great enough to justify a less-than-optimal user experience?

If you're, say, the Financial Times, you're not going anywhere. It makes sense to place a long bet on HTML. But if you're a startup, you're probably thinking in terms of months. I will bet that Moore's law is not going to take care of your performance problems inside of the next two years. If in that time a competitor can take 3 months and produce a better user-experience than you could in 4 weeks with HTML, your two-month head start is probably not going to be enough.

Bottom line: if you're a startup looking to exit prior to 2015, you should probably still be writing your apps in objective-C.

P.S. Entirely coincidentally, it seems Facebook agrees with me, and have rewritten their app in objective-C.

[1] Depending how long you've been a coder, it may or may not come as a surprise to you that PHP, now fast and (depending on your framework) lightweight, was once the slowpoke, resource-hog language.

[2] I hate over-used buzzwords like "HTML5", and will hereafter just use "HTML", but take it as read that I mean the combination of HTML, CSS, JavaScript and browser APIs that get rolled into that label.

[3] Unlike iOS and Obj-C, I have little experience using Android and none at all in developing for it. I believe the same arguments generally apply, but don't hold me to that.

[4] No offense intended to BlackBerry developers, but I think it's uncontroversial to assume RIM isn't going to be a force in the mobile space two years from now.