Native versus HTML 5

As a developer who primarily writes natively for mobile platforms, I frequently get asked about native code versus HTML 5. Obviously, this happens most when people want to hit multiple platforms. They speak to developers who advise them that they’ll need to hit say at least iOS and Android, and then they’ll respond with something along the lines of “well, I’ve heard HTML5 runs on all devices, so I’ll just do that since it’ll be cheaper and then just work on everything”.

This issue has been reported in the mainstream media yesterday, as Mark Zuckerberg has publicly stated that using HTML5 on mobile devices was ‘the biggest strategic mistake we’ve ever made’, and that ‘it was really painful, we were never able to get the quality we wanted’. If Facebook had asked me 2 years ago when they started developing their mobile app, I couldn’t have more strongly advised against using HTML5. In some sense I can understand why Zuckerberg would make the choice he did though. He wrote Facebook initially using HTML, PHP and Javascript, that’s where he logged all of his coding hours. His experience of coding has all been web-based, and that is what he understands and is comfortable with.

As a developer who understands mobile platforms, it often grates on me when people view HTML5 as a viable solution in that space simply because they hear that it ‘works everywhere’ and flashing lights go off in their head as they suddenly see cost savings. There are a plethora of problems and issues that arise when mobile solutions are attempted with HTML5. Unfortunately, most non-techies, who are making the decisions, simply don’t understand the repercussions.

Note that when I talk about an ‘HTML5 app’ I mean an app that has a native shell that provides a standard web view, and then the majority of the app works inside that web view.

Firstly, HTML5 will always result in a slower and clunkier interface than native. For one, the app has to hit some server online that is hosting the HTML so there is the initial overhead of retrieving this. Whilst this may seem fast for one off operations, let’s say as an example one second, you have to remember that any serious use of your app is going to involve hundreds or thousands of these requests.  Waiting one second once is okay, waiting one second a thousand times is not. Note that in computing terms 1 second may as well be eternity, most native operations will be measured in pico or nano seconds. Once the HTML data has been received from the server, it still has to be decoded, interpreted and then the web browser has to conduct the appropriate work to update the display. All of these tasks are out of your control, you are relying on the browser to do this efficiently. Indeed, all of this assumes the user has a good Internet connection and the servers are working 100% of the time. If either of these aren’t true then an HTML5 app can fail in horrible ways, displaying blank or 404 pages.

Another issue is that an HTML5 app will never be able to make full use of the a mobile device’s capabilities; they are stuck with what HTML supports. Mobile devices are evolving from one month to the next, with better cameras, accelerometers, GPS, NFC… a never-ending multitude of sensors and capabilities, all of which are immediately supported natively.  However, HTML apps can’t access most of these, and if they can then they can only do so when support is eventually added and even then only in very specific and inflexible ways. For example, even though GPS hardware has been around for a long time and is in nearly every mobile device now, with HTML you might be able to get a location from the GPS, but you have to ask for it in a specific way. You can’t get rapid location updates, and you can pretty much forget about retrieving any other interesting information the GPS and location hardware can provide, such as altitude, speed, heading. Even forgetting the hardware and its sensors, HTML 5 apps can’t make full use of the excellent native APIs that most platforms provide. For example, on the iPhone there are APIs for sharing items via email, Twitter and Facebook. Users see these standard sharing items everywhere, and become familiar and efficient with them. These standard widgets are designed by the device manufacturers to be beautiful, and present information clearly in an easily understandable.  Yet HTML 5 apps are unable to use these, and will instead fall back to embedding features like sharing in the web view they operate within, the text will likely be small, and users will be forced to slowly figure out this new method whilst becoming increasingly frustrated as they strain to read the small text.

HTML5 apps also tend to really stick out, in a bad way, because they are unable to conform to the HIG (Human Interface Guidelines) of the device. Nearly all devices come with a set of guidelines about how developers should design and implement apps. These include things like how big buttons should be, how tables should be laid out, how information should be presented using standard widgets, etc.  Again, HTML5 apps can’t access these standard widgets that all other apps can.  They may try to duplicate them, but the duplication never quite looks right, and even if it is a good visual facsimile, when the user interacts with them they will be slow or jerky.  Basically, just as some human-looking robots fall into the uncanny valley and end up making people feel nauseous, these HTML attempts to copy end up doing the same for graphical widgets. Users look at them and expect one thing, and then become annoyed and frustrated when they behave oddly.

A final issue with HTML5 apps is that the primary claim of them working everywhere, across all devices, is just plain lies. Every device and operating system interprets HTML slightly differently.  You just have to try any HTML compliance tester (e.g. http://html5test.com) from multiple browsers to see for yourself how different the same HTML can be from one device or browser to another. The standard mobile browsers provided in Android, iOS and Windows Phone are all wildly different, and you can never be sure that the design you are supplying will always look or work the way you intended.  Add in screen size differences (tablet versus phone) and you end up with so many combinations that you can be certain that your HTML5 won’t be looking and working as you expected on at least some devices.

So, my list of HTML5 app problems are:

  • Always going to be slower than native
  • App may fail if servers go down, or connection is not available
  • Unable to use the full features of the device/OS
  • Unable to conform to the UX/UI guidelines of the platform
  • Actually not as compatible as you may think

In short, if you know for sure that you’ll never want to use any of the unique features and functionality that is currently available on mobile devices or that may come along in the future; don’t mind a slow, ugly, non-standard app; and truly believe that by some unknown magic HTML5 looks the same on all platforms and screen sizes; then sure, maybe HTML5 is a good solution for you.

Seriously though, don’t be fooled by the one claim that HTML5 relies on… that it just ‘works everywhere’.  It doesn’t.  Apps represent your company and your brand, they are a direct channel to customers. HTML is an ugly, slow and hacked together solution; don’t force that on your customers.