Search This Blog

Wednesday, August 29, 2012

HTML5 vs Native Apps.. Do you really know which is better?

Every organization struggles with the most effective way to publish their content across the web, tablets, smartphones, etc.    HTML5 has been touted as the "silver bullet" to solve that problem.  Like anything else however, the answer isn't always that easy or obvious.

In some cases, HTML5 can solve the problem, in some cases you have no choice but to go native (native apps that is..  apps written in  the native code base of that particular device).

Below is an outstanding writeup on this subject from our Senior Developer of Mobile Apps, Scott Newman.    Scott is always on top of the latest technologies and has a keen understanding of the details and nuances between them.   Hope you find this helpful.

"HTML5 and Native App Development Comparisons" by Scott Newman

Here's an executive summary of the decisions that need to be made when deciding between HTML5 and native mobile app development. This isn't meant to be an exhaustive study of all the pros and cons; if more information is needed, I will be happy to go into greater depth.


The HTML5 moniker gets thrown around loosely. Technically, it refers to the fifth revision of the HTML standard, but it is commonly used as an umbrella term to describe a combination of HTML, CSS, and Javascript technologies to render modern web content.

Native applications consist of code that is compiled and installed onto a device. Apple iOS applications are commonly coded in Objective-C and compiled using Xcode; Android applications are commonly code in Java and compiled with the Eclipse toolchain. The terms "app" or "apps" usually refer to native, installed applications.

Webapps or web applications consist of code written in web presentation technologies: HTML, CSS, and Javascript. They run in a web browser on the device and do not require the compilation step. On iOS devices, special HTML tags can be used to remove the browser chrome (the address bar, status bar, bookmarks, buttons, etc. that surround the area where the web page is displayed) and status bar, allowing the web page to be displayed in full screen mode and launched from an icon on the springboard. (The Springboard is the iOS "desktop" screen where the icons are displayed) 

HTML5 Apps are native applications that usually consist of a full-screen web browser window with no chrome around it. Inside the web browser, content is rendered using web technologies such as HTML, CSS,  Javascript, SVG, or Canvas. (Usually HTML) Most often, the HTML content resides on the device as part of the application data to prevent the latency of URL calls. 

The HTML5 Panacea

A popular point-of-view in mobile development is that HTML5 solves the "write once, run anywhere" challenge. The idea is that developers can spend a few minutes building a native shell application consisting of a single browser window on multiple devices, then serve a common set of content files to all the target devices. With the proper design, the content will look nearly identical across all devices and you don't have to spend time on device-specific code.

This idea sounds great in theory, but the reality is far from simple. Differences in HTML capabilities, screen size/resolutions, CSS rendering quirks, and HTML rendering engines (such as webkit, gecko, and IE) make achieving a consistent look across devices extremely difficult. It's hard to do on the desktop and it's just as hard on a mobile device.

HTML5 Frameworks

A handful of frameworks exist to make developing HTML5 applications very easy, Cordova (formerly named PhoneGap) is the most popular. Cordova takes care of the native part of the implementation for each device, freeing the developer to spend their time working on the content. You download the code for your target device, open the files, and drop your HTML code into a specific folder. Cordova offers an cloud-based build service that allows you to send your code to their servers where it is compiled into an installable application. 

Frameworks such as Cordova often expose and abstract hardware APIs with Javascript. For example, many devices have accelerometers or gyroscopes but lack a consistent method of reading their values. Cordova takes care of how to "talk" to each device's sensors and adds new method's to Javascript's navigator object, such as navigator.accelerometer.getCurrentAcceleration().  (The browser's navigator object does not have an accelerometer property by default, Cordova adds it) Similar properties exist for camera, compass, contacts, etc. 

HTML5 Development: Speed and Cost

In recent years, iOS and Android developers have experienced very high demand for their skills, driving up the cost and demand for this talent. By comparison, web developers are much more plentiful and commonly offer their services at a lower rate. (and they have more availability) If a native app and HTML5 app take the same number of hours to develop, the development cost for the latter will be lower. If you need to develop for both iOS and Android, the development cost might double when the developer creates different codebases for each platform. 

Native application development, especially custom interfaces and code, are much more difficult and time-consuming to develop as compared to web development. The initial development is often cheaper with HTML5 apps.

Dynamically Updating Applications

If your HTML5 app designed to be able to call Internet URLs for its content, it is possible to update what the end user sees without recoding and recompiling the application. (and then sending the update to the platform's app stores) Some HTML5 applications are able to update their layouts, look-and-feel, and even change functionality by modifying HTML code and FTPing it to an online web server.

The Dark Side of HTML5 Development: Going Beyond the Demo

So far, everything about HTML5 development sounds great: cheaper developers, shorter development cycles, easier updating, and the ability to target multiple platforms. Why wouldn't everyone do this? In minutes, you can have a demo-able prototype that works well enough to convince management that this is a slam-dunk and the rest of the world is crazy for spending big bucks on native app development.

Indeed, if you are targeting a small amount of devices, have a content-heavy application (as opposed to something like a game that requires custom drawing and layouts) and offer a concise amount of easily organized content, HTML5 app development might be a very good solution for your needs. Many real-world applications, however, don't fit nicely into this set of requirements.

Rendering Speed

The first place that HTML5 applications show their limitations is in rendering speed. Rendering is the process of turning the code into something that can be displayed on-screen. 

Native applications are compiled, so much of the process of turning human-readable code into something the CPU understands was done when the app was first developed. Often dynamic content is displayed in compiled applications, but the code is usually designed to efficiently transform this data into on-screen content. Additionally, the screen drawing is optimized and often has a dedicated graphics chip to help complete this task as quickly as possible. (Remember that 30-60 times per second the screen is redrawn, so graphics rendering is one of the most intensive processes that is happening)

HTML5 applications don't have the benefit of pre-compilation*. When the app loads, the HTML content's markup code must be read by the browser's rendering engine and turned into a document object model (DOM) that the browser knows how to draw on the screen. This process of interpretation is very fast, but it can be enough to make an application feel sluggish, especially when the process must be repeated many times. Additionally, this step requires a fair amount of RAM to perform, and mobile devices don't have nearly the amount of memory that desktop machines do.

* The authors of the web rendering engines are constantly working to speed up the process of turning HTML markup and Javascript into byte code, and there are attempts at performing compilation-like steps inside the browser.

Native applications can perform many optimizations to increase the speed and reduce the amount of memory required to render content. HTML5 applications, however, can only be as fast as the underlying web browser, and there are very few tricks beyond optimizing your HTML markup that can be done to speed it up after that.

Native User Interfaces

Another major problem with HTML5 applications (especially cross-platform ones) is the lack of native UI controls. Anything displayed on-screen is either a browser-rendered control, an image, or a CSS-created layout. If you want to present a look-and-feel that is consistent with native applications, you'll have to build these yourself using images and CSS. 

For example, native iOS applications often display a navigation bar with a title and back button to allow a user to navigate through sections of an application. With native development, you get these "for free" with the software development kit (SDK). If you want to use this technique inside of an HTML5 application, however, you will have to create images and CSS that mimic the native controls. 

There are a number of projects that help you do this, and often they are nearly indistinguishable from the native UI. When you want to do this for a cross-platform application, you'll have to write Javascript logic to detect what platform the user is on and which set of UI "widgets" to use - iOS, Android, etc. Choosing to render an iOS-specific checkbox vs an Android checkbox is pretty easy, but some techniques aren't as easily swapped - for example, iOS presents tabs at the bottom of the screen, where Android presents them at the top. If you are going for a native "feel", you'll have a lot of work to do to get it right on all platforms.

Often HTML5 developers work around this problem by not trying to create a UI that looks exactly like the UI that is native to a specific platform, instead providing a generic UI that can be used on multiple target platforms. (the jQuery Mobile project does this very nicely) The downside to this approach is that users will be less familiar with the controls than the consistent ones that are idiomatic to their platform.

Screen Size and Resolution

A benefit of iPhone web application development is that you can count on a screen that is 320x480 pixels*. Android device, however, are not consistent - you will need to account for many screen sizes. This can be extremely challenging when developing pixel-perfect layouts with HTML and CSS. (To be fair: This is also very challenging when developing native apps for Android)

* An iPhone retina screen has 640x960 device pixels, but you still develop HTML and CSS as if there are 320x480 pixels and the webkit rendering engine takes care of mapping the pixels properly, though you will still have to create multiple versions of each image at different resolutions

Access to Device-Specific Hardware and Features

When developing applications that run inside of a browser, you don't have access to everything the device offers. The iOS webkit browser, for example, has no ability to access the user's address book, calendar, or photo library.* These limitations can be overcome by frameworks like Cordova - the authors of the framework have added "hooks" into the device's hardware and given developers a way to access them through Javascript. When a developer calls a Javascript function such as navigator.compass.getCurrentHeading(), the underlying native application (the one showing the web browser) uses its access to the compass to get the heading, then it sends it back through Javascript to the code that wanted the value. 

These hooks are extremely valuable, but it requires the authors of the framework to constantly stay on top of changes and additions to the platform SDKs and add them to their code. If a feature isn't of a high enough priority for the community, you might have to wait for the features to be added (or pay someone to add them) before you can use them in your HTML5 application.

* Browser access to the photo library is being added to iOS6

Stop and Look Where You Ended Up

If you've accounted for the items noted above and created an HTML5 application that looks consistent across many devices and platforms, consider what you've had to do to get here:
Write logic to handle multiple screen sizes and display images and CSS appropriately
Written separate user interfaces and layouts for each platform you are targeting
Wrote multiple navigation schemes that match each platform's user expectations
Wrote logic to show/hide features that are not available on certain devices
Created multiple versions of each image to handle retina displays
Hired a web developer who is familiar with the intricacies of cross-platform mobile development
An argument could be made that you didn't save a lot of time and effort to get this far.

The Facebook Dilemma

Described above is exactly what Facebook has been doing with their mobile applications for the past few years. They have worked extremely hard to provide a consist experience across a massive variety of devices and platforms. At the end of the day, users still complained loudly about the speed and sluggishness of the applications. In 2012, they rewrote their iOS application from scratch to provide a better experience to their users.

Here are some links describing the effort:
A Hybrid Approach

There is a way to save development time when creating native applications, especially ones that deliver a lot of text-heavy content. I call it the hybrid approach:

Write the chrome of your application as a native application. Make your tabs, menus, navigation, tables, etc. using the native controls and layouts of the platform. Make your application "feel" native to the platform it's being used on so that users are familiar with the way it works and operates. Use native performance optimizations to ensure that animations and scrolling feel responsive and fast. On the detail/content screens of your application, render that content using HTML, and make it reflow properly so that it can be displayed at multiple screen sizes and resolutions.

For example, say you have an application that allows a user to browse a library of information about birds. The user will be able to filter, search, and scroll through categories and lists of birds, then they can view the entry about a specific bird with text and photographs. The UI to filter, search, and scroll should be native to the platform - this will ensure it renders quickly, efficiently, and using UI idioms that the users are familiar with from other apps on their device. When it comes time to create the content pages, write them once in HTML and include them in the app on each platform. You'll save a lot of time by writing the 1000 detail pages just once, and you'll spend a few dozen hours writing the chrome/shell of the application for each platform. As long as the text and images reflow properly in each web container, you'll save yourself the hassle of trying to create multiple copies of each page for every platform you are targeting.

Where Does HTML5 Fit?

At this point, it sounds like we've completely written off HTML5, but that isn't true. For the reasons outlined above, HTML5 is a poor choice for many native application development projects. There are a few scenarios where the technology can work very well:
  • You are deploying to a limited platform of devices (non cross-platform apps)
  • Your performance requirements are light
  • You don't need deep access into hardware/sensors/APIs that the web browser can't access
  • You aren't trying to emulate native UI
  • You are developing the early version(s) of your application as prototypes
If you are only deploying to a single platform, such as the iPad, then the cross-platform UI considerations outlined above don't really apply. If your content does not require lots of scrolling and heavy screen drawing, the sluggish performance of HTML rendering won't be as much of an issue. If you are primarily displaying content and media, then the lack of access into the hardware sensors shouldn't be much of a concern. If your UI is custom (and not trying to mimic native UI controls) then the concerns over non-standard UI elements aren't a consideration.

If you are prototyping your applications, HTML can be a much faster tool than native development, and it is much easier to make changes to without recompilation and redeployment. You could also develop the app in HTML to get it into the hands of customers, gather feedback, and see what customers want. If nobody complains about the performance and the app functions well enough to meet users' expectations, then perhaps the extra pain of native development wasn't necessary. As the programmer/author Donald Knuth said: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."


In summary, there is no "right" and "wrong" for HTML5 and native app development. There are pros and cons to each approach and a thorough set of requirements must be analyzed before making a decision. Beware the trap of thinking HTML5 is an "easy win"; there are circumstances where it can be a great alternative to native development and others where you'll end up down a rabbit-hole of target-specific optimizations and hacks.