HTML5 vs Native

Should businesses bet on a clear winner like one would in an epic winner-takes-all boxing match (*Pacquiao and Mayweather enter stage left*) or should we reserve judgement and make our decisions on a case-by-case basis? Let’s explore some of the trade-offs between the various approaches, and then get back to that burning question.

As part of our recent January 2015 internship program, we decided to run an experiment. The goal was simple: Build a Native-and HTML5 app with the same/similar functionality side by side in order to explore and gain first-hand insight into how they stack up in terms of the effort involved, usability, the simplicity and maintainability of the codebase, etc. Based on specific client requirements, our mobile development to date has always been targeted at specific devices (Native), or has intentionally been cross-platform (HTML5). We wanted some first-hand experience (some proper ‘evidence’ if you will) that could help us make the best possible decisions around which mobile development tools to use under which circumstances. The task was to build a simple application (3-4 screens) that accessed some basic device capabilities (location information and the device camera). At the end we had some time left, so we hooked up a barcode scanner to the camera. We had two different interns each develop the same app using different technologies. The first intern used HTML5 to build an app that we tested on an iOS device, as well as an Android device, while the second intern developed a native android app using Android Studio. Using interns with little or no experience in either of the technologies was a sure way to keep our pre-conceived ideas out of the mix. Having set the stage, the requirements were discussed and laid out for the interns. They had access to a mentor to help with any roadblocks, etc. and to clarify requirements from time to time, but in terms of the actual building of the applications, they were largely left to their own devices. Towards the end of the internship, both interns showed off their handy work to the team, and various pros and cons were discussed and explored by the team.

OK, so what did we find?

Here are some of the elements that warrant discussion.

USABILITY – One has to be honest in that it really is possible to design and achieve excellent usability using HMTL5. I would go as far as saying one can even get close to making it look and feel like a native app. However, achieving device-specific usability, i.e. making the elements behave like other similar elements on the device, is easier in a native app. Though it might be possible to get there using HTML5, you’d need separate code and usability designs for each native platform, thus almost defeating the object of a single code base.

On device-specific usability, our experiment highlighted that users quickly become accustomed to their specific device usability to the point where they expect apps to look and behave in a very specific way. Consider for a moment that even though well known players Facebook and LinkedIn provide functional and reasonably good browsing experiences on smart phones, they both produce applications that provide an experience which is just that little more polished and subtly device-specific.

SINGLE CODEBASE – HTML5 provides some obvious benefits and elements like responsive design can go a long way to help you build a site that can be used on smart phones, tablets and traditional PCs or laptops. We did find however that accessing device capabilities resulted in separate code paths in our HTML5 application. The Android device, for example, allowed us to access a video stream from the camera whereby we could take a snapshot to produce an image. On the iOS device the user would click a button to select a file and could then decide to take a picture or to use an existing picture from his/her library. The HTML5 app (even just to support Android) took longer to build than the native app for Android. This further put in question the idea that using HTML5 is cheaper and results in less code (easier to maintain) than building more than one native application. The reality is that it depends on a couple of things, which include the complexity of the application, the extent to which device capabilities are accessed, as well as the number of native platforms targeted. It is for example entirely possible to write two separate native apps (say iOS and Android), that access numerous device capabilities and to have less code than a single HTML5 app built to cater for both.

IS THERE NO MIDDLE GROUND – At this point in the discussion you’re probably thinking that this certainly makes the case for using tools like Xamarin, PhoneGap, or any one of the slew of new technologies that have sprung up in this space, whereby one can build once and deploy to multiple platforms. While these tools provide a single code base to maintain (a definite benefit), and potentially save time and effort on the build side, they don’t provide benefit on the deployment side, since you’ll still need to deploy to each native platform separately. One other minor consideration, which is true for HTML5 as well, is that native support for new device capabilities will precede such support in tools like these, even if just by a little bit. If for example I’d like to access some function on the new Apple watch, native support would arrive at the same time as the watch, while support for the hybrid tools will likely lag behind. Who knows if we’ll see a whole bunch of new devices and/or device capabilities being released in the near future; the prospect is certainly exciting, and using or accessing these capabilities may well turn into a race.

DEPLOYMENT – Having touched on deployment in the previous point, clearly HTML5 is the winner here. Native apps require specific deployments, and one has to point out that it does become easier the more you go through the process. If you need to deploy on multiple various different platforms, HTML5 could save you a lot of deployment effort.

CONCLUSION – Good usability and design have become critically important to any mobile experience. We now live in a world where users expect it as a standard minimum. When building mobile applications/solutions, we need to make sure we not only meet the user’s need, but also their expectation. So even though we’ve learned a lot through our experiment, we know that we need to keep learning if we want to have any chance of staying ahead of the game.

If you look back at the various discussion points above, you’ll notice that they basically make up a collection of trade-offs (by no means exhaustive) that ultimately answer our initial question. As business owners we can’t (ever) just pick a winner, and we really shouldn’t try to. Every new mobile development project/product needs to be considered within the context of the ultimate requirements, target audience, available budget, usability expectations, etc. to determine what tools and/or technologies are best suited to achieve the desired outcome. This is by no means news to technologists, as evidenced by various blogs and articles. Matthew Mombrea summed it up very nicely in this article where he states ‘New ammo, same answer’.