Assumptions 5 & 6 in the series on HTML5 for Enterprise

The story continues – HTML5 and what it is mostly likely good for in Enterprise.

5 – An HTML5 web app can do everything a native app can

Native apps give ultimate access to the features of a given device.

For example Android allows the developer to pretty much do what they like – even going as far as overriding the built-in phone dialler app if that is really whats wanted. Android does suffer from some fragmentation of the operating system though – either because the user is not using the most recent version of the OS, or because the device manufacturer has changed the base Android software – so some things don’t always work on every device.

iOS is quite a bit more restricted both in terms of the device features that are made visible to the developer, and in terms of the functionality that Apple’s vetting process will and won’t allow.

In contrast, HTML5 does not offer the developer access to all of the native device features. The browser on the device is somewhat abstracted from the underlying hardware and so while HTML5 does offer access to some functions which were traditionally only available to native apps – the camera for example – there are some things which it doesn’t do, or doesn’t do particularly well.

Anything that requires intensive computation within an HTML5 web page – such as complex animation, or even page transitions – can often appear stilted or unresponsive on a mobile device. Coding these compute-intensive tasks inside the browser is all achieved through Javascript, which is traditionally not considered a high performance language (though this does have a lot of attention so it continues to improve rapidly). Native apps – coded in Java for Android or Objective C for iOS – don’t suffer from these same performance limitations, and can access a multitude of third-party libraries to assist with complex tasks.

Last on this point, a note on some of the UI frameworks that are around right now, such as the well known JQuery mobile and Sencha, and the lesser known such as Kendo, Lungo (in development, but my favourite looking),

6 – Hybrid apps will solve HTML5’s deficiencies

There is a middle ground between Native apps and HTML5 web apps, known as “Hybrid” apps. There are several of these available, but from what I know these all work in a similar way … a native app which offers access to underlying device features through an API which is common to all devices, and a User Interface built in HTML/Javascript/CSS.

Hybrid apps have a few immediate benefits :

  • Your hybrid app is installed onto the device in the same way as any other native app – downloaded from a website or Apple iTunes/Google Play.
  • The hybrid app containers offer the same access to native device features across all devices and operating systems
  • Most coding for an app uses HTML5/Javascript/CSS3 so the skills are relatively available, and are cheaper, compared to Objective-C or Java

With a few drawbacks, of course :

  • HTML5 User Interface may use a different browser (or web view) than the standard browser on the device, leading to more inconsistencies regarding HTML5 and Javascript support.
  • Some Hybrid technologies require the developer to ‘tool-up’ for each platform so that they can build and deploy the hybrid app to the app store. This would include using a Mac for any iOS development (which may seem like a small thing, but not every dev. shop use Mac’s). Note that there are Hybrid technologies around such as Trigger.io, Phonegap, and maybe others – which offer a service to build your app in the cloud, removing the need to tool-up for each device platform. Trigger.io is a personal favourite of mine due to it’s easy to use web based toolset vs. Eclipse IDE.
  • In an attempt to provide generic support across platforms, not all Hybrid containers respect the uniqueness of all devices’ User Interface. The UI can look generic, meaning that at least in theory your users are not going to like it. In practice this may not be that big a deal. It is worth checking though that all the devices physical keys work in the expected way – e.g. as iOS don’t have a physical “back” key it may be missing or not work on a Hybrid app running on Android.

More to come in conclusion on why only some of the above points and preceding posts are relevant to Enterprises.

One thought on “Assumptions 5 & 6 in the series on HTML5 for Enterprise

Leave a comment