Author: Dimitris Michalakos

HTML5 is perceived as a lower quality platform, mainly because of performance. This comes both as a result of survey data, as well as developer interviews. Yet, industry experts claim the problem is lack of tools. So what is the HTML5 really missing, performance or tools?

In April 2013 VisionMobile asked mobile app developers what stops them from using HTML5. 46% answered “Performance issues”, followed by 37% who said “Lack of APIs” (sample size: 1,518 developers).

We spoke to developers about their views on HTML5 performance. Apostolos Papadopoulos, author of 4sqwifi, a highly acclaimed public WiFi password app, noted “Quality and user experience is top priority for us. Therefore, we prefer going with a Native API”. It’s a common practice for developers to go native for better performance and user experience. But user experience, meaning following the behavioural conventions of the native platform, is a different story and HTML5 can’t help much. Developers can try to imitate but for a truly native UX they have to use Native SDKs; unless we are talking of Firefox OS or the long-awaited Tizen.

Ciprian Borodesku, CEO of Web Crumbz, added “From a business standpoint, there’s a lot of education needed for the acceptance of HTML5. There’s a gap between what we developers can provide and what the clients think we can provide”. The perception of HTML5 being a less capable platform is also common amongst people who commission apps.

Experts point to a tools gap

As part of our How can HTML5 compete with Native? report, VisionMobile conducted 32 interviews with industry experts, from Miško Hevery (author of Angular.js) to Max Firtman (author of “Programming the Mobile Web & jQuery Mobile” published by O’reilly) and Peter-Paul Koch (author of Quirksmode).

It came as a surprise when Robert Shilston, director of FT labs, champion of HTML5 apps, noted that “the biggest issue for HTML5 is the maturity of tools”. He emphasized not performance, but tools, as the key HTML5 gap.

Ran Ben Aharon, head of front-end development of Everything.me, explained it in more colour: “Hearing Mark Zuckerberg 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”.

Even though developers identify performance as the #1 problem of HTML5, a number of experts claim the actual challenge is tools. There’s no contradiction here, performance and tools are related. How can you improve an app, if you can’t measure it? How can you fix a bug, if you can’t replicate it?

HTML5 is like a car without a dashboard

[tweetable]Tools are to HTML5 what a dashboard is to a car[/tweetable]. You can’t run at high speed without knowing how fast the engine runs or you might end up totalling the engine. Likewise, you can’t produce fast HTML5 apps if you don’t have quality debugging and profiling tools.

With HTML5, coding and debugging are two separate processes. There is no self-contained IDE here. Developers code on the editor (e.g. vim or sublime) and debug on the browser, i.e. using Chrome developer tools. But debugging tools are difficult to master and they require a thorough knowledge of the underlying technology, e.g. what is a reflow, how does the garbage collector work, how is a memory leak created.

Louis Stowasser, author of CraftyJS noted “it would be great to have something like YSlow for game developers”. Why pick YSlow and not Chrome developer tools? Well, because the former offers insights on what to fix rather than data requiring interpretation.

Moreover, each browser has its own set of debugging tools. As a result, [tweetable]developers need to become familiar with at least 4 different environments to match the most popular browsers[/tweetable] of the market. And though it’s generally true that these tools look alike, it’s the little bits and pieces that make the difference.

Patrick H. Lauke, former product manager at Opera Software, highlighted the fragmentation of the browser debugging tools by commenting on a W3C public discussion board about our research: “Opera Dragonfly was the first to offer remote debugging and proposed a unified protocol for debugging. Sadly, other browsers showed very little interest and instead went their own separate ways to build something similar but different”. This also touches on the browser politics issue, due to be the subject of another blog post.

Better tools are needed

HTML5, as far as performance is concerned, is adequate for most use cases. And tools like famo.us and Goo Engine provide a testament. The question is no longer *whether* HTML5 can produce quality apps, but *how* easy it is to create quality web apps. What the HTML5 platform desperately needs is easy-to-use debugging and profiling tools.

With the right tools we could see external debugging tools hooking to multiple browsers and even apps able to profile themselves via standard debug APIs.

Web development attracts millions of developers who are new to software engineering because of the learning curve; it’s very easy to get started. The complexity gap between building basic sites and single page web apps (SPAs) is too big of a leap for many to jump over. Improved tool usability is one of the best ways to bridge that gap while also increasing productivity for those already building complex web apps.

What other improvements do you think are needed in HTML5? Download our research and participate in the discussion.