At the Forge - Communication in HTML5

HTML5 gives Web applications new communication features.

One of the greatest contributions of UCB (Berkeley) to the UNIX operating system was the introduction of sockets. Sockets allowed programmers to open a connection to another computer easily and quickly. Once opened, the socket operated something like a point-to-point file handle, allowing you to ignore the fact that data in the socket was being transmitted through dozens or hundreds of other computers. A large number of Internet services, from SMTP to FTP to HTTP, use sockets. I personally have used them for nearly 20 years to implement everything from my undergraduate thesis, to Web browsers and servers, to various Internet-enabled applications.

HTML5 brings socket-like connections to the browser, using a technology called WebSockets. WebSockets are similar in principle to UNIX sockets, in that you can open a connection to an arbitrary other point on the Internet, and send and receive data reliably without even considering the numerous hops or connections along the way.

Now, if you are an experienced Web developer, you might be wondering what the big deal is. After all, Ajax calls allow you to open HTTP connections and send and receive data. And xhr (the XmlHttpRequest function) has been around for a few years, and it works quite well. The difference is WebSockets will allow you to open one or more connections to anywhere on the Internet, not just to servers with the same origin as the current page. Moreover, WebSockets use their own protocol that is admittedly quite similar to HTTP, but it has a great deal less overhead. Finally, WebSockets remain open as long as the sides agree to do so—as opposed to HTTP, which is meant to be stateless and to be closed after a single request-response transaction. For all these reasons, communication using WebSockets generally is going to be far more efficient. A number of articles describing WebSockets have done the math and show just how much more efficient WebSockets are than HTTP—and the difference is staggering.

Working with WebSockets is remarkably simple. You open a WebSocket with some JavaScript code, often (presumably) fired either when a user performs an action (such as pressing a button) or when a certain event takes place (for example, a certain amount of time has elapsed). No matter what, you open a new WebSocket by specifying the URI to which you want to connect, starting with a protocol name (either ws or wss, for unencrypted or encrypted, respectively), continuing with the hostname, and then ending with a resource name.

Once the WebSocket is open, you can attach callbacks to it, indicating what should happen when the socket is opened, closed or receives a message. (Each time the WebSocket receives data from the remote host, it will invoke the “onmessage” callback function.)

For example, here's a simple WebSocket that retrieves data from a hypothetical weather server:

var weatherSocket = new WebSocket("ws://localhost:8080"); 
 ↪// Our own weather server

Then, you can assign callbacks:

weatherSocket.onopen = function(e) {
alert("Opened weather socket");

weatherSocket.onmessage = function(e) {
alert("Received a message: " +;

weatherSocket.onclose = function(e) {
alert("Closing the weather socket...");

Finally, you can send messages by invoking the send() method—yes, the same method that you saw above, but without the second parameter indicating the origin.

Notice that although you write directly to the WebSocket using send, you don't read a result directly from it or via a return value to send(). Rather, you will get the data when it is sent to you, via the execution of your method at weatherSocket.onmessage().

One piece is missing from this description, namely a server to which the WebSocket connects. You cannot connect to just any old server on the other end, and especially not to an HTTP server. Fortunately, a growing number of packages (in various open-source languages) can handle the server side of WebSockets. One such package is the em-websocket gem for Ruby, based on the well-known eventmachine gem. WebSocket server libraries already exist for PHP and Python, as well as a number of other languages. Over time, I expect to see a number of WebSocket-compatible servers emerge.

How can you use WebSockets? As with interwindow communication, I expect the best applications and ideas haven't been developed yet. But once your Web browser can connect to any host on the Internet using a specialized high-performance protocol, you can imagine that the sky is the limit. Suddenly, Web-based chat servers no longer need to use kludges or hacks in order to allow for real-time chat. You can create mashups on the client, rather than the server. Combined with the new geolocation facilities in HTML5, you can have a map that updates your location in real time, using nothing more than HTML and JavaScript. It does mean that on the server side, Web applications now will require more than just installing Apache, but that has been true for a while now, as applications have become more sophisticated, so I don't think you need to worry about that too much.