HTML5 Apps vs Native Development

February 20, 2013

In the previous posts we have covered the cases when HTML5 could work as good solution for mobile. Now it’s time to see when going native might be a better idea. Mainly, we’ll focus on user experience and app performance. Let’s move through different cases step by step.

Fundamental limitation of HTML5 apps is that user interface is constrained to fit the HTML model. HTML5 app will almost always look and feel like a web app, with web-style user interface controls and touch handling.

Look and feel: long lists

We’ve taken a couple of elements to compare. Let’s start with long lists. This was one of the major problems we faced when working on an HTML5-based app.  If the list is very long, it takes almost forever to load and fast scrolling is out of the question.

As an example, we can take long lists in Dell app. If you try scrolling the list too fast, it freezes.

You can try separating lists into different pages like Superbest did (but then users will have to switch between them and wait for the info to load).

In our case, to reach faster scrolling of long lists in HTML5 app we’ve spent over 2 weeks of programming. However, when we switched to native lists the performance speed increased more than twice. You can learn more on how to deal with long lists from the example of LinkedIn app. They share some useful tips on how to deal with infinite lists.

Look and feel: drop-downs and various forms

Next let’s investigate drop-downs, fields, checkboxes – all kinds of forms.

Just try to set this radio button or fill in a form  (it’s quite complicated to position the main bottom menu when we open the keyboard):

The thing is that all the area is a web view, and when we open the keyboard the web view area is just reduced. To overcome this you have to use many tricks or, like we did, create native navigation.

What about native apps?

Now let’s compare them with almost effortless loading of native lists, for instance, in Aribnb. The thing is that to make long HTML5 lists work better you start cutting down images and animations whereas in native lists you have a variety of options which make the design look more vivid, alive, in one word, more native 🙂 Also, in native apps there are all kinds of options you can use for filters and forms:

So, why native?

To sum up, the most popular mobile platforms nowadays – iOS and Android – need applications to be developed in different program languages: Objective-С and Java respectively. Apps developed specifically for each platform provide the following advantages:

Better user experience. If you really care about your user, that’s the main point.  Android and iOS have separate design patterns and UI guidelines. If you follow the concept of “create once-run everywhere” in the HTML5 apps, you get the same layouts for the Android and the iPhone and all other platforms. Usually, users are against such layouts. When they get the iPhone-style layout for their Android app that means that they have to use the app that has the different navigation, different controls from what they are used too.

Better performance. Native code is developed for a specific mobile platform and works in its native environment much faster than HTML (which needs to be separately interpreted by the device).

More opportunities. Native apps allow using all the possibilities of the device: camera, accelerometer, uploading files, GPS etc. without too much effort. It’s possible use HTML5 for some of these functions, however, many features and interactions will require additional development efforts.

Better testing options. Native apps are easier to test with emulator and their bugs are more predictable in general. HTML5 app will require lots of time for testing and tweaking for each platform. Even 24 months of development of the Financial Times app, it took 4 months to fix all the bugs on Android.

Keep in mind:

  • The reason HTML5 is not yet a valid option is simple. It’s only on Working Draft status with the W3C. In other words, it’s still subject to change and therefore should not be used in anything that requires any kind of stability of the standard.
  • Features. If you need audio, notifications, sockets, locations, etc. – then you need native access. You can access those from HTML5 via a wrapper (e.g.PhoneGap), but this a bit defeats the HTML5 promise – cross platform developments.
  • Native look and feel. This can be simulated via HTML, but will never perform the same.
  • Performance. Web applications can only communicate to the operating system through the browser engine – no way to use the hardware accelerators while rendering, the layout for example.
  • Programming in the native APIs offers a significant speed advantage at runtime.
  • Native applications offer security and privacy advantages to users for certain specific applications (e.g., contact details of friends/family).

In our next post we’ll investigate prospects of HTML5 technology in mobile for the nearest future. Stay tuned!