HTML5 seems to be everywhere at the minute, with many of those I would consider as software giants hinting that that HTML5 may be the future of their mobile strategy. I know there has been much written recently, but here I want to share my views.

I believe that whilst HTML5 is an amazing leap forward in technology, it could be on the verge of becoming the next technology “buzz” word and is wrongly being touted as a cure for all that ails mobile development.

In this blog I will be outlining just a few issues which, to me, mean HTML5 is not a “one size fit all” solution and, in its current state does not provide an answer for those who need to mobilise enterprise applications.

Here are my top five things to consider when pondering whether to go HTML5 or native:

  1.  Security

HTML5 is still HTML, sounds obvious? Maybe, but to me this is one of the big things that those of us in the enterprise seem to be forgetting. Although HTML5 applications can use HTTPS to secure the channel, all the normal vulnerabilities of HTML applications such as fishing, malware, and macros, to name but a few, still exist as threats to HTML5.

Whilst this may not be an issue with business to consumer applications or social networking think of it in terms of your enterprise data, would you trust a HTML5 application in its current iteration to keep your data 100% safe?

  1.  Maturity

Let’s not forget HTML 5 is still an evolving standard and whilst this does mean that HTML5 in 2015 could be amazing, what it means today is that enterprises could be investing R&D in solutions where the applistructure is still shaky. Hence we find ourselves as developers, “band-aiding” problems while hoping the real fix will be just around the corner.

This obviously costs you time and prevents your developers from getting on with the development they need to do. I have experienced this problem with immature technologies first hand. One of the last projects I was involved in as developer and project manager, we wrote a whole interface to something in HTML and Javascript, we then began to realise that things that on paper were supposed to work didn’t work because the synchronisation between objects wasn’t there.

In my case the customer kept insisting it was a bug but there was nothing wrong with the code, I needed to create numerous “work arounds” just to get everything to work, having written the whole code I was faced with fixing all the little things that didn’t quite work the way they should have. The whole experience, which I vowed never to relive, made it very obvious to me that working with an immature technology your code can quickly become unmanageable.

  1.  Synchronicity

As you know HTML5 is an asynchronous technology that is being stretched to become synchronous by using JavaScript. JavaScript relies on synchronisation between the different document objects and that in turn depends on the download and refresh speed of the objects. 3G is a flexible speed network that can drop speed in areas based on utilisation, coverage and many other factors in cases like that, the synchronisation between objects can be broken.

This phenomenon is clearly demonstrated when we look at the Facebook application on iPhone where the pictures, tags and descriptions are not always synchronised when using 3G. I know this has happened to me on more than one occasion, I get a note to say someone has tagged me in a picture, I have a look and don’t recognise myself or the picture this is because someone has uploaded a new picture and tagged me but the tag has come through before the picture normally because the 3G coverage in the area I am in isn’t great.

With time and especially with move to 4G the situation will of course improve but your guess is as good as mine as to when 4G will be available all across the UK, let alone worldwide. This may only seem like a small annoyance but imagine if the enterprise application I use most, my PO approval app, were to run on HTML5 and encounter the same issue.

Imagine if I got an approve/reject request for a PO before I got the cost break down, what would I do? I would have no idea what I was approving; worse still imagine if I had mishmash of data, meaning I could approve something completely in error. Obviously applications with sensitive enterprise data these sorts of issues are far more important and could result in costly errors if the data isn’t right all of the time.

  1.  Not truly native

Native technology is compiled for each of the devices, fully utilising the capabilities of each device in the most efficient manner, so providing the highest CPU, RAM, caching etc. on each of the devices. HTML 5 by its very nature is going through a browser container that renders the objects and synchronised them based on JavaScript engine and CSS, all these mechanism cost in performance and hardware utilisation.

  1.  Client technology

HTML5 is still at its heart a client technology with a mobile app, regardless of where your application sits, you ideally would want the platform to use server resources where they are required at the server and client resources where they are required on the client resources, this of course is not the case with HTML5. In an ideal world the developer shouldn’t need to go into the nitty gritty of requests and synchronisation but of course with HTML5 you need to do all of that.

HTML5 is of course very easy to learn however, we must not forget it is only a front end everything you do on the client you eventually need to submit a request back to the server to make anything happen. This means the partitioning of logic between the client and the server needs to be manually managed by the developers and supported by the design of the application.

You may think there is nothing wrong with that, we have all done 3 tier application development in our time but when compared to working with an application platform, that automatically take care of the partitioning of code between client and server (and all communication of course), we can see that with a tool such an application platform the development process not only significant reduces in time but also in complexity and number of lines of code. I think every developer reading this will understand that this of course significantly reduces project risks, costs and increases quality.

I would argue that right now HTML5 is an amazing tool for social media and maybe even some business to consumer applications, it is perfect for notifications but when you start talking enterprise data and process it is just not ready.

Ask yourself do you want to use JavaScript to get your data from SAP? If you want interaction with sensitive enterprise can you afford to risk the vulnerability? Let’s face it we have been here with the dotcom bubble from that very costly lesson we learned security is key, we learned that performance and synchronisation can make or break you. Let’s not repeat those mistakes!

I don’t want to come across as an old cynic I really am very excited about HTML 5, it is for that reason that I would like to see the development community use it where its best suited until it matures. I don’t want to see HTML5 become a whipping boy for those who use it before its ready.

In 4 to 5 years time, we don’t know how the HTML5 will look all these issues may have been resolved, and I for one hope they have been, but for the next 4 or 5 years if you are serious about developing an enterprise application learn from the past go with something that can actually run natively. Mobile application platforms are built on the same premise as HTML5, develop once deploy anywhere, but with enterprises in mind they have none of the above issues I mentioned and they are the safe bet.