Origins
Back in the day, when the web industry was just beginning to take shape, browsers were just starting to get important to everyone’s lives. Competition was extreme. In fact, that period of intense competition between Netscape and Internet Explorer was called ‘The Browser Wars’.
During this time, both browsers tried to gain the edge over each other by introducing as many nifty features as possible, and also to display every page as best as they can, whether or not the page had valid HTML, CSS or JS code or not. This lead to a proliferation of badly coded sites on the web which still displayed more or less satisfactorily in browsers. The World Wide Web Consortium, when deciding the next version of HTML after 4.01, decided for a more strict approach. Thus landed, XHTML, which was based on XML and had much more strict rules for it.
This newfound emphasis on XHTML was met with the industry embracing standards based web design, or so we thought. While many advanced developers made sure their pages validated with proper XHTML, most web developers either did not care, or simply followed some of the rules and left out others. Another problem was that many developers thought they were serving a valid XHTML page as it validated online, but in reality it was just processed as an html page and not an XML document (the intention of an XHTML page) because it was not served up with the proper MIME type.
Browser makers noticed this, and wanted the next version of HTML to move in a different direction than the XHTML specification. The W3C at that point was firmly on the side of XHTML and was working on XHTML2 as the next version of the standard. Meanwhile, Opera, Mozilla and Apple formed a separate group called the ‘WHATWG’ and started working on a parallel specification which was more in line with what most developers were doing in the real world and which dealt with modern web applications. This specification started to get more attention from web developers, to the point where the W3C came back and said that they would discontinue work on XHTML2 and adopt HTML5 as the next version of HTML officially.
Present Day
In just a few years, HTML5 has come a long way from its humble beginnings. Along the way, there have been certain developments in the technology landscape that were not there at the time of previous standards, like the rise of mobiles and various other devices, as well as the intense competition between a variety of browser vendors (unlike the two in the ‘browser wars’ era). All this means that the way HTML5 has evolved and is influencing the Web is really very interesting.
One of the most important ways in which this has played out is decline of one of the most important components of the web – plugins. Newer features of HTML5 like (which allows you to do interactive 2D graphics) and more put HTML5 head to head with plugins on the web.
This is because HTML5 is made for web applications, not just websites. In fact Ian Hickson, editor of the HTML5 spec on WHATWG said HTML5 is “…extending the language to better support Web applications, since that is one of the directions the Web is going in and is one of the areas least well served by HTML so far. This puts HTML in direct competition with other technologies intended for applications deployed over the Web, in particular Flash and Silverlight”. On desktop, plugins such as Flash and Silverlight etc are still pretty relevant. However, on mobile devices, stability, performance (both in terms of CPU and memory) are of utmost concern. Some important phone manufacturers took the call to go with HTML5 and ditch having plugins on those systems.
Another interesting difference from the days of the ‘Browser Wars’ era is that there are many more browser vendors in the game now, and all of them are willing to work on building new features and technologies by discussing and reaching consensus. This of course, is not the case overtime, but a whole lot of features and technologies in the modern web environment have come along this process. Lets take the example of the <canvas> tag again. It was initially something that Apple demonstrated and implemented, and then later on other browsers, instead of making something similar but competing like in the old days, came together and implemented in in their own browsers too. There is a fine line between competing with each other and at the same time reaching consensus to build the future foundations of the Web better, and browser and with HTML5 this has been the case.
Sometimes though, viewpoints diverge. An example of this is that when it comes to HTML5, we have to keep an eye on two things. The ‘living standard’ simply called ‘HTML’ by the WHATWG and the ‘HTML5’ specification under the W3C. The former is under the editorship for Ian Hickson. The HTML version in the WHATWG is supposed to be a living standard where there is not really a version of HTML as such, but is just a specification which is continuously updated as feedback from developers, designers, browser vendors etc is received over time to advance the web. The W3C approach is to make a snapshot of HTML called “HTML5’ which has a lot of new feature geared towards the future of the web.
Hype vs Fact
HTML5 has been an object of much hype. In many cases people have twisted and turned what the technology is and what it really means for the Web to suit their own narrative. HTML5 can’t solve every problem and neither should it. HTML5 the specification (at least the W3C one) contains just a subset of modern new web technologies which are exciting web developers today. It contains a bunch of new semantically correct elements, easier and more useful way of making web forms, ways of running applications offline and more.
However, just HTML5 is usually not enough. To make modern compelling web applications, you need to make it look great too. That is the job of CSS or Cascading Style Sheets. This is a separate standard than HTML, though used in conjunction with it. New improvements in this standard, in the form of CSS3 are also shaping the future of the Web. Then there comes other standards which are JavaScript based but are not part of HTML5 like Geolocation or WebRTC (which defines Camera access and Mic Access along with peer to peer communication). All these when used together (either in part of whole) will result in the modern compelling web applications of tomorrow.
There have a been a few detractors as well, saying that there is still a large gap between native applications on mobile devices and web applications. However, web standards are being defined and implemented in browsers which are closing this gap very fast. For example, most smartphone browsers already support web applications to have access to the accelerometer and gyroscope and some also have support for the camera and 3D Graphics. Another thing to consider with the Web platform is the fact that you can write once and deploy everywhere, whereas in the case of native apps, you have the rewrite the same product in many different languages for different platforms, and be bound by the rules and demands of each platforms’s app store. The Web platform also still gives the most reach than any other platform, and given the improvements in this platform happening with HTML5 and other upcoming technologies, web applications will remain the right choice for developers seeking to make innovative applications for the largest possible audience.
All said and done
We’ve covered how HTML5 came to be, what it is today, separated the hype and the fact, looked at its weak points and strong ones too. Doing so is essential to place these new web technologies in the proper context. Web standards are of no use until browser vendors implement them, and when it comes to HTML5 and other upcoming technologies, all browsers are on board to make this a success.
Choosing the technology stack for your next venture will depend on a number of factors. However, HTML5 will certainly should be a very compelling option to have in mind. The reach, pace of development, interest from developers, ease of learning, developing and deploying as well as reduced cost of remaking and maintaining the same app on different platforms make web applications the most exciting technology stack amongst the myriad of options developers have today.
