HTML5 Vs Native? You don't have to choose

by paul, on 08.28.2012

Facebook has just launched a fantastic new iOS app, a huge upgrade in performance and user experience from their previous application. This has re-sparked the debate over native vs portable mobile apps. I think that the reality is more nuanced, and talking about html5 vs. a native app presents a false dichotomy.

Native apps are applications coded using the language, developer tools, and APIs provided by the mobile device's SDK, or software development toolkit. If you want to have a native app for both android and iOS, you would by definition have to write two different pieces of software: Android's SDK is for the Java programming language, whereas iOS is for objective-C. Portable apps, which use html5, css, and javascript, promise a "write once, run anywhere" developer experience. You write your app using standard web technologies, package it up using a framework like senchatouch, and bingo bango bongo, you're in business in the android store as well as the apple app store. A lot has been written on the relative advantages and disadvantages of these approaches, and I will not be re-hashing those arguments here.

The problem with the "native vs portable" debate, is that it implies if you're writing a native app, you won't be using html5. In practice, this doesn't have to be true, and frequently isn't. When I was at GS, my team built GS Research, to showcase equity research to our clients. Equity Research functions quite a lot like a newsroom, and our app is built around a business that publishes timely research, sometimes based around market events, sometimes more general economic forecasting, etc. We wanted our clients to be able to download our app from the app store, and have a first class experience browsing through the research we publish.

When we architected the GS Research app, to allow our clients to read our investment research products, we made a couple of important decisions that allowed us quite a lot of flexibility:
Number one, after some debate, we decided we wanted to do a native app. The usability of the portable frameworks we tried like SenchaTouch weren't quite up to speed. Since our app is iPad only, and would have a lot of visibility, we opted to use objective-C. I would note that none of us, including myself, had ever written a line of objective-C before we started on the project. We used books, I even wrote a small metronome app to prepare. Our attitude was that we are good technologists, and can use whatever technology is required to get the job done. Programming languages are not like spoken languages; they usually have a lot of common ground, and are relatively quick to learn, and as programmers, we love to learn new languages.
Number two, we didn't want to rebuild the whole enchilada if we wanted an android client. Most publishing and news apps have a non-trivial server side component, and for our app, we had roughly three times as many developers working on the server side as we did on the client side. I don't want to trivialize client development; but we had to implement services for search, app activation, personalized content, email alerts, etc.
We needed a clean, platform agnostic way to represent our investment research. Guess what we chose? HTML5 for documents, JSON for reference data, and javascript (jQuery) and CSS for styling. The app uses a UIWebView to display research documents, which were semantically marked up and delivered to our app via HTTP.

In general, the decision to use html5 and JSON as a contract between our web services and client application served us very well, and I would readily architect another web application this way. In fact, my colleague Bryan Irace, who was instrumental in the planning, crafting and implementation of virtually everything I've just described has, as far as I know, done just that at his current gig. My current job is pretty far removed from the mobile space, but my experience and feeling is that architecting your app using a native wrapper, but html5 for transient content, is a very sound, flexible approach.

Categories: Technology