Status Check: What's Going on with HTML5
October 15, 2014
In short: the battle continues between HTML5 and native apps. Why that’s relevant today is a longer discussion.
HTML5 has received significant press since its inception, perhaps because this is the first major update to HTML language standards since 2000. Though it wasn’t designed in response to mobile technology developments, when today’s publishers consider the question of HTML5 it is in relation to how it delivers content to smartphones, tablets, and desktop computers. However, publishers are also asking the same questions now as they were back in 2012:
“What will the future of publishing be? Native apps? HTML5?”
“Is HTML5 the only solution to work across platforms?”
“Should I design for a native app, then use the same templates for a mobile web design? Or do I design for mobile web first?”
One of the most exciting aspects of HTML5 remains its ability to work well across multiple platforms, accommodating for varied screen sizes, resolutions, aspect ratios and general performance guidelines. It’s also compatible with most Internet browsers. For publishers, some of the best advantages of HTML5 is its ability to send their content to readers on almost any device without requiring readers to download anything. It’s this capability that has publishers placing the microscope over HTML’s newest developments.
The questions arise when publishers find HTML5’s disadvantages, such as while almost all new browsers support HTML5, there are a select few browsers with a small market share that do not. (IE8 comes to mind, but you can see the rest at HTML5test.com.) While those browsers are being phased out as the populace uses updated browsers and devices, it does create uncertainty for publishers targeting mobile web readers.
Another uncertainty troubling publishers is understanding the power and limitations of HTML5 as an app. HTML5 is a markup language of the web, and each device platform operates with another language native to the device. Writing app code in HTML5 requires a measure of translation from device to device, leading to possible inefficiencies in code and performance. Because of this, conventional wisdom pointed to relying on native apps – or apps written for specific device platforms – for a more robust reading experience. This was especially true for publishers hoping to capitalize on offline reading. However, this action required publishers to design and code for individual platforms, creating more work and development for each issue of each publication.
Why We’re Talking About It Now
With the release of iOS 8, Apple has demonstrated support for the new web standards (HTML5). Other companies, such as Google, push the envelope in keeping up with the newest standards and iterations. (Google is also proactive in trying to get their own standards included into HTML5’s standards.) Apple and Microsoft have historically been more cautious in adopting new standards. However, the new release of iOS 8 included a new safari with support for iOS 8. They appear to be positioning themselves to compete more on this with Google with a boost in features supported, including the means to increase development ease for animations, transitions and HTML templates.
Image from sencha.com article “Apple Shows Love for HTML5 with iOS 8“
For mobile apps built in HTML5, this is a step in the right direction. Where the big impact comes in are for those who develop hybrid apps, or apps that use both native and HTML code.
While many publishers are used to talking about apps – or delivering content to their mobile readers – as either a mobile web HTML experience OR a native app, developers have been producing hybrids, or HTML apps with a native wrapper. This allows developers to reuse code across multiple platforms and to embed web code in the apps. However, according to Developer Economics’ “State of the Developer Nation Q3 2014” survey of 10,000 app developers, “the overall proportion of developers using HTML5 on mobile devices is falling, both through those switching to native code and new entrants adopting native platforms.” (Download the State of the Developer Nation on their website, here.)
Typically, publishers have chosen to emphasize either mobile web apps or native apps based on how their readers used their mobile devices, as well as how many resources they had available for creating a good experience across multiple platforms. Based on their answers to those key areas, some publishers chose to design for multiple native platform languages, while others chose an optimized for most screens design, and still others moved to a responsive design mobile web app solution.
Currently, developers are still creating hybrid apps for native platforms, though they prefer to work in the language native to a particular platform. Given the duopoly of Android and iOS in the U.S., this means publishing separate mobile web, iOS and Android apps.
As of yet, HTML5 is still young, and the difference in performance between HTML5 and native apps is in part due to a lack of mature tools for HTML5. This could change as brands use HTML5 more, putting pressure on the need to develop these tools. Recent developments in the hardware – mobile devices – themselves have also been working toward paving the way for HTML5 apps. Newer devices are being made powerful enough to handle HTML5 sites, and HTML5 apps.
For now, your move is to develop a mobile strategy based on your audience’s needs, expectations, and their ability to discover your content. In the future, keep an eye on HTML5 as it could bolster your ability to publish once, syndicate everywhere.