Is HTML5 really ready to lure us away from native?

POSTED BY Jason Porter on Oct 12, 2011

There has been a lot of buzz lately about HTML5 being the long sought-after alternative to the closed-market model currently making any reasonable mobile presence price-prohibitive for many companies.  After completing some recent work that pushed the envelope of what is possible with HTML5 on mobile devices, we asked ourselves – is HTML5 really ready to lure us all away from native application development.  The unanimous verdict was an overwhelming “eh, kinda”.  Essentially we found that HTML5 definitely has something to offer but it’s not without limitations and pushing those limits will probably cost more time/money than simply going native in the first place.

The unanimous verdict was an overwhelming “eh, kinda”

Before getting too deep into what HTML5’s offers the mobile space, it will be helpful to consider what “mobile” means.  Time spent exacting over an all-encompassing definition of the mobile experience would probably be fruitless and beyond the reach of this entry.  So instead, I will grab the broadest brush I can find and state that the mobile experience is entirely about apps.  It really doesn’t matter if you’re rockin’ HTC or Apple hardware,  Android or iOS software – the core experience comes down to apps.  You think it’s about hardware – have you ever used ANY Android handset?  They’re slow, clunky and look awful…yet they are dominating market share growth.  You think it’s about the OS – have you ever used iOS AND had any inkling of individuality or desire to control the trajectory of your own path through this waking dream called life?  First they want you to pay for even looking at your iPhone wrong and thank them for shutting you out of every decision about how you use it; Apple will tell you what is good and what is bad; this is probably why we have religion I suppose and I digress.  Anyway, we can all agree then that it’s about the apps – good.  So now in regards to apps, I’ll grab the second broadest brush I can find to say that there are basically two types of mobile apps – apps for content consumption and apps for entertainment (read: everything else).

In this area of content-consumption, our experience made it clear that HTML5 has considerable potential will absolutely replace native application development.  The main reason for this is that content consumption apps are, at their base, just fancy layouts to frame text and images (albeit sometimes stylish and fun ala Flipboard too) which, just so happen to be, HTML5’s strongest points.  From the beginning, HTML has essentially been a layout engine meant for displaying content like text and images; every iteration since then, they’ve simply  added shit tons of bonus goodie to make things <blink>fun and pretty</blink>.  

Well, we concur – we found HTML5’s layout paradigm simply delightful on mobile; long live HTML5!   Development was quick, painless and interoperable!  To put what interoperable means in perspective for any non-developers: imagine the deep inner joy and solace you would feel if Obama actually did anything he promised he would; that feeling of euphoria is pretty much on par with what we’re talking about here.  Add to that the fact that the two most popular mobile platforms (Android and iOS) both support the designy-goodness of CSS3 via -webkit and native apps suddenly seem so passé.  I am not even going to waste time expounding on this further; this was probably already axiom to most.

In the realm of entertainment apps however, things get a little less clear and lead to a lot more drinking.  I should clarify that I am using “entertainment apps” as an admittedly large catch-all to include everything from games to those apps you use while on the bus to help tune out the crazy person SCREAMING at the window (no, not out the window, at the window).  These apps are often media-heavy with a fair amount of interactivity and, sadly, run like ass when migrated to HTML5.  What’s interesting however is that we found this terrible performance was less a consequence of what’s possible with HTML5 and more a consequence of vendors explicitly limiting what’s allowed to meet their own ends.

For example, we ran into extreme difficulty when working with audio – I cannot understate that.  We found Android audio support was flaky at best (ala fragmentation) while iOS straight up says “oh hell no” when trying to preload audio (preloading audio as means to support any kind of sound effects for your app).  While dealing with Android’s audio support difficulties can be chalked up to iteration and fragmentation (for what it’s worth, it’s fully supported since Gingerbread), dealing with Apple’s audio difficulties army tank-backed roadblocks bares more attentions.  To be clear, I am saying that Apple explicitly ignored the HTML5 specification for audio tags because supporting audio in the way defined by the rest of the world (ie, W3C) is not the way that Apple thinks it should work.  Apple contends that they want to protect users from unsolicited downloads over cellular networks (probably valid) and supporting audio the way it’s defined in the W3C standard doesn’t work for them.  Regardless of any virtue that decision might hold from a business point-of-view, Apple’s stance is downright terrifying for anyone pulling for HTML5; if vendors decide what is “standard” then of course there is really no standard; this is basically 1998 all over again; remember “This page is best viewed in Netscape”, yeah well, that’s back.

Another difficulty with developing more resource-heavy applications in HTML5 for mobile is simply the current limitations of hardware.  For example, iOS won’t let first-gen ipads/iphones browser’s cache more than 5mb of images per page (I’ve heard it’s 7mb for iphone 4?).  That sounds reasonable…until you try developing anything fun.  For example, when preloading images (just as with audio) Apple goes to great lengths to prevent mere padawan JavaScript from undermining their control – we did find a simple ugly workaround.  Turns out the cache limitation doesn’t apply to CSS backgrounds, so you can do something like this:


Codez son:


But that’s just a case in point because sure, there might be workarounds to some of these limitations but damn if they aren’t ugly.  These workarounds also beg the question – what are we really gaining from HTML5 in this space.  In other words, the drama between HTML5 and native development was supposed to read that native applications offer you raw power and more capabilities (camera, motion, GPS support…ect) in exchange for only supporting select devices while HTML5 is supposed to offer interoperability across all devices.  But if vendors are arbitrarily supporting different aspects of the HTML5 specification, then it’s no longer interoperable and the whole balance changes. Further, accounting for all time we spent finding the workarounds, it might be argued that native apps would have been cheaper.  No joke.  Anyway, I am sure that this will eventually be resolved when as mobile handsets are getting more powerful daily but for now, it’s a pretty crappy situation.

So whatever, in conclusion HTML5 is awesome and iPads are awesome.  But just like the two hottest girls from my high school, sometimes the two just can’t seem to play nice together when vying for the same boy – namely, me.

WRITTEN BY Jason Porter

Add a comment



Apr 10, 2012 at 2:44am

First off, I am sincerely baffled by your choice of photos for this article. Having said that, I like them. Like your writing style too. "Informative madness".

Anyway, what do you mean "content consumption" and "entertainment" are the only two kinds of apps? What about genuine tools? Apps that do shit? I'm looking to build an "app" which lets you upload pics, and knows your location. Can HTML5 handle this?