How can HTML5 compete with Native?

Hi all,

We ‘ve recently completed an important piece of research at Visionmobile,
in collaboration with Telefonica, on “How can HTML5 compete with Native”. I
personally led the project.

My name is Dimitris Michalakos. I am a software developer, proficient in
web technologies. I have worked as a software team lead for Renew, a
network of screens located in the city of London and now I am leading web
research at Visionmobile.

There is a lot of discussion around HTML5 vs. Native, and it’s usually
polarized. But most people express opinion, rather than facts. In our
research we attempt to answer some of the key questions with data.

Before I talk about the results, I ‘d like to explain the  approach to the
research.

   - *30,339 Android apps from Google Play (US) *analyzed in terms of app
   categories and API permissions;
   - *6,000+ mobile developers worldwide* surveyed in April – May 2013 as
   part of VisionMobile’s 5th semi-annual Developer Economics survey;
   - *42 HTML5 tools*, analysed and mapped into categories across
   Architectural frameworks (e.g. Angular.js, Backbone.js, Ember.js),  UI
   frameworks (e.g. Bootstrap, jQuery Mobile), Gaming engines (e.g. Goo
   Engine, ImpactJS), Web wrappers (e.g. Phonegap, Sencha Cmd, Ludei),
   Web-to-native converters (e.g. Appcelerator, Game closure) and Native
   Javascript APIs (e.g. Firefox OS, Tizen, Blackberry Webworks);
   - *32 developers, industry experts and tool vendors* interviewed, from
   Angular.js to FT and Mozilla;

So here’s an overview of what we found. More on the linked
PDF<https://www.dropbox.com/s/51bmutcuqikz03e/Visionmobile-Telefonica-How_Can_HTML5_Compete_with_Native.pdf>
..

Four routes to market

Web developers have four fundamental routes to the mobile market…

   1. *Go direct to mobile browser;*
   *e.g. iOS Safari, Android browser, etc.*
   2. *Use a web wrapper (aka “the hybrid approach”);*
   *e.g. Phonegap, Sencha Cmd, Ludei, etc.*
   3. *Use a web-to-native converter;*
   *e.g. Appcelerator, Game closure*
   4. *Use a Native JavaScript API platform;*
   *e.g. Firefox OS, Tizen, Blackberry webworks, etc.*

Not all routes are the same

How do the four routes compare? Are they all the same? A sample of 2,275
mobile developers from VisionMobile’s Developer Economics Q3 2013 survey,
says *61% of HTML mobile developers go direct to the mobile browser, 27%
use a web wrapper like Phonegap, 7% use a native JavaScript API platform
like Blackberry Webworks and finally 5% use a Web-to-native converter like
Appcelerator*.

But routes also differ in terms of API depth. Among 30,339 Google Play (US)
apps, *37% can be implemented using HTML5 via the Mobile browser, 49% via
Phonegap, 63% via Appcelerator and 98% via Firefox OS*.

Lack of APIs

Lack of APIs is a valid concern. It comes both as a result of survey data,
as well as by comparing Google Play (US) API usage to HTML5. But, are all
APIs equally important to mobile apps? And since resources are limited,
where should W3C focus? In other words, which APIs, if existed, would make
the biggest impact to the developer community?

*Power Management and WiFi APIs, if implemented, would result to an
astonishing 20.83% rise in the number of apps that can be created with
HTML5.*

Slow performance

HTML5 performance, and specifically JavaScript performance, is highly
debated. In July 2013, Drew Crawford, an iPhone developer from Texas
implied that JavaScript performance reached a dead end and is not going to
improve anytime soon, receiving 499 points on HackerNews.

Nevertheless, CPUs for mobile devices do get better. iPhone 5S has twice
the CPU power of iPhone 5 and that is twice the CPU power of iPhone 4S.
Within two years iPhone improved 4x in terms of CPU.

At the same time, JavaScript compilers improve. JIT compilation is 5x
slower than Native and asm.js promises approximately 1.3x slower.

So, if software and hardware are improving, what makes JavaScript slow? The
real problem is browser politics. Besides Opera, all major browser vendors
are mobile OS vendors. Google promotes it’s own Native Chrome Apps. Apple
is keen to implement all latest standards but leaves out performance
related APIs, e.g. WebGL. Therefore, *HTML5 performance is it’s current
phase is more about politics, rather than technology*.

Ease of development

Lack of APIs and slow Performance is at the center of criticism. But when
we spoke to Robert Shilston, Director of FT labs, champion of HTML5 mobile
apps, he argued that “the biggest issue for HTML5 is the maturity of tools”.

Ran Ben Aharon, head of Front End Development of Everything.me supported
the case: “Hearing Mark Zuckenberg denounce HTML5 made me angry at first,
but then I looked at some data and realized that the main reason was not
performance or APIs but the lack of memory management and debugging tools.”

Finally, Louis Stowasser, author of CraftyJS added “it would be great to
have something like yslow (debugging tool) for game developers.”

Once an app has a memory leak, it is like a speeding car with no dashboard.
You never know how fast you go, or when the engine will explode. Developers
need simple, comprehensible tools, like YSlow, that offer insights on what
to fix, rather than cold data.

*So it’s not about performance, it’s about tools and the ability to measure
performance and improve. The absence of instrumentation tools, especially
debugging and memory profiling is profound.*

You can download our full research at the following link.
https://www.dropbox.com/s/51bmutcuqikz03e/Visionmobile-Telefonica-How_Can_HTML5_Compete_with_Native.pdf

Your feedback is most appreciated,

Dimitris Michalakos
Web Technology Lead | VisionMobile :: Knowledge, Passion, Innovation
Tel: +30 693 6526071 | visionmobile.com/blog

Received on Friday, 18 October 2013 09:53:45 UTC