December 18, 2014

The future is looking good: HTML5 finally getting love from vendors.

In my experience, HTML5 has been dismissed in favour of native apps because it just did not have the same "wow" factor. Even the best written apps often suffer from sluggishness and noticeable performance bottlenecks on mobile, and the experience is inconsistent across platforms and devices.

Putting aside code quality, frameworks, how much jQuery spaghetti is in the code, lets explore other critical factors that affect HTML5 performance and talk about some exciting recent events that are defining the future for HTML5 app development.

Performance bottlenecks

No matter how well we design our HTML5 apps, they still run in the browser, and always will. This means the performance of HTML5 apps heavily relies on the browser engine as well as the target hardware. Benchmarking browser engines is broken down into two parts:

  1. JavaScript performance
    This measures the raw performance of JavaScript operations. From object creation and manipulation to complex canvas computations, this may attribute to why your HTML5 app or game is sluggish.
    SunSpider is a popular tool for measuring JavaScript processing performance.

  2. Renderer performance
    The browser renderer is responsible for DOM and CSS computations; it's the piece that figures out how to render parts of your application in the document tree. More often than not (except maybe in games) your application spends far more time rendering than computing JavaScript, which is why the renderer is a critical part to getting high performance out of your HTML5 apps.
    RoboHornet is a tool that can be used to measure the renderer and JavaScript performance. Paul Irish has (an older yet still very relevant) article about this here. It is still in alpha, so whether it's ready for production testing is up for debate, nevertheless a good tool to get my point across.

I've been paying attention to how these numbers change year after year and how new releases of hardware and software impact these. Here's an example of sunspider results for Apple's iPhone devices:

iPhone 6 - 336ms
iPhone 5s - 414ms
iPhone 5 - 914ms
iPhone 4S - 2270ms
iPhone 4 - 3483ms
iPhone 3GS - 4903ms

Sources:
http://davidbcalhoun.com/2011/ios5-sunspider-iphone-4s-vs-iphone-4-vs-iphone-3gs/
http://www.idownloadblog.com/2014/09/22/iphone-6-performance-benchmarks/

These show rapid advancement in both hardware and software to level the playing field of HTML5 apps vs. native apps. These numbers will continue to decrease, proving my theory that HTML5 will be the defacto standard and it's just a matter of time.

Browser vs. App

Don't get too excited by this data just yet. These results are from benchmarks run inside the browser on their respective platforms. Your Cordova/PhoneGap app may not be using the same browser engine, in fact on most platforms (depending on version) it actually doesn't. Cordova apps use a native app container with a WebView that actually renders your app. Therefore, to get an idea of how your app will run in Cordova, the benchmarks need to be run in the Cordova WebView instead of the browser.

Android

Prior to Android 4.4 KitKat, Cordova/PhoneGap development was an absolute nightmare. The Android webview shipped with the AOSP Android Browser, and not Chrome. Your app maybe snappy and animations are nice and smooth in Chrome, but as soon as you deploy it as a Cordova app you quickly begin to contemplate your career choice. If I were an executive and you showed me your app running in Cordova on Android, I'd send you you know where and likely never give HTML5 a chance again.

With Android 4.4 KitKat, Google shipped a Chromium webview to replace the AOSP browser, which was the first step towards making HTML5 app development "fair" for those targeting Android. This was huge news at the time.

As exciting as these news were, the Chromium webview updates were dependent on the OS, so in time, the webview will fall behind and introduce inconsistencies between the browser/app experience once again.

Google has been making significant renderer optimizations since their switch from webkit to Blink. This is very noticeable when testing between browser and Cordova. Why? Because at the time of writing, Chrome for Android is at version ~38 while the Chromium webview is frozen at version 33 (30 if between 4.4 and 4.4.3).

Not to worry, Google announced that with Android 5.0 Lollipop, the Chromium webview can be updated via Google Play. This means updated independent of the OS and closer in parity with Chrome for Android.

This ushers a whole new era for HTML5 app developers targeting Android and is very exciting for all of us.

iOS

iOS has a similar strategy, where the webview isn't really the same as the browser engine.

Apple has been hiding it's awesome Nitro engine from us PhoneGap/Cordova devs for quiet some time. Nitro is what powers Safari on both desktop and mobile and offers some very cool tricks such as JIT and LLVM, which increase performance by about 35%.

Apple announced that with iOS 8, this browser engine is available as a WKWebView component to iOS developers. This means Cordova can and is in the progress of supporting WKWebView as its webview for devices running iOS 8. Take a look at these ridiculous benchmark results from early tests.

The future

The future is looking good. WebView based apps (Cordova/PhoneGap/etc) are finally getting the love and attention from vendors. Hardware, software, browser engines are only getting better, so if you're contemplating learning HTML5 development, now is a good time to start.