Search Google for “HTML vs Native” and you’ll get about 2.5m results. It’s a hot topic, and you’ll find a boatload of articles, many of which have an agenda, declaring that “Native is Dead” or “HTML Is Crippled and Slow.”
Don’t bother reading those. Here is the truth – native isn’t dead, although it is ill. Standards will always win in the end. While HTML is certainly crippled and slow, it’s improving every day. This is because standards are slow to evolve and be implemented.
While early adopters use blood, sweat, tears and a little magic to harness the powers of emerging technologies, it takes a lot longer than you’d think for them to become mainstream. Remember the Year of Mobile? It was going to be “next year” from roughly 2004 onwards. It took seven years for the real Year of Mobile, 2011, to arrive. Similarly, Flash only kicked the bucket about five years after it first received a terminal diagnosis.
Today, both HTML and native have benefits. Making hybrids of the two offers publishers an attractive proposition, where native wrappers precludes the need to use HTML in unnecessarily complex ways. Layers of native will continue to peel away as HTML is progressively developed and improved. This may means that native operating systems start losing their identities, but that’s a discussion for another day.
HTML’s strongest advantage is that it is a web standard – an internationally agreed upon method of storing and sharing information, so it is not going to disappear. And WebKit, the open source layout engine technology at the heart of most browsers, has benefited from 1,400 man years of work. The separation of presentation and content at the heart of HTML neatly allows for cross-platform interoperability, although this is not as easy as it should be yet. This brings with it a strong advantage in that content, and workflows, are future-proofed. Native apps are not protected in this same way. In addition, existing outside of the native ecosystems is attractive to many businesses as it allows them far more control over things like data and revenue.
So which bits of your app should still be native? Remember that different apps require different features, but as a guide, the bits that are painful using HTML are:
- Smooth, responsive transitions – Even the tech community can’t agree when (or if) HTML will match the performance of native apps. It’s complicated. What is clear is that the native apps in the stores are, for whatever reason, a whole lot smoother than the web apps;
- Offline storage – HTML only allows you to store a limited amount of data, and the standards are currently a bit flaky. Expect this to improve quite quickly;
- Offline advertising and analytics – This might be fairly publishing specific, but both are a real challenge using HTML;
- Background activity – At present, if a user doesn’t have a web site/app loaded in a page in front of them, you have no way of interacting with that user. Native apps, however, allow you to send notifications, download background content, or wake up the app based on time or location. In essence, a user can only pull content using a web app, but you can push content using a native app; and
As we predict that native wrappers will die out in the relatively near future, it’s important to be ready for the coming changes. Workflows, technology and content can and should be protected through the smart use of structured data and HTML – but it’s also important to avoid relying purely on HTML until it makes sense. The future belongs to it – standards always win in the end. However, sadly, the future isn’t now. It’s 2017. And you can quote me on that.
Jon Marks is CTO of Kaldor.
Share this story