Why HTML5 is not the choice for enterprise mobility

HTML5 is being hailed as the programming language that will not only enable developers to achieve multi-purpose web application development, but ultimately solve many issues facing mobile development.

As a result, the buzz around the technology is intensifying, further proof of which came from a recent survey of 1,200 developers, which found that 75 per cent are using, or plan to use, HTML5 for app development. Perhaps this is partly due to recent accolades, such as Adobe’s public denouncement of Flex in favour of HTML5, hailing it as the best technology for creating and deploying rich content to the browser across mobile platforms.
 
HTML5 offers some real advantages in the consumer space and for tools such as social media and video. However, the reality is that it’s not mature enough as a tool for business applications. Issues such as security, synchronicity and the very fact that it’s an evolving standard make it an unreliable option for enterprises. Consideration of these pain points offers a reminder that, while the future may be an HTML5 one, right now it’s not the panacea for mobile development. Moreover, for those looking to mobilise their enterprise applications, the priority is that sensitive data is kept safe, and applications perform as they should.

Security concerns

The security of data is a key concern, and the vulnerabilities that we associate with HTML applications – phishing, malware and denial of service attacks – still apply. In its new 2012 Security Threat Report, Sophos cites that HTML5 offers cyber criminals “new ways to trick people into passing on potentially sensitive data or installing malware”, and that “the sophisticated presentation layers that can be created using HTML5 ‘blur the lines’ between what's running on the device and what's on the internet”.

There is a fundamental danger that HTML5 will offer an open gateway to the corporate network, and, with the proliferation of mobile devices accessing networks, this is too much of a risk to take. There is also a key question of trust – when it comes to enterprise data, would you trust an HTML5 application in its current iteration to keep your data 100 per cent safe? Do you want to use JavaScript to get your data from SAP?

When it comes to developing for enterprise applications, synchronicity is key, and perhaps the primary concern when it comes to HTML5, is that it is an asynchronous technology stretched to become synchronous using JavaScript. JavaScript relies on the synchronisation between different document objects, the download and refresh speed of which can be significantly affected by bandwidth. The downside is that synchronisation between objects can be broken when 3G drops speed based on factors such as utilisation and coverage.

A common example is when using a Facebook iPhone application and receiving a notification that a ‘friend’ has tagged a photo of you. Since the 3G coverage in your area is weak, you might not recognise yourself in the picture, or else the tag has come through before the picture. A comparable business context could be using a PO approval app on a mobile device that runs on HTML5, and receiving a request to approve or reject it before the cost breakdown comes through. This would effectively mean approving without knowledge of the full facts. While for social media apps there may be less severe consequences, in the enterprise there is far more sensitive data at stake and huge implications for the business if things go wrong.

Evolving standard

The very fact that HTML5 is an evolving standard means it's not a ‘model de facto’, but a technology that is still in its infancy stages. The World Wide Web Consortium (W3C) will not finalise the definition of the HTML5 standard for several more years, which poses significant levels of uncertainty around its validity and reliability. For example, given the issue with synchronisation between objects, developers will find they constantly have to patch problems when HTML5 doesn’t perform as it should, which will cost money and time. Unfortunately, when working with an immature technology, an entire code can very quickly become unmanageable. Certainly when 4G arrives in the next four to five years, many of these concerns will evaporate, but until then we have to consider HTML5 in the context of 3G, and therefore not a foolproof technology.

Jeffrey Hammond, principal analyst at Forrester, says that “it isn't simply a question of either/or; there are four viable approaches to choose from: native, hybrid apps (native code with HTML and JavaScript), mobile middleware platforms, and a web approach (HTML5 and JavaScript)”. This suggests that HTLM5 is not a “one-size-fits-all” solution in its current state, but rather what should be considered is a hybrid approach that will suit a complex mobile strategy, taking into consideration how people are using particular apps. Native app development, mobile middleware platforms and a web approach, can all in fact be viable choices for enterprise application development.

In four to five years time, when 4G will be widely available, HTML5 might well have matured enough to be seriously considered for a range of different development purposes, including as a tool for business applications. Until then, in order to successfully develop for enterprises, it's more sensible to opt for something that can run natively. This means applications can be optimised to the programming interface that a specific device platform offers. Mobile application platforms are built on the same premise as HTML5 – develop once, deploy anywhere – but they have none of the above mentioned issues around security and synchronicity, and so offer a much safer option until HTML5 technology matures.