The Truth About HTML5 – Part #2
Author: Gil Bouhnick
Previously on “The Truth About HTML5”: We’ve reviewed the changes happening in mobility worldwide, influencing the enterprise world; employees looking to utilize their personal smartphones and tablets for activities that are work related, IT managers looking for zero footprint, device agnostic solutions.
HTML5 offers a perfect technology for those requirements, and has the potential to become the mobile leading technology for building applications and solutions. However, as usual, things are not that simple…
Part #2: The Industry Bear hug:
Not surprisingly, all the major mobile players are now hugging HTML5. “We support HTML5”, they all claim, “We push HTML5”, they brag, “We are in love with HTML5” they almosr shout, “We were there first! Long time before the others joined!”
OK, that’s enough, we get the picture, thanks, we all support HTML5 now, that’s given, but how exactly, and more importantly: isn’t all this HTML5 love becoming a bear hug?
Let’s look at the different mobility players and how their technologies work with HTML5:
- Giants like Google, Apple and Microsoft have practically (although not officially) dumped their own technologies (Google Gears, Silverlight) in favor of HTML5. They are investing in making their browsers and micro browsers 100% certified for HTML5. Microsoft will even bring native “off-browser” support for HTML5-based widgets in Windows 8 (demonstrations have already been shown – see image below).
- Software companies developing Internet browsers are adding HTML5 support. Some of them (such as Mozilla) are aiming high with HTML5, and going to enrich the language beyond the standard capabilities, in order to try and turn their browsers into a web-based operating systems (we all know ChromeOS, the same goes with WebTops running Mozilla FireFox, etc.). The goal is eventually to compete with native apps by allowing web applications to do things they cannot do running inside existing browsers.
- MEAP companies are adopting the “hybrid” approach where HTML5 applications are running inside proprietary containers “theoretically” closing some additional capabilities which are not yet part of the standard HTML5 functional standard (such as specific hardware integration etc.).
- Industrial devices manufacturers (building rugged or niche devices) are in the process of building their own proprietary HTML5 containers (mostly running on top of Android and Windows Embedded) to allow easier integration with their own proprietary hardware (barcode scanners, printers, etc.)
- Mobile applications vendors are developing web apps using HTML5, and whenever they encounter a technical limitation they usually adopting (or build) a native container that will complete the missing functionality while “wrapping” and “hosting” the original web app. (There are plenty of containers, native wrappers such as PhoneGap, which are providing web access to some native resources).
As you can see, there are many contenders in this HTML5 race. Unfortunately, each category is taking a different course, different approach, resulting in a fragmentation.
Many of those vendors have created a culture of native runtime environments and therefore may find it tempting to transfer that culture to the HTML5 world, by transferring their design principles and technology into HTML5 containers. They may even feel that it’s a good decision – shorter time to market, lesser dependency on browser and device vendors, and higher compatibility with earlier versions of these vendors’ offerings.
Quite a temptation, right?
Well, not all temptations are worth following. This one only seems to lead to standardization, but in fact it just keeps the old “my environment, my rules” game going. Even if this is done with the best of intentions, this is not a standards-oriented approach and, since it pretends to be one, it is a serious threat to the acceptance and usability of the HTML5 standard.
Fragmentation, remind you, is one of the biggest problems of Android. Web technologies and especially HTML5 were designed to work across platforms…
So there you have it.
Chapter #2 ends with this kind of a bitter aftertaste. The one technology that could potentially run identically regardless to the platform it is running on, is at the risk of becoming fragmented due to this massive competition and high number of competitors, all looking to take advantage of the huge HTML5 buzz.
In the next part of ‘The Truth About HTML5’ we will discuss some of the ways to avoid HTML5 fragmentation, give some recommendations, and present the ClickSoftware approach to HTML5.