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 potential for “cross-layer” security exploits due to lack of testing
- A highly unpredictable path for how technologies evolve across standards organizations
- The role of browsers and browser vendors that support standards
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 Development
HTML5 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 Stability
The 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.
