It appears to me that HTML 5 is reaching the proverbial “critical mass” on the Internet Hype Machine. Everybody and their brother is touting HTML 5 as the solution to every ailment, and every vendor is proclaiming “HTML 5 support”. Before I go any further in this post, please understand the following – I am a HUGE supporter of HTML 5. As a mobile application developer, I have been a backer of HTML 5 ratification from the time Palm implemented HTML 5 proposed standards as the foundation for WebOS development. HTML 5 offers a world of promise for addressing many mobile (and desktop) web development woes, including the fundamental need to work offline (i.e. – NO INTERNET CONNECTIVITY) using a single standard for programming. However, the push to “jump on the HTML 5 bandwagon” immediately and start migrating native mobile applications to the web causes me to have an old (and far too familiar) “sinking feeling”.
If you read my introductory paragraph closely, you may have noticed my careful choice of the phrases “proposed standards” and “world of promise” when talking about HTML 5. There is a reason for that – HTML 5 is not yet an official standard. In fact, the W3C (the official sanctioning body for HTML specifications) has recently mentioned that final ratification may still be years away. I totally understand and accept that fact. I also understand, however, the potential implications that presents for today and until the time that a final specification is ratified.
My web development as a professional consultant actually goes back to the days when HTML 2 was a proposed standard (ah yes… when a company’s web site was largely static and, well, rather plain or ugly by today’s standards). As HTML evolved, from proposed specification through the ratification process, the following events have ALWAYS occurred:
- Company A that supports using HTML (read – “browser maker” or “web development tools maker”) implements their “interpretation” of the proposed HTML standard in product.
- Company B that supports using HTML decides Company A’s interpretation isn’t quite right and implements their own variation of the proposed standard.
- Companies C, D, E, etc all do the same.
Back in the days of HTML 2 and HTML 3, we were fortunate in how limited the number of “companies” referenced above were. Even then, however, the differing interpretations often created such development havoc that building one application for the web was more time- and resource-consuming than building separate native applications. Anyone reading this remember HTML 3 or 3.2 and the “Internet Explorer/Netscape Navigator Browser Wars”? I sure do. The varying approaches that Microsoft and Netscape took towards “implementing” HTML specifications soured many businesses from moving to the web. In fact (and totally in my opinion), I believe that the fallout from the “Browser Wars” actually set back web adoption by a few years. Unfortunately, HTML 5 is setting up to walk down this same path again.
The “HTML landscape” of 2011 is far more complex than it was a decade-plus ago. The number of “companies” (those providing fundamental support for HTML through browsers and development platforms) dwarfs the numbers of the late 1990’s. Furthermore, their stakes in the HTML market are far greater and extend far further than they did 10 years ago, with the desktop and mobile web reaching a vastly larger audience. During this “Wild West” period of HTML 5 implementation, when there is no final specification and plenty of room for “interpretation”, these companies have the ability to lead developers down a single path that could, in turn, restrict wider use. While there is no guarantee that this will happen, history speaks otherwise. This risk, in turn, is one that potentially result in a repeat of the development nightmares of the past. Even as we speak, current browsers and their “HTML 5 support” are beginning to cause developers to spend extra development time and effort to ensure that what works for “Browser A” also works for “Browser B” (and “Browser C", D,E and F”). Speaking strictly from a risk management perspective, the longer the time it takes for formal ratification, the greater the risks become.
While I eagerly await the day when HTML 5 is formally ratified and HTML 5-supported platforms come into greater alignment, I have a hard time staking my (or a company’s) development investment on the standard. While the HTML 5 “companies” continue to bombard me with messages on why I should invest in their HTML 5 implementations, I cannot help but feel that their answers to HTML 5 will lead me to a point where I will be either sandboxed into just their products or be forced to spend a lot of time coding my way out of their sandbox. All of that leads to that familiar sinking feeling of the past. That feeling is something I already have faced one too many times. So, I will stick with either native mobile applications or web applications that work across platforms (complete with limitations) until I feel comfortable that the sinking feeling will stay away.
Not logged in