HTML5 Dangers: WebSockets and Stable Standards
The Role of Browsers
Browsers and browser vendors like Google, Microsoft and Mozilla also play a role in how HTML5 specs play. Each one has a different perspective in how to balance the trade-offs between quick innovation and spec stability.
Google's Chrome and Mozilla's Firefox have generally mixed the stable specs from ones that are rapidly changing. With Internet Explorer 9, Microsoft has begun to distinguish stable vs. unstable specifications, keeping the latter out of the browser. Instead the company experiments with unstable specs at www.html5labs.com.
SVG makes for an interesting example: the first browser with practical display of Scalable Vector Graphics, late in 2000, was Internet Explorer 6, with an SVG plugin from Adobe. By 2005 and 2006, other browsers supported parts of the still-evolving SVG standard. IE9 introduced native support for most of SVG during 2010-2011, after a view that the SVG specification was adequately stable. While Microsoft probably could have supported it faster, IE did avoid putting Web developers through many of the pain-points that made it hard to test and, in some cases, led to site breakage as the spec changed.
WebSockets: An Unstable Spec Case Study
Let’s go deeper into the WebSockets case. There's no question that mistakes were made with its early prototypes and their immediate acceptance regardless of stability. To understand how, you need to think first of the original Web, from the early years of the 1990s. Back then it was all "pull" -- a Web browser sends a request and retrieves a page to display. Needs for more general kinds of networking have been obvious for most of the last two decades; among all the technical fixes to this point, the AJAX model first accessible in Internet Explorer 5.0 in spring of 1999 represented the most dramatic advance.
Even Ajax imposes constraints on the responsiveness (latency) and capacity (bandwidth) of applications that have become unacceptable. The constraints have remained in large part because security is so hard to get right. The point of WebSockets is to solve this problem.
It seemed a "good enough" solution to be supported first in Chrome at the end of 2009. The spec kept changing and sites had to keep updating implementations as their sites broke. By Fall 2010, several browsers supported WebSocket capabilities. That was also when a team published a paper that described security vulnerabilities. The outcome: Firefox and Opera turned off WebSocket in their browsers. Internet Explorer chose not to carry WebSockets because it was too unstable to make a bet on the technology and instead prototype it. It's widely recognized that, WebSocket will continue to change and is not yet stable. It certainly will change and, when it becomes successful enough, will begin again to expand in capabilities and refinements.
As mentioned above, browser vendors have made different choices in regard to support of WebSockets. Who's right in all this? Maybe everyone. While partisans lob shots at Firefox and Google, respectively, for publishing browsers that are risky, and at Microsoft for conservatism, the choices aren't easy. Engineering is all about trade-offs, and the trade-offs in a case such as this are subtle and hard to compute with precision. Different organizations, developing for different markets, might justly make different choices. Microsoft Technical Evangelist Giorgio Sardo is certainly right when he emphasizes "It's important to get it right." Sardo doesn't mean something as simple as "always assume IE" or even "use only accepted standards." He admits that, "personally I like WebSockets" -- and he should! HTML5 is the way it is because bright people are working at the edge of our understanding to make the most of the Internet infrastructure as it exists right now. There are thousands of valuable applications waiting to be written, and HTML5 is mostly part of the solution, not the problem.
Finding the Balance
The lesson of WebSockets, then, is not to retreat and give up on HTML5. Instead, we should take these steps:
1. Analyze clearly what parts of stable HTML5 pay-off for your site versus the risks of unstable spec development
2. Research why browsers support specific HTML5 technologies and what it means to your end-user experience if you develop for them
3. Plan your development balancing new technology with website stability be prepared to weigh the costs of supporting changing standards
4. And of course, stay current and be active in the latest spec discussions
Find or become an HTML5 expert through sites like HTML5 Labs or WebSocket.org that make it easier to assess a new technology. Are you looking for a simple choice, like adopting HTML5 and then living happily ever after? That's not realistic. What is realistic is that, with a little effort invested in the appropriate technical communities, you and your teammates can stay current with the best Internet programming practices. If you're good enough, you can even have a hand in their creation.
About the Author
This site does business with companies mentioned in this article or associated with the technologies.