HTML5 and Enterprise on Mobile

An Argument

Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That’s as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you’ve read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author’s inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as “enterprise” to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn’t addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what “enterprise” means.

Security

So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven’t been inculcated in an enterprise environment and maybe don’t think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the “new shiny” and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn’t mean they aren’t in the code borrowed from somewhere else, especially if the developer is new to the game.

Synchronicity

I’d like to think every developer has already built a system to lock records — ideally one that doesn’t halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don’t “log out,” and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it’s a bit trickier with more likelihood of flaky connections and long wait times. It doesn’t need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don’t have clean methods of handling dropped connections and can end up leaving users stranded.

While that’s not the technology’s fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you’ve been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla’s IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren’t in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.

• There is no simple solution for local storage by Chris Heilmann;
• PSA: DOM Local Storage considered harmful by Taras Glek;
• In defense of localStorage by Nicholas C. Zakas;
• localStorage, perhaps not so harmful by John Allsopp.

Conclusion

Look to the business case. Don’t fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don’t fall for the arguments in favor just because of a knee-jerk reaction against “stodgy” enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.