HTML 5, The Future is Now!

During the last 5 years, we have seen the birth of Ajax — the term, not the techniques — and its evolution to include Comet, a variety of clever workarounds that allow any modern browser to receive new information from the Web server, but without having to flood the network with HTTP requests.  We have also seen innovation from the Dojo Foundation and others in an attempt to define a standard wire protocol for Comet, called Bayeux.  More applications than ever before are deploying Comet, including Meebo, embedded GTalk and Facebook, each with their own internally-defined wire protocol.

Now W3C is defining the HTML 5 standard, which promises to raise the bar for the modern Web browser, turning it into a fully capable rich Internet application client platform.  The most important Comet-related enhancements defined by HTML 5 are called Server-sent Events and WebSockets.

HTML 5 Server-sent Events (SSE) standardizes Comet for all browsers, eliminating the need for those clever workarounds that make the task of writing both Comet clients and Comet servers so challenging.  Instead, SSE allows the browser to send an HTTP GET request to the server, and defines the syntax of the response payload that is used to stream events from the Web server to the HTML 5 compliant browser.  Each event is described using a line-based syntax, with an optional event type (defaults to “message”), an optional id (used to track progress through the event stream), and the data which describes the actual event payload, such as “Hello, world” shown below.  An empty line marks the separation between events in the stream.

event: message\n
id: 101\n
data: Hello, world\n
\n

The HTML 5 DOM introduces a new element, called “eventsource” that is used to co-ordinate access to one or more SSE event streams.  Setting the source on an eventsource element triggers the HTTP GET request described above.  Adding an event listener to the eventsource element allows the application to receive events in JavaScript as they arrive at the browser.

<eventsource src="http://www.example.org/server-sent-events"
             onmessage="alert(event.data);" >

If connectivity is broken between the Web server and browser, then the eventsource element automatically attempts to reconnect, informing the Web server of its progress through the stream to avoid receiving duplicate events.

However, simply standardizing Comet is not sufficient to satisfy the networking requirements of a fully capable rich Internet application platform, because we also need full-duplex bidirectional communication, just like traditional desktop applications already enjoy today.  To address this requirement, HTML 5 standardizes WebSocket, which integrates with the existing HTTP infrastructure of the Web to complete its handshake with the WebSocket server, and then switches protocols (on the same TCP connection as the initial HTTP-based handshake) to remove the undesirable half-duplex nature of HTTP from further communication.

The WebSocket JavaScript API provides the equivalent of a desktop style TCP connection, limited to text-based payloads for now, because JavaScript does not yet have a byte or ByteArray type.  The WebSocket wire protocol itself can represent either binary or text payloads, so languages other than JavaScript that do have a binary representation can choose to send binary data to a WebSocket server in the raw, rather than having to encode the binary data as text.

var socket = new WebSocket("ws://www.example.org/web-socket");
socket.onopen = function(event) { alert("socket opened");
                                  socket.postMessage("Hello, world"); }
socket.onread = function(event) { alert(event.data); }
socket.onclosed = function(event) { alert("socket closed"); }

WebSockets represent a revolution for rich Internet applications, because they enable socket-based access to back-end services.  For example, with WebSocket, a JavaScript implementation of the XMPP protocol (used by desktop GTalk for chat), a suitable WebSocket gateway server, and any off-the-shelf XMPP-compliant server, you can develop a Web-based chat solution in short order, focusing primarily on the user experience.  Naturally, the scope of WebSocket is not limited to XMPP, in fact any TCP-based protocol is feasible to implement over WebSocket.

The world of HTML 5 Server-sent Events and WebSockets certainly seems exciting, but when will browsers implement it, and how should we prepare?  The HTML 5 specification is scheduled for completion in 2022 (!) although the Server-sent Events and WebSocket sections seem more stabilized than others and will likely be implemented in modern browsers much sooner than that. But even if all the modern browsers would implement these standards today, there would still be an issue of backwards compatibility for folks using older browsers, futher increasing the burden on developers to support such varying browser capabilities.

Fortunately, it turns out to be possible to emulate both HTML 5 Server-sent Events and WebSockets in all the modern browsers today using Comet.  The Orbited open-source project provides something similar to WebSocket called TcpSocket, and Kaazing provides emulation of HTML 5 Server-sent Events and WebSockets in both open-source and commercially supported solutions.  Working with APIs that closely emulate the HTML 5 standard today will allow those Web applications to seemlessly fall forward onto the native browser implementations as they become available. This should also help to stimulate futher interest in the HTML 5 specification itself, hopefully leading to an earlier completion date!

If you would like to find out more about how you can start building your future Web applications today, please join us for an intriguing panel discussion at the Chronicles of Web Standard: the HTML 5, the Comet and the WebSocket.

John Fallows