HTML5 and why IT often leaves the end user naked

Mary Brittain White, CEO of Retriever Communications, discusses IT's default to choosing HTML5 formatting when developing enterprise applications and how it ultimately, it is hurting the end-user.

History is littered with technologies that are hyped by IT as the next major wave with fabulous capabilities. They burn brightly for a few years until their lacklustre performance becomes common conversation in the market. Their enduring legacy is the end user saddled with a poor solution having a heightened distrust of IT.

The common vendor example is the large and costly ERP system that took years to install and is little better than the system it replaced. However, the more acute examples are when the IT mainstream industry backs a technology set that turns out to be inappropriate to the problem.

By example WAP, a wireless data protocol for phones was all the rage from about 2000 through to 2004, attracting a mountain of investment funds in the USA and Northern Europe and the accolade of the telco industry, only to disappear without trace.

Bluetooth was similar; overhyped as the answer to all personal networking requirements, it has settled down to a helpful but restricted use case.

So how can this happen? IT people are generally smart enough, so why do they laud solutions that work so poorly? Often insisting on their selected solution as the business asks for something else. So lets look at a current example – IT’s rapture with HTML5 as the universal answer to wireless apps – to see if it reveals any answers.

HTML5 vs. native wireless apps

Apple’s success with apps is all about the app being local on the device, or “native”. This approach allows strong integration by the app with the device features like the camera or GPS, while also delivering good performance and reliability irrespective of wireless coverage.

HTML5 apps assume that you have coverage, don’t work with the camera or GPS features of your device, have no local data and require the server or website to drive the app; this is just fine for booking airline tickets, but awful for the technician fixing your dishwasher, the sales representative doing a call or a nurse delivering homecare.

So why is the IT industry advocating the HTML5 route as a universal solution when the under pinning assumption - that you are always in mobile coverage - is demonstrably untrue? Whether you are driving down Highway 101 in Silicon Valley, sitting in a restaurant in downtown Toronto or working in West Virginia, you know on a daily basis that coverage is not universal.

The reasoning for IT advocating the HTML5 solution includes:

  • HTML5 coding skills are easily available in the market as they are the same skills required in web development, so if you are a large consultancy firm your staff is already trained.
  • Easier ongoing maintenance as the HTML5 is centrally controlled – if I have a change I just update my server and that is what everyone now sees. In contrast, a native app needs to be updated on every mobile device, which is much more work.
  • HTML5 will be a standard one day, in contrast to developing on a vendor’s platform for mobile, which is proprietary to that vendor. Skills in a specific vendor are not valued at a CV level unless the vendor becomes market dominant in a significant category.
  • It comes cheaply from one of our current vendors, like scheduling or accounts, and though it is not great fit it is fully integrated so we won’t have to worry about setting up the connections between our legacy system and our mobile capability.

For these reasons it is easier for IT all around, however is very unfortunate that the end user experience is poor and consequently the business benefits achieved in the project are at risk. Of course IT is not alone; the industry backs up these decisions by analysts declaring that HTML5 is the market trend, as well as large vendors marketing their variety of HTML5 solutions and journalists adding to the hype.

But without a happy end user it will always come to a bad end. The emperor is declared to have no clothes as the market moves to a new entrant that has a different approach.

If you look at the last decade with search engines, sales force automation or social media, the market behaved exactly like this – brand vendors and IT pundits laying a roadmap that was unappealing to the end user, only to be over turned by a new entrant that breaks all the rules, but is loved by their customers.

The best IT shops are business and end user centric; we need to applaud their courage at not just following the pack. If your IT department is not in this league then the guy at the top needs to change their attitude.

We all deserve clothes. in hearing industry leaders discuss subjects like this and sharing their use-cases? Attend the co-located IoT Tech Expo, Blockchain Expo, AI & Big Data Expo and Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam and explore the future of enterprise technology.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

4 Jul 2013, 1:02 p.m.

Interesting article - I heartily endorse your call to consider a projects business benefits rather than following the hype.

However - on first read - this article seems to be confusing HTML5 apps with HTML5 web apps, and also contains some technical inaccuracies.

This may be down to terminology, but it is incorrect to say that "HTML5 apps assume that you have coverage, don’t work with the camera or GPS features of your device, have no local data and require the server or website to drive the app". Web apps have these characteristics. (apart from the local data point). When wrapped with something like PhoneGap and delivered via the respective store, HTML5 hybrid apps can do all of these things.

And HTML5 hybrid apps tend to be referred to as HTML apps (see Whereas apps delivered by the browser tend to be called 'web apps' - not HTML5 apps.

Perhaps the confusion would be avoided if you were to refer to them as 'HTML5 web apps' rather than just 'HTML5 apps'.

Also - whatever your view on the above - HTML5 does have local storage, even when delivered as a web app.