Andrew McHugh is right to contrast the protagonists in his “Fight for the Future: HTML5 vs. Native Apps“. The details, though … about those, I’m less convinced.
McHugh and I agree on several essentials:
- the choice between HTML5 and native is an important one;
- seamless, continuous updating of Web applications is a crucial part of the HTML5 experience in many markets; and
- browsers are vastly better than they were even a year ago.
Too much of his comparison, however, looks backward.
Detour through storage
While McHugh, Technical Content Manager at SoftBear Software, correctly emphasizes the priorities above, parts of his comparison only confuse matters. His second paragraph begins, “HTML5 was developed as a solution to storage issues.” This is at best an extreme and misleading claim, something like finding the origin of the US Civil War in Kansas-based terrorism while neglecting mention of slavery, federalism, or trade policy. HTML5 does provide useful definitions for Web Storage, Offline Storage, and Indexed Database, but WebForms 2.0, canvas
, and the multimedia specifications were far more compelling technical problems than client-side storage in the 2006-2009 time-frame he presumably has in mind.
Emphasis on HTML5 storage is particularly unfortunate in that it’s only a distraction from the true issue at hand, which is to compare HTML5 and native bases for application development now. Whatever their histories, both HTML5 and native now have good handset storage.
Far more than McHugh, I see convergence between the two approaches in their engineering capabilities. For McHugh and other commentators, HTML5 suffers because it doesn’t allow for monetization, it’s incapable of disconnected operation, and is far less secure than native apps, while the latter are expensive to develop and can be updated only with difficulty. Again, while differences in these domains were important just a few years ago, they’ve nearly vanished of late. Alexander Krug, CEO & Founder of SOFTGAMES Mobile Entertainment Services GmbH, even argues, for example, that “… HTML5 Apps are Easy to Monetize“. On the other side, advanced toolkits should largely solve difficulties in updating natively-developed applications.
Details matter
My own perspective is that both HTML5 and native technologies have improved so much that a selection between them depends crucially on engineering details lost in broad overviews. I personally often advocate for HTML5; at the same time, I know that a wise choice for or against it requires careful analysis of the specific situation of an organization. How does the background and culture of the development team mesh with the requirements of particular app stores? Can the devteam recruit effectively in the HTML5 or native communities? What marketing and distribution consequences are there for one or the other approach?
The fight for the future of mobile development has largely moved beyond bits and bytes; now it’s cultural.
Leave a Reply