(For more resources related to this topic, see here.)

WebSockets define a persistent two-way communication between web servers and web clients, meaning that both parties can exchange message data at the same time. WebSockets introduce true concurrency, they are optimized for high performance, and result in much more responsive and rich web applications.

The following diagram shows a server handshake with multiple clients:

For the record, the WebSocket protocol has been standardized by the Internet Engineering Task Force (IETF) and the WebSocket API for web browsers is currently being standardized by the World Wide Web Consortium (W3C)— yes, it’s a work in progress. No, you do not need to worry about enormous changes, as the current specification has been published as “proposed standard”.

Life before WebSocket

Before diving into the WebSockets’ world, let’s have a look at the existing techniques used for bidirectional communication between servers and clients.

Polling

Web engineers initially dealt with the issue using a technique called polling. Polling is a synchronous method (that is, no concurrency) that performs periodic requests, regardless whether data exists for transmission. The client makes consecutive requests after a specified time interval. Each time, the server responds with the available data or with a proper warning message.

Though polling “just works”, it is easy to understand that this method is overkill for most situations and extremely resource consuming for modern web apps.

Long polling

Long polling is a similar technique where, as its name indicates, the client opens a connection and the server keeps the connection active until some data is fetched or a timeout occurs. The client can then start over and perform a sequential request. Long polling is a performance improvement over polling, but the constant requests might slow down the process.

Streaming

Streaming seemed like the best option for real-time data transmission. When using streaming, the client performs a request and the server keeps the connection open indefinitely, fetching new data when ready. Although this is a big improvement, streaming still includes HTTP headers, which increase file size and cause unnecessary delays.

Postback and AJAX

The web has been built around the HTTP request-response model. HTTP is a stateless protocol, meaning that the communication between two parts consists of independent pairs of requests and responses. In plain words, the client asks the server for some information, the server responds with the proper HTML document and the page is refreshed (that’s actually called a postback). Nothing happens in between, until a new action is performed (such as the click of a button or a selection from a drop-down menu). Any page load is followed by an annoying)(in terms of user experience) flickering effect.

It was not until 2005 that the postback flickering was bypassed thanks to Asynchronous JavaScript and XML (AJAX). AJAX is based on the JavaScript’s XmlHttpRequest Object and allows asynchronous execution of JavaScript code without interfering with the rest of the user interface. Instead of reloading the whole page, AJAX sends and receives back only a portion of the web page.

Imagine you are using Facebook and want to post a comment on your Timeline. You type a status update in the proper text field, hit Enter and…voila! Your comment is automatically published without a single page load. Unless Facebook used AJAX, the browser would need to refresh the whole page in order to display your new status.

AJAX, accompanied with popular JavaScript libraries such as jQuery, has strongly improved the end user experience and is widely considered as a must-have attribute for every website. It was only after AJAX that JavaScript became a respectable programming language, instead of being thought of as a necessary evil.

But it’s still not enough. Long polling is a useful technique that makes it seem like your browser maintains a persistent connection, while the truth is that the client makes continuous calls! This might be extremely resource-intensive, especially in mobile devices, where speed and data size really matter.

All of the methods previously described provide real-time bidirectional communication, but have three obvious disadvantages in comparison with WebSockets:

• They send HTTP headers, making the total file size larger
• The communication type is half duplex, meaning that each party (client/server) must wait for the other one to finish
• The web server consumes more resources

The postback world seems like a walkie-talkie—you need to wait for the other guy to finish speaking (half-duplex). In the WebSocket world, the participants can speak concurrently (full-duplex)!

The web was initially built for displaying text documents, but think how it is used today. We display multimedia content, add location capabilities, accomplish complex tasks and, hence, transmit data different than text. AJAX and browser plugins such as Flash are all great, but a more native way of doing things is required. The way we use the web nowadays bears the need for a holistic new application development framework.

Then came HTML5

HTML5 makes a huge, yet justifiable, buzz nowadays as it introduces vital solutions to the problems discussed previously. If you are already familiar with HTML5, feel free to skip this section and move on.

HTML5 is a robust framework for developing and designing web applications.

HTML5 is not just a new markup or some new styling selectors, neither is it a new programming language. HTML5 stands for a collection of technologies, programming languages and tools, each of which has a discrete role and all of these together accomplish a specific task—that is, to build rich web apps for any kind of device.

The main HTML5 pillars include Markup, CSS3, and JavaScript APIs, together.

The following diagram shows HTML5 components:

Here are the dominant members of the HTML5 family. As this book does not cover the whole set of HTML5, I suggest you visit html5rocks.com and get started with hands-on examples and demos.

Although Storage and Connectivity are supposed to be the most advanced topics, you do not need to worry if you are not an experienced web developer. Moreover, managing WebSockets via the HTML5 API is pretty simple to grasp, so take a deep breath and dive in with no fear.

Summary

This article has helped you understand the basics of WebSocket. It also helped you get an overview of life before WebSocket. It explained Postback and AJAX and then explained the topic of HTML5

Resources for Article:

Further resources on this subject:

• Building HTML5 Pages from Scratch [Article]
• Basic use of Local Storage [Article]
• Scalability, Limitations, and Effects [Article]