Skip to content
All posts
·5 min read

The Promise of Mobile HTML5

Less than a year ago it seemed like HTML5 was going strong. With Facebook and Linkedin adopting the technology to reach most of the screens on the mobile and…

Less than a year ago it seemed like HTML5 was going strong. With Facebook and Linkedin adopting the technology to reach most of the screens on the mobile and on the desktop.

Linkedin had the better hybrid mobile app (HTML5 + native) and published a series of videos and articles about how they successfully did it with a team of "just" 5 developers.
Admittedly Linkedin app was really nice, but, after learning more about the internals of their app I've realized it wasn't perfect.
For example the way they manage the application cache is not as good as the HTML5 app-cache that just works well out of the box. Using the term "it wasn't documented" is not a good enough excuse, it was working well long before the debute of their app.
Also, their infinit scroll is just a not so infinit swipe, etc'

Anyhow, it appears that linkedin, similar to her bigger sister Facebook, ditched its mobile HTML5 in favor of native.
Linkedin senior director for mobile engineering Kiran Prasad claims are that there is not a good debuger and no performance measuring tool.
Firstly the debuggers are getting there every day (there are many more).
Secondly, profiling in the desktop and mobile Chrome will give you a general idea where memory is going. Profiling hybrid apps in iOS6 is also available.
I don't think that these are really the reasons, they simply needed a stronger platform and HTML5 became too difficult to scale to their needs. That's reasonable, mobile HTML5 is definitely not for everything.

Yet, the promise is still here – use the same code base and the same web development skillset to deploy for: native apps for mobile, browser apps for mobile, cross platform for the desktop (also outside of the browser), and so much more.

So why mobile HTML5 is not there yet? I'll outline some of the main reasons here:

1. It's not realy the same web development skillset
Well it is in a way, for the simple stuff it is still mostly HTML, Javasctipt and CSS. But, even for the simple stuff, things that works just fine on the desktop browser can greatly affet smoothness, battery consumption, memory usage, and eventually crashes, when used in mobile.
Every bit of code needs to be perfected in order to maintain the user experiance. Not even talking about specific glitches in specific versions and OSes.

2. Android – when it comes to HTML5 Android sux big time.
iOS had good HTML5 support from the get go. It reached full maturity from iOS 5 which is currently all that is needed to cover the great majority of devices out there.
Android on the other hand only reached HTML5 maturity with version 4.1 which is less than 25% and going up slowly. The notorious Android fragmentation is affecting HTML5 as well.

3. HTML5 apps doesn't easily scale in terms of features
You needs to be vigilant about every piece of code that is added.
For example, adding just a small feature like an image or a text to every item in a list can greatly hurt performance.

4. HTML5 apps doesn't easily scale in terms of crew
You needs to be vigilant about every piece of code that is added.
In order to deliver the promise of same code base in all mobile devices and in the desktop you firstly need that all of your crew will be highly proficient. Mobile HTML5 apps can easily be ruined.
Secondly if you want that code to be used in the desktop as well, you need a greater level of harmony between members.

5. Product ppl want stuff they see on other apps.
Some of these stuff are very easy to create nativly but are extremly painfull when created in HTML5.
Product ppl needs to better understand the technology that is used.

6. Native is not that hard to do
At the end of the day wrting native apps for iOS and Android is not that difficult, it'll be easier than HTML5 in many cases.
It's way more diffuclt to ruin the smothness in native UI though I see many apps that manage to achive that.
An avarage native developer can easily achive good user experiance.
When writing native you can get a way with poorly written apps. Even if you will make the UI render itself 10 times more than it really needs to, you can still achive good user experiance that will satidfy most users.

7. Peer presure, don't be a chicken
Some idiot with a rooted and very old phone, will install Android 4.0 mod (worse Android OS for HTML5). And than will start to whine that things don't work smothly.
– That's not even a real phone, idiot.
Announcements from facebook and linkedin ditching HTML5 in favor of native lowers the moral of HTML5 supporters and help "classic" developers that are intimidated by stuff like javascript to raise their heads.
What?! Can't you write it in native what are you chicken – nobody ever calls me chicken (btw, this is how we'll be in 2 years)
You will (almost) always have doubts about switching to native.

∞. It's not over, it's barely just begun
Don't be let down by facebook and linkedin moving to native, it's always depends on the type of app, resources and the kind of people involved.
Mobile HTML5 apps are deliverable and in good quality for some time already.
You will gain the benefits mentioned above of same codebase and skillset along with way better deployment model.
Done right, you can deploy new app versions like deploying a website. Without the need for approval, and without sacrificing much user experience.

The bottom line is that mobile HTML5 is here for somewhat long time already, but it's not for everything and definitely not for everyone – yet.

Comments (4)

Imported from the original blog

John JeremiahApr 30, 2013

Nice post. While there have been few large sites that have tried HTML5 only to make a change toward Native, I think those few cases misses longer term potential for HTML5 and mobile apps. Especially when you look at enterprise mobile apps, where the cost of ownership is a key factor to consider when creating apps to increase productivity. The goal is efficient and effective, not perfect. Too often, when teams try to achieve perfect, they just keep refactoring and never ship.
For enterprises, the benefits of an HTML5 / hybrid approach are clear. In fact, we’ve been working on HTML5 hybrid mobile apps for a while, and in fact, we recently made HP Anywhere – an enterprise mobile platform available for enterprise developers to explore how to leverage HTML5 and Javascript in a hybrid platform to build and manage enterprise mobile apps. Feel free to check out the developer zone. http://bit.ly/dev_anywhere, where you can download the free IDE and explore HP Anywhere http://bit.ly/HP-Anywhere.

moodboomMay 8, 2013

It will be nice when HTML5 is rock solid everywhere. It's a great point that the main HTML5 barrier is the ease of native app development. One thing in HTML5's favor is JQuery Mobile, it makes getting started dead easy. But you'll quickly hit limits. For me, it's the inability to continue running my music app (click my name above) in the background - even the stupid lock screen shuts down HTML5/Javascript. Will HTML5 ever be granted the power to fully run in the background if the user decides that's what they want? For me that's the primary blocker to going fully HTML5. Right now I'm leaning heavily towards punting and developing a native Android app. On the other hand, once again, Apple will never approve my music player as a native iOS app as it overlaps with their goals.

guyaMay 8, 2013

moodboom, on the iOS you can play the audio in the background by delegating it to native. Shouldn't be too difficult http://stackoverflow.com/a/...
You can keep all of the UI and logic in HTML and Javascript and just play the audio on the native side.
On the Android everything can run in the background, even Javascript. That's not always the best thing though, but it's possible.

MaksymJun 26, 2013

> On the Android everything can run in the background, even Javascript. That’s not always the best thing though, but it’s possible.

Could you please, add some details on how to run JavaScript on Android in background. I've only succeeded using iframe on 4.2.2, but 4.0 doesn't work. No timers or intervals work.