The Brave New World of HTML5
[Home of the HTML5 Car]

Since this blog introduced the invention of the HTML5 car you might expect that we stress this analogy again. Imagine you bought a new car. In the users manual you find the following hint: “In case you are interested in the power but don’t want to drive you can easily isolate the engine and use it for whatever purpose you like.” You might be surprised. Not only that the pure power might be dangerous. In order to make it useful you will need to have something that you can drive with this power.

If HTML5 (based on HTTP) is the car then TCP/IP can be seen as the engine. And HTML5 provides you access to the engine. It allows using TCP plain – without the HTTP around it. And as with the car engine you can only make use of it if there is a counterpart that can consume and react on what is produced. The API that provides this to you is called WebSockets.

So what can WebSockets do for you? They allow your Web application to send and receive messages. Without the HTTP headers that usually are required when you send or receive data on the Web. Normally when communicating with your Web server HTTP request headers provide the information needed to tell the server what you are sending and what you would expect in return. And HTTP response headers inform your browser about if and how the request was fulfilled and what data is sent in return. The world wide agreement on what HTTP headers mean and how they should be handled keeps the Web alive. Any Browser can talk to any Server as long as both sides follow the rules.

But for certain applications HTTP has some trade-offs. One is that HTTP is stateless by design. Once a server has replied a request it forgets everything about it. It is fire and forget. A next request cannot relate to a previous one by any means. (The are techniques to store some state on the client side – most popular are cookies. But this is information that has to be sent to the server with each request, because the server is not able to relate two requests to each other.) With Websockets Client and Server can have a “Dialog”. Each of them can store connection related information and send and receive messages at any time.

Another tradeoff of HTTP can be that headers typically have a size of 200-500 bytes (+ ~40 bytes for TCP/IP headers). Which does not seem to be much. But if your application requires in the quick exchange of short messages it can make a difference. AJAX which often is used for emulating state-full conversations with a server makes this even worse: all information about the state of a conversation has to be carried forth and back with the messages between client and server – because only the client has a means to store the state between messages.

Of cause there is a downside of Websockets. Why would HTTP otherwise have been invented on top of TCP/IP? HTTP is a simple approach to send documents, parts of documents, results of queries. Developers don’t have to spend much time thinking about maintenance of connections and the error handling is pretty simple. You don’t have to worry about a protocol – the rules (e.g. syntax and semantics) of your message exchange with the server. This was what caused much of the success of the Web. With nearly no effort you can do a lot. So it would be definitely a bad idea to head for Websockets for each and every of your applications.

Websockets can easily be used by means of a Javascript API. It mainly provides a simple mechanism to open and close connections, a send function, to send messages to the server and an onmessage event to become aware of messages from the server.

What are Server Sent Events in this context? Server Sent Events are HTTP in essence. But they allow a server to stretch its answer to a request over time. Server Sent Events allow a client to open an EventSource by means of an HTTP request. This allows the server to send multiple messages and trigger events as response to a request over a long time till the EventSource is closed. Server Sent Events use a mime type text/event-stream by which the server can sent data and trigger events on the client. Server Sent Events may be a good alternative to Websockets in cases where data has to be sent by a server over time (e.g. measurements) because they avoid most the HTTP overhead without the need to implement a new application protocol.