HTML5 versus native (iOS:Obj-C, Android:Java) mobile development is a hot topic at the moment, with Facebook's ditching of a hybrid HTML5/Obj-C app in favour of an Obj-C-only app the latest blow to land. However, independent observers will already have noted that the battle, as always, is not without it's fair share of FUD.

This FUD-free technical article will side-step the debate, assume that you've chosen to go with HTML5, and ask - what level of real-life performance can you expect if you build an HTML5 app and deploy it across multiple-platforms?

Background

The app was designed with two objectives, to demonstrate the performance of basic user interactions (i.e. scrolling, selection and navigation) and to do this within a justifiable business context (i.e. not a todo list). In addition, to make sure that we didn't miss the 90% of effort that invariably goes into the last 10% of tasks, we added a final objective to finish the app with the same level of polish as any client project.

The rest of this section walks through the business context of the app, skip to the next section if this doesn't interest you.

The Wealth Manager app represents the type of functionality wealth managers and financial advisers would use to manage a client portfolio and sales relationship. Whilst not as complete in functionality as a commercial app would be, it demonstrates how some of the key functions in such an app can be realised.

The entry point for the app is an overview of all the managed clients, with immediate access to fundamental information regarding their portfolio and contact details. The list can be filtered to show only recent client appointments, upcoming appointments or overdue appointments that need to be scheduled. From here, the portfolio of an individual client can be selected for analysis using the tools in the app. Analysis provides sector and regional interactive analytic views, selecting an item in either of the visualisations highlights the corresponding item in the other visualisation.

Implementation

GWT provides structure to the project and the guts of the code, it allowed us to produce a maintainable, well-tested app without bloating the run-time performance. This is achieved by the Java to JavaScript compiler which performs optimisations not normally possible with vanilla JavaScript, such as using type information from the Java code to perform dead-code elimination or inlining property accessor methods. It also follows the general principle of trying to do as much work as possible at compile-time rather than run-time, a good thing when targeting low power mobile devices..

The GWT DOM abstraction and widget library were also used where possible to provide XML-based UI layout. Certain newer browser features e.g. CSS3 transitions for smooth animation aren't currently supported out the box, but this was easily fixed by dropping down to JSNI. Other CSS3 features such as font-face, to include a custom font, and media-queries, to change the layout based on device pixel width, were used to further enhance the app.

One of the big features missing from the current crop of mobile browsers (standalone or natively-wrapped) is overflow:scroll/auto. Currently this will render either as overflow:hidden or as expected but with a vastly inferior bounce-less, marker-less scroll behaviour. iScroll is a polyfill which does it's best to emulate the native behaviour in platform specific ways. We incorporated the library into the project for the client list screen, again utilising JSNI to interface with it.

The final piece of the puzzle is another open source project called PhoneGap/Cordova, best considered as a native shell around the HTML5 app. The project maintains a native app per supported platform, with each being no more than the platform equivalent of a full-screen browser control. By utilising it and the PhoneGap Build service, we were able to set the name, icon, splash screen, orientation, target device-type and app permissions in one config file and have the service automatically return a native app for each target platform. We then further automated this using the phonegap-build-maven-plugin which gave us continous integration of the build and maven managed releases.

Performance

The following video showcases the performance of the app running on a Samsung Galaxy Tab 10.1 (Android 3.1) and an iPad 2 (iOS5).

Conclusion

The app demonstrates two clear conclusions -

  • You can produce a functional, good-looking app in HTML5 that can be deployed to the platform app stores without writing any native code.
  • There are unavoidable performance problems when trying to implement specific UI features on specific versions of specific platforms on specific devices.

You may read that as a general conclusion, that any app will be a compromise if you write it in HTML5, indeed initially that was our conclusion. However, we now believe a better conclusion is to ask; by using HTML5, to what extent would you have to compromise your app running on your user's devices?

Your app has unique requirements that may or may not be well suited to an HTML5 implementation. The only way to find out the best technology for your requirements is to build a cut-down but representative app, and to then test it across the range of devices you expect your users to have.