You celebrate: it's the first Friday after your start-up opens its first real office and a round of funding came through. This is going to be a good weekend. HTML5 has the technologies you need to make your idea for a Web-based massive multi-player game take off. Hardware-accelerated gaming in a browser is real and you're going to lead the way. Until Monday, when you find that all the tests you'd already done, and all the demos you've staged, no longer matter. Your website crashes, the game freezes and there's nothing obvious you can do to bring it back. What Happened to the WebSockets?This story is a true one. It happened already to several teams that depend on the WebSocket protocol. How could things go so wrong? What protection can Web developers put in place to prevent being "burned" this way? The short answer: constant vigilance. The WebSocket situation is more involved than any few-word explanation like, "he ran a red light" or "they didn't do back-ups." Like most real-world dramas, many factors came together to create the WebSocket situation:
The only insurance you have is to be aware of the changes that occur with unstable standards (and invest the time to support them). To see why there's no easy systematic fix, we need clarity about what HTML5 is, WebSocket's position within HTML5, and how standard-based development itself is evolving. HTML5 and Application DevelopmentHTML5 has significantly more potential than its predecessors. In the past, "Web Application" generally involved something no more sophisticated than a data-entry form like a college entrance examination or a tax return. Previous incarnations of Web standards went by several titles, including HTML4; they brought us to roughly the point that that made search engines, the cloud and the rest of Web 2.0 become possible. HTML5, in contrast, is a collection of technologies that are emerging with varying degrees of stability. These range from hardware-accelerated graphics, audio, and video that can make a Web game feel like a native application to a mundane (but a highly valuable) approach to database standards like IndexedDB. The Web is still the platform to reach the most people possible for relatively low cost. HTML5, in broad terms, will be the set of standards that make networked application development feasible across a range of platforms and devices. All the devices you use -- phones, game consoles, automobiles, TVs, point-of-sale installations, household appliances and more -- have the realistic potential to fulfill a single set of standards. That's quite an achievement for a set of technologies that are just emerging! It is also not a single coherent definition or document like, say, HTTP1.1 (and we should recognize that even that rather well-controlled topic was published in seven distinct parts). HTML5 won't be completely finished for at least a few years more. So how do web developers take advantage of these technologies at varying levels of readiness? How do browsers play a role in supporting HTML5 standards with developers in mind? Speed of Innovation vs. Spec StabilityThe key actors behind HTML5 could make it "tight" -- more coherent, integrated and internally consistent. It would be more trustworthy and blemish-free. That would appear to make our choices as developers simpler. Such an alternate-reality HTML5 would probably have taken an extra decade, and been unused on release. The real choice is not between a high- and low-quality standard; it's how best to balance flexibility and reliability in standardization. Moreover, when the standard lags too much, clever developers create their own techniques for solving their real problems, and further muddying the engineering landscape. The HTML5 sponsors did the right thing in modularizing the standard and its process. Parts of HTML5 are fairly well understood and noncontroversial; they just needed standardization, and a few of them have been usable in Web browsers for more than five years already. Other parts are more difficult, including the WebSocket protocol. Understand that "difficulty" here isn't a euphemism for "written by people acting in bad faith" or "subject to an evil conspiracy." The problems HTML5 addresses are hard ones that demand careful design and engineering. Occasionally, with the best of intentions and even plenty of intense meetings, mistakes are made. The Role of BrowsersBrowsers 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. So how do developers decide what to support when browser vendors disagree? For the foreseeable future, thinking of it in terms of "does browser B support HTML5?" simply won't make much sense; the pertinent question will be more along the lines of, "how well does a particular version of B support the particular version and parts of HTML5 that our implementation requires?" We should think of "support" here as the character or attitude of the browser rather than a particular feature, like a checkbox in a table. Suppose, for instance, that your application focuses on scheduling. The new datetime input datatypes are crucial to you. You need to analyze clearly which browser releases give you the input behavior you're after -- but you equally need to know how the browser providers decided on those behaviors, and therefore what the different browsers are likely to do as standards continue to develop. You also need to determine how whether you want to add support for something that will continue to change and likely break your web experience at times. WebSockets: An Unstable Spec Case StudyLet’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 BalanceThe lesson of WebSockets, then, is not to retreat and give up on HTML5. Instead, we should take these steps:
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 AuthorCameron Lairdis an experienced developer who has written hundreds ofarticleson programming techniques. He's particularly enthusiastic aboutHTML5; keep up with him throughTwitter. |