Is HTML5 about to make a comeback?

The web is losing and apps are winning. At least that’s what the most recent data from Flurry says – 86% of time on mobile devices is spent in an app other than the browser, up from 80% last year. Does that really mean the web is losing? What about apps built with HTML5? Is the implementation technology more important than the distribution mechanism? Why should anyone care? A number of new tools and frameworks are maturing that should make it much easier to build great mobile sites and apps with HTML5. Could they stop the shift from web to native apps, or even reverse it?


Why the web is losing on mobile

Modern web browsers and standards were designed for a desktop computing environment and they built upon a base that was designed for sharing linked documents. Mobile computing environments have capabilities and constraints that desktops don’t. Native mobile app platforms were designed for building highly interactive, animated, apps utilising hardware graphics acceleration. The result is that apps running in a mobile browser are disadvantaged in terms of performance, user experience and access to device functionality versus their native counterparts.

The app is the new browser bookmark. People have favourite services and sources of information or entertainment even though a great deal of substitution is possible in most cases. Providers have to compete on user experience and that creates a bias towards native apps. You want to check the weather every day? You don’t search for a weather forecast every time, or find a favourite weather site and bookmark it, you download a weather app. Need to catch up with your friends on a social network? You don’t open the browser, type a URL or go to a bookmark and wait for the latest updates to download, you get update notifications pushed to you by the native social network app, or when you open the app it has already downloaded the latest content in the background. For frequently accessed apps, the native versions have much less friction, as well as a nicer user experience.

What about hybrid apps?

Delivering a web app in a native wrapper allows it to access device functionality and reduce some regular usage friction. However, it doesn’t fix performance (indeed on iOS it makes it worse), nor make it easier to deliver a great user experience. Another problem with delivering a packaged web app that uses a system WebView is that the functionality of the WebView itself can change with OS updates. Android recently switched to a new Chromium-based WebView and broke or crippled lots of hybrid apps. The flip-side to this problem is that WebViews upgrade slower than browsers; on Android the WebView is currently tied to OS upgrades (which are still lacking from most manufacturers) while the Chrome browser continuously auto-updates. This means it’s a long time before it’s feasible to start using new standards added to the browser specifically to tackle mobile issues. A hybrid app is also still subject to app store reviews and policies. It may be possible to update functionality without an app update in the store but the platform owner still controls what developers can and can’t do.

Another popular complaint about hybrid (and native) apps is the loss of ability to cross-link versus the web. I believe that Facebook’s recent App Links project puts all native apps (including hybrids) about on a par with web apps here. It may be possible to link to any web page but many modern web apps only have a single page. What’s actually needed with a web app rather than a web site is the ability to link to app states. This is only possible if the developer enables it by setting up routing for URLs to app states – native apps can already do this and App Links solves the “what if the app isn’t installed” problem with web fallbacks or store links. If platform providers enhance app interoperability then native (and hybrid) apps could significantly exceed the capabilities of the web here.

Engagement versus ease of access

As discussed above, any content or services you access frequently create less friction by providing native apps. Less friction enables more engagement and a virtuous cycle of greater usage. On the other hand, new or infrequently accessed content and services have extremely high friction if you need to download an app before you can do anything else. Here the web has significant advantages over native apps. The companies who really don’t get this are the ones that have a full screen popup asking you to download their app every time you visit their website on a compatible device! Another way to look at the Flurry stats linked at the top of the article is this: exclude games (which have almost always been native for performance) and social networking (which falls firmly into the frequent access category, plus a lot of the time will be using an in-app browser anyway) and the browser still has more than a third of the remaining mobile usage time. That doesn’t sound quite so bad.

New frameworks fill the gaps

With the threat of being relegated to the “infrequently accessed” category of apps, the web development community has not been sitting around doing nothing. A new framework recently into public beta,, attempts to solve the major performance problem for animated web app UIs. Their current approach is a series of clever hacks involving minimal manipulation of a very flat DOM structure. However their JavaScript APIs will also render to WebGL in future (when it’s sufficiently widely available, ahem, Apple). The approach is promising and the demos are impressive. Currently their homepage (on both my retina iPad Mini and Nexus 4) kinetic scrolls with a stutter that makes my 2006 Symbian device look slick, so there’s a way to go before they’re ready to come out of beta. Note that using JavaScript APIs starts to make building web apps look more like creating a native app.

Another framework close to its 1.0 release is Meteor, a new way to create real-time web apps very rapidly. They fix common issues with the responsiveness of web apps out of the box – having to poll the server for new data and wait for it to update the UI after user interaction. The latter is achieved with a technique called latency compensation (UI is updated with local data immediately, then fixed if the server returns something different). The former is down to having long-running bi-directional connections between client and server rather than a more traditional RESTful API. Meteor actually supports native client apps too but with the ease of creating the web front end it would be unusual for developers not to have both web and native options if they go down that route.

Although there are lots of new and interesting frameworks in development I’ll highlight just one more that’s in a fairly mature beta stage. Ionic is a framework designed specifically for building hybrid apps. It’s built for performance and to provide common UI components and interactions out of the box so it’s easy to make an app with a native feeling user experience. The default styling is very similar to, although deliberately not exactly like, iOS 7. The major disadvantage to this approach is that while it works on recent iOS and Android versions you lose the broader cross-platform and device compatibility. It’s not for building mobile websites or desktop web apps. As such Ionic is building on HTML5 purely as an implementation technology and abandoning the browser. However, as it’s still running in a WebView developers retain the privileged position of being allowed to download new code on iOS.

Native user experience

I listed performance and user experience as two separate issues for a good reason. Despite all the great efforts at resolving performance issues for web apps, native user experience is not just about performance. For some apps it’s natural to take over the full screen and provide an immersive user experience. Games fall into this category, unfortunately they’re also the category of app most in need of full native performance. The majority on non-game apps use some standard platform components and need to follow platform user experience conventions. This makes it easy for users to learn how a new app works; navigation and controls work in the same way as most of their other apps. In this sense when we say “native” user experience we mean aligned with the platform culture and conventions rather than compiled to native binary code. The folks at Ionic are right not to mimic iOS 7 too closely. The more native looking an app’s UI, the more users will expect it to behave exactly like one (and get frustrated when it doesn’t always). A phenomenal amount of effort is required to make an app look and feel just like a native one when it’s not actually using native controls. Even if this can be achieved, the platform will change and the app won’t, making it stand out like a sore thumb until it can be updated (again at significant effort). This is an issue for all cross-platform environments that have their own rendering engine rather than wrapping native controls.

What the technology wants

Marc Andreessen famously said that the eventual application model on mobile will be the web application model, because the technology wants it to work that way. Having every app stored on a remote server and the latest version always updated to the device when it becomes available is a superior model to downloading and periodically updating local apps. This technological advantage applies almost equally to hybrid apps, assuming the native wrapper rarely needs changing. Native apps that automatically update is a step in the right direction but doesn’t aid lean development practices like split testing and continuous deployment. The latter are so valuable in figuring out what to build quickly that there are plenty of entrepreneurs and businesses out there who would build mobile apps with the web model if they were good enough for their customers.

The next wave?

Consumer apps that don’t have highly desirable unique content or features are going to have to compete on user experience for the foreseeable future. For most that will mean native apps. However, building native apps is significantly more expensive than building cross-platform web apps. Not all of the people who pay for apps are going to prioritise user experience. The next generation of software for large enterprises right down to small businesses is going to need a much better user experience than the last but the current state of web technology is probably good enough.

Revenues from consumer mobile software may look quite attractive but the bulk is in Free-to-Play games and is highly concentrated amongst a handful of publishers. The majority of the growth in that market is in Asia. A more interesting opportunity for many developers may be the only slightly smaller but faster growing Software-as-a-Service (SaaS) market for businesses. As mobile devices become increasingly essential in our work lives as well as our personal lives, maybe we’ll see more of that total usage time in business and productivity apps.


So, is HTML5 about to make a comeback? In a way. If the first wave of mobile computing adoption was primarily about consumers, the next wave will see many more businesses getting serious about using mobile devices to enhance productivity and collaboration. I suspect the use of HTML5 in business apps to be much more successful than in the consumer space. Possibly we’ll see a return to the browser but for now the hybrid app looks more likely. General purpose business apps like time and resource tracking or project management will have large enough user bases to justify native client apps, although of course they’ll need web access too. The more specialised the app, the more likely it is to be a hybrid app than a fully native one.


HTML5 performance is fine, what we are missing is tools

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, 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 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.