Native vs HTML5 – HTML5 wins hands down

It’s hard to believe that the native vs HTML5 debate is still a popular topic. Personally, I knew that HTML5 was superior from the moment that WebViews came into the picture (http://developer.android.com/guide/webapps/webview.html).

To be perfectly fair though, proponents of native apps are not completely wrong – The idea of having an app that you can distribute through an app store is a powerful notion – Even the vast majority of HTML5 supporters will agree that you still need to write some native code if you want to deliver your HTML5 app successfully.

Here are some reasons why HTML5 apps are better:

  1. Continuous deployment: This is by far the single most important point – As the provider of an HTML5 app, you can deploy an update of your app quickly and easily if there are any issues with it (which arise quite often among lean startups). Also, it gives you the freedom to add features to your app without requiring your users to explicitly update it via their app store (which, let’s face it, won’t happen often, if at all).
  2. One code base: Now with IOS, Android, Windows mobile, Blackberry 10, Firefox OS, WebOS and many more mobile operating systems coming in the near future – Who can afford to maintain all these different code repositories?? If you want to avoid this, you’re pretty much stuck to using HTML5-to-native technologies like PhoneGap.
  3. Design advantage: HTML5 gives you more creative design flexibility than native (HTML5 is where the creative talent is) – Again, you need to use HTML5 technologies like PhoneGap to get around this issue.
  4. Speed and user experience: Contrary to what ignorant native purists say – HTML5 apps can be really fast and responsive. Anybody who claims otherwise has obviously never heard of single page apps (http://en.wikipedia.org/wiki/Single-page_application) – Most SPA frameworks (AngularJS, EmberJS, CanJS, …) allow you to setup client-side routing to let users switch between ‘screens’ without ever actually leaving the page. The experience is smooth and seamless. Also, HTML5 allows you to deliver a consistent experience to all users regardless of whether they are accessing your app through their desktop at home or on their mobile phone or tablet. You don’t want to force your users to relearn your app when they switch from desktop to mobile! CSS3 lets you create responsive layouts which look great on all screen sizes without changing the user experience too much.

The only downside to HTML5 is that you can’t directly leverage native features that are specific to mobile devices – Like accelerometers, gyroscopes, etc… That said, there are simple ways to expose these features from a WebView to your HTML5 JavaScript – So your native WebViews should still be pretty lightweight.

What you don’t want to happen is that in a couple of years, if the mobile OS market becomes fragmented, that you’ll end up having to maintain 4 different code bases for the same app.

In summary, I wouldn’t say that native apps are bad – After all, they make great wrappers for your HTML5! You can’t deliver a great Pizza if you don’t have a box to put it in.

Advertisements

16 thoughts on “Native vs HTML5 – HTML5 wins hands down

  1. You have got to be joking…. processing any serious amount of data in JavaScript is slow, tedious, hell. Throw in ridiculous limits imposed by LocalStorage and HTML5 is utterly useless for any serious client-side processing. YUCK.

    • Why would you want to process ‘serious amount of data’ on a mobile device? That kind of heavy data processing should generally be left to the server where the data is secure.

    • I’m working on such an app right now actually and it’s going really well (it’s for a company I work for). We have a single-page app controller that handles the switching of pages with seamless transitions in between – Changing between pages is instant. Message me again in a couple of months (when it’s done) and I’ll send you a link if you’re serious.

      • I had to rewrite a full client to mobile, since the HTML 5 app was really, really slow on mobile. So, for basic app ok, for heavy application with animation, HTML 5, NO! 😛 In future, maybe canvas and div repositioning operations are gpu accelerated on mobile like css already are, then, possibly, HTML 5 could be an alternative. And even so, I really doubt it will ever outstand reuse components performance like native has (You can say for example the infinite lasy loading from facebook feed, its the nearest from it, but the components are not reused, so on limited memory devices like almost any mobile, this is the worst).

        For now, ur argument are good, I wrote them believing so, in the end, the costs from a second app client had to be supported by us, since the application has not enough performance and client didn’t accept it (and I had to agree with it) (And yes, the application was optimized at max (sprites, js optimization, even sound concat)).

      • Did your root app controller destroy each ‘page’ after it faded out from the screen?
        With SPAs, it’s important to remove each page’s view from the DOM after it has faded out from the screen and to make sure all events have been unbound and the ‘page’-level controller is no longer active. You never want to have more than 1 page controller running at a time within the app.

      • I want a real application, I’ve already seen all the demos (actually many of theme since it’s so much better).

      • That’s fair enough, but you said “show me” to fast and responsive.

        It’s an application that hooks into the Facebook api. It doesn’t have every single Facebook replacement but pretty sure it is functional enough to be considered an application. How “real” do you need?

      • real = something that someone built as a product instead of a demo.

        also, that demo scrolling physics are all wrong and sometimes it jumps on an iPhone 5.

  2. …and Steve Jobs’ March of the Fools continues. The contradictions in even this post are staggering — HTML5 is the only cross-compatible option but you need Angular or jQuery to make it work reliably in all browsers, it’s more powerful than native apps but you can’t do what native apps do without something like PhoneGap, it offers greater design flexibility than native (so self-evident that we don’t even need an example), etc. etc.
    Perhaps you should stick to finance; blatant ignorance, public fraud, and open deception are welcome there.

    • I don’t work in finance. But I occasionally enjoy writing about it. The contradictions you pointed out here are figments of your own imagination. I suggested PhoneGap as a way to work around some of the limitations of native apps, not the other way around.

      The main limitation of HTML5 (no direct access to native APIs) was mentioned clearly at the end of the article and the solution I offered for this was to use the WebView to explicitly expose the relevant APIs to the HTML5 app’s JavaScript.

      There is no logical contradiction in this article. Your extreme bias is causing you to distort my arguments.

  3. Pingback: In the News: 2014-05-18 | Klaus' Korner

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s