May 12, 2015

HTML5 for Mobile – Will One WebView Ever Rule Them All?

HTML5 is no longer a new technology. But despite having been around a few years, its potential has never been fully realized, especially on mobile platforms. Since its introduction something has always been missing, preventing HTML5 from ever being fully embraced as a serious platform for mobile app development.


First it was the lack of implemented standards – I remember checking with each new browser version release, eagerly hoping for a score above 300. Then came the era of “performance nits”: developers wrestled long lists to get a smooth scroll and did backflips to get transitions that felt “native”. Fast-forward to today (mid-2015): performance is less of an issue but still requires very close attention – one sloppy CSS rule or DOM modification and the veil is lifted.

And JavaScript memory management has always been a sand trap. You might think JavaScript will handle things smoothly with dynamic memory implementation and garbage collection. Not on mobile devices. If you’re developing for devices where resources are limited, the JS GarbageCollector becomes your enemy, sucking performance from your app any time it pleases and leaving you with no control over when it springs to life and blights your seamless animation. And although you can say “it’s not me – it’s GarbageCollector”, no one will listen: you’ve just gotta learn to deal with it. Here are a few tricks JS developers can perform to mitigate this issue:

All in all a bit long and unless you’re a JS developer you may not want to sit through it. Let me just cite the narrator’s definition of JS GarbageCollector: “waste monster which keeps your applications from going too fast … a blind beast filled with hate and rage.” I can only grin and applaud that characterization. So if you are a JS developer watch this video carefully. It contains the best description of JS’s GarbageCollector algorithm I’ve ever come across together with an effective approach for taking control of this “beast”.

Imagine trying to keep memory under control with a few junior JS developers on your team: throw in a few folks with HTML-level coding skills and no clue about memory heaps, stacks and other low level stuff and the beast roars bigger than ever.

And returning for a moment to the era of “performance nits”, speaking from experience I can confidently say that the only way to get 60fps from an HTML5 mobile app is to avoid HTML and CSS entirely, relying instead on a single hardware-accelerated canvas which runs WebGL underneath. Yes, you’ll have to implement the UI yourself but resulting app will be fast. And there are several good libraries which can help.

But this post is not about WebGL libraries since the state of the art puts “performance nits” in the rearview mirror. Instead there’s a new threat building around mobile HTML5 – WebView fragmentation.

WebView for HTML5 is a Common Language Runtime – that means it’s supposed to be “common” on different platforms while allowing us to run Javascript HTML and CSS. That’s the theory. Practice is another matter. Taking a closer look at what’s out there now:

Android 2.2  to Android 2.3.7 – WebKit version 533.1

Android 3.2.1 – WebKit version 534.13

Android 4.0.1 to Android 4.3 – WebKit version 534.30

Android 4.4.x – WebKit version 537.36

Android 5.0.x – WebKit version 537.36, upgradable separately from Android version!

Today, developers can expect Android 5 devices that, despite their common base OS, all run different WebView versions. Compounding the problem is the fact that some Android device vendors are “tweaking” default WebView, leaving developers to sort out “device specific issues”. And unfortunately there are many of these.

Now let’s look at the Android versions market shares:

Screen Shot 2015-05-11 at 8.47.12 PM

As for Apple – with iOS 8 they introduced fast WKWebView instead of regular UIWebView but, as of this writing, about 17% of Apple mobile devices were still running iOS 7.

iOS fragmentation

And that’s just looking at Android and Apple. Matters get even more complicated once you consider platforms like Tizen, Blackberry, Amazon Kindle, and Windows Mobile, which has its very own WebView implementation.

With so many WebViews in the field the reality is that each has specific defects that developers need to be aware of to then apply corresponding workarounds. And as noted here, nobody’s going to fix previous versions of WebView even when bugs are really severe. And if big bugs get glossed over you can imagine how much attention minor malfunctions get…

More than ever before, HTML5 developers have to deal with a bewildering array of issues: Webkit version specific, OS/Platform specific, device specific and in addition to all this – wired memory management. As a lead engineer who’s been working on a big HTML5-based project for about three years I can confidently say that navigating this labyrinth and while building automated test systems to maintain control on product quality absorbs significant time and resources. Time and resources that are comparable to those required to create two native applications…

So welcome to the era of WebView fragmentation. With each new WebView version in the field, added to manufacturer-specific “tweaks”, HTML5 supporters are losing their last and best argument in favor of “hybrid HTML5” vs. native. “Build once run everywhere” is becoming a form of wishful thinking.