The web started birth with very much a “click and wait” experience. Any interaction with the server meant a round trip of data across a slow line and ended up with a page refresh. In the Web 2.0 era things changed dramatically with the exploitation of an API: XMLHttpRequest the foundation of a framework called Ajax.
With Ajax web pages could now interact with the server without page refreshes. This was transformational, and especially as bandwidth speeds increased people got very inventive with Ajax and created applications that started to feel much more like desktop applications.
Whilst this created a massive step forward developers were still having to create proprietary approaches, sometimes using plugins, for other forms of communications with the server. Ajax allowed the client to call the server, what about the other way round?
And further still how about a server sending a message to multiple clients – either on the same machine but in different windows or indeed to multiple physical clients?
Step forward HTML5 which brings a number of new capabilities for communication. There are plenty of resources that provide tutorials on how to use these new features, the focus of this blog is just to raise awareness of the features and the possibilities they present.
Cross Domain Messaging is one of my favourite features of HTML5 and worthy of it’s own separate article, which I will do in my next post. Essentially Cross Domain Messaging allows you to send messages between separate applications running in separate iFrames, Tabs or even browser windows. It is facilitated by the existing PostMessage api (see next post for more details).
XMLHttpRequest has also been upgraded to support Cross Document Messaging. This now means that an application can communicate with multiple servers. For example imajine a News page that contains an article about Japan, the page may have separate sections containing local weather and currency rate updates.
Previously the page would have been built up with content from different sites at the server end, now it is possible to do this from the client. A further enhancement to XMLHttpRequest is the addition of Progress Events. Previously when a request was made to the server there was only the “readstatechange” event, which was limited and no implemented consistently across browsers.
Now there are several more meaningful and useful events (loadstart, progress, abort, error, load, loadend) that can be processed
Another constraint the web has faced has been the ability for servers to send messages to clients. The most common example being stock markets feeds. Typically developers have created a polling mechanism to get updates from the server at regular intervals most likely using XMLHttpRequest. This creates unnecessary load and traffic to the server.
HTML5 also introduces the concept of Server Sent messages using the EventSource interface. This is basically a publish and subscribe approach: the client subscribes to a message event source, and the server code publishes messages to those subscribers.
XMLHttpRequest and Server Sent Messages are uni-directional messages, but what if you need bi-directional messages: the ability for either the client or server to send/recieve messages? Well HTML5 also has an answer for that with WebSockets (note it is possible to achieve bi-directional messaging without WebSockets, but it is much more difficult, unreliable and network inefficient)
WebSockets is a large topic, however the key point to be made here is that it is a more efficient and standard mechanism for enabling bi-directional messaging. The first step in the process is establishing a handshake between the client and server, this is done by upgrading from http protocol to the websocket protocol.
Where websocket communication provides a significant advantage is that once the handshake is established, communication between client and server is free from the heavy load of http headers! Http headers can reach 2k in size, which is a massive overhead if the message is only 10 bytes.
When you compare this to applications that have implemented a polling approach you can see that WebSockets are not only more efficient in message size but can significantly reduce unnecessary traffic created by polling and reduce latency of updates (created by the polling time).
Using WebSockets today does require a server of which there are many available, and of course like all HTML5 features browser support varies and hence needs to be checked.
This post aimed to key you a flavour of some of the key new features that enable web applications to become more chatty and in doing so not only make applications faster, efficient but richer and more dynamic than we have been used to. I believe just these features alone could drive a new generation of web applications across many industries like gaming and financial services. Could this be Web 4.0?