HTML5 provides an overwhelming variety of communication methods. Let’s map them out.

By “overwhelming”, I don’t mean “poorly-designed” or “unusable”; I just mean that Web developers and network operators have relatively little experience in the full range of facilities modern browsers embed, and it’s easy for all the novelties to disorient all but the specialist. More programmers appear to have used AJAX, for instance, than can explain when it’s appropriate. This makes it a good time for a quick, high-level, and focused catalogue.

Architecturally, the Web’s original “pull” demand-response dialogue Tim Berners-Lee defined more than two decades ago remains the most important HTTP channel. It was only rather recently, during 2000-2006, that the major browsers standardized even XMLHttpRequest (the basis of so-called AJAX) as a basis for “push” and other communications models. Before this, the only effective alternative to retrieve more information without a page refresh was custom coding in Java.

HTML5 dramatically alters the landscape. This is in part because HTML5 itself is so sprawling: it has many parts, and several of them involve programmable networking.

Web Sockets slash the latency inherent in XMLHttpRequest; game authors have healthy appetites to try Web Sockets because, at their best, they’re far faster than XMLHttpRequest-based codings. Web Sockets aren’t as widely-supported yet, however; that’s the main impediment to their use.

Cross-site scripting has been, of course, a considerable security hazard for most of the history of the Web. The principal defense against it is browsers’ enforcement of “same-origin” policies. HTTP, XMLHttpRequest, and Web Sockets all default to same-origin restrictions. These policies ensure that Web pages only receive information presumed to be under the control of the authors of the Web pages. Web Messaging doesn’t default to a same-origin policy; instead, its security comes from co-operation. Both sender and receiver must name each other.

There will eventually be minor alternatives to these; the HTML5 File API might, for instance, be combined in specialized circumstances with external filesystem mounts, as a communication method. The Messaging API or Web SQL definitions have similar potential for communication with a special-purpose transceiver. XMLHttpRequest, Web Messaging, and Web Sockets, though, will form the foundation of communications in applications for years to come.

The most interesting of these applications will, of course, have major communication components. Whether your own role is in design, coding, or operations, keep in mind the important generalizations: Web Sockets are fast, Web Messages operate between domains, and XMLHttpRequest is best supported by tools.