BT

What’s the Problem with Mobile HTML5?

by Abel Avram on Nov 09, 2013 |

A recent research concludes that contrary to the general belief performance is not the main problem with HTML5 but rather the missing of profiling and debugging tools and the lack of certain APIs.

After surveying over 6,000 developers worldwide, analyzing 30,000+ Android Play apps, reviewing 42 HTML5 frameworks and tools, and interviewing 32 top experts on the subject of mobile HTML5 vs. native, VisionMobile has come to a number of conclusions published in the How can HTML5 compete with Native? research report, the most significant findings being covered in this article. The report distinguishes four main routes to market used for HTML5 applications:

  1. Mobile Browser – web apps or websites tailored for mobile devices and running in a mobile browser
  2. Native Wrapper – web apps packaged in a native wrapper and delivered through an app store
  3. Web-to-native Converter – apps written in JavaScript and compiled to native code
  4. Native JavaScript API – HTML5 apps written for platforms natively supporting it, such as Firefox OS, Windows 8, Chrome OS

The key findings of the report are:

  • 61% of the developers write for the mobile browser
  • 63% of the US Android Play applications cannot be written in HTML5 for the mobile browser because some APIs are not implemented by the browsers yet
  • the 37% of US Android apps that could be implemented in HTML5 would become 58% if the browsers would add support for Power Management and WiFi APIs
  • 39% of the developers create HTML5 apps for the other 3 routes to market beside the mobile browser
  • 49% of the US Android apps could be implemented with native wrappers, 63% with web-to-native converters, and 98% with native JavaScript

The following chart shows what makes HTML5 attractive:

image

What developers complain about HTML5 is shown in the next chart:

image

Many developers consider performance as HTML5’s main problem, but interviewing a number experts in the field the authors of the report consider it as a false target because performance is automatically improving by new generations of hardware, better JavaScript compilers, the option of using Asm.js, etc.. The main culprit in their opinion has to do with politics, more exactly the fact that the major browser vendors are also mobile OS vendors, interested in channeling applications through their respective app stores. Google encourages native Chrome apps, Apple seems to be implementing the latest HTML5 standards but “leaves out performance related APIs, e.g. WebGL.” Also, according to the report, one of the HTML5 myths is that development is easy, but actually development is pretty hard because of missing adequate debugging and profiling tools.

The most used APIs by US Google Play apps are:

image

The current HTML5 APIs standardization status and browser adoption is depicted in the following graphic:

image

The next table indicates the APIs that would make the most difference if implemented for their respective route to market, showing how many more apps could be implemented in HTML5 if that happens:

Route to market

API % of apps
Mobile Browser Power management 13%
Native Wrapper Power management 12%
Web-to-native Converter WiFi 21%
Native JavaScript API Calendar

1.4%

The report concludes with a number of observations and recommendations for the HTML5 space:

  • Browsers should implement more HTML5 APIs starting with Power Management and WiFi. Developers should push browser vendors to implement more APIs.
  • A standardized packaging solution should be developed for native JavaScript apps, allowing such applications to be packaged once and deployed on any supporting platform
  • A device identity API should be developed to alleviate the fears related to cookies and privacy concerns
  • Developers should be better educated regarding the possibilities offered by HTML5, the real advantages and drawbacks
  • A Debug API should be developed to enable the creation of a set of debugging tools

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Not so by Shai Almog

Better profiling tools will not solve any of HTML5's inherent problems. The biggest problem is that it is shipped by the device vendors who don't update the OS with fixes/improvements so better profiling tools might help slightly for one device but not for the 11,800 Android devices in the market.

However, all the profilers in the world won't help.
Reflows are an inherent flaw in HTML which was designed for documents not for apps, sure you can workaround it by positioning everything absolutely but this is tedious, error prone and not realistically doable. Its over abstracted and this just can't be fixed by any magic of a better rendering engine, JIT or hardware.

There is room for all - HTML5+JS; Native; and Cross-Platform Native (Xamarin) by Faisal Waris

All have their tradeoffs. I think we should not expect too much from HTML5+JS; it has reached a plateau. HTML5 + JS will be good for relatively simple mobile web apps; don't expect it to compete with native.

A better cross platform option is Xamarin. Cross-platform code sharing is about 70% (in my experience) and performance is good.

HTML5 by Guest

HTML5 is really a common technology choice for mobile content. But it's not the only alternative. Here is a great overview of the main mobile technologies available for developers www.g3-247.com/2013/12/engaging-new-battles-onl...

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT