Websockets and the real-time web, part I

Link to Part II of the Article [The server side]: http://ruminationsontechnology.blogspot.com/2014/10/preview-websockets-and-real-time-web.html

Link to Part III of the Article [The Client Side]: http://ruminationsontechnology.blogspot.com/2014/10/websockets-and-real-time-web-part-iii.html

 
Let us start with bit of history...

The basic motivation behind websockets is not new, ever since the use of the web went viral we have attempted to build the ultimate mechanism to push information to the users on real-time, without requiring them to repeatedly hit the refresh/reload button in their web browsers.

I can agree with the thought that a billion users worldwide reloading the content of their web browsers in a continuum can seem a bit Orwellian, a little barbaric and even ridiculous, but that is basically what many of the pseudo-real-time-web solutions do, only that they do it via some HTML or JavaScript-based mechanism on behalf of their human masters, among those techniques I could mention ajax, comet and the infamous meta refresh tag.

The problem is not that the creators of these technologies were unprepared for the task at hand or that they lacked imagination, or even that HTTP is a static, stateless, client-controlled request-response protocol.

The problem is that we humans are never satisfied with whatever new toy we are presented with, we need to bend it, jailbreak it, disassemble it, break it, fix it, over-clock it, tune it up, overhaul it, and, ultimately, attempt to use it in ways that the poor and now doomed toy was never intended or designed to be used. And that, my dear reader, is the basis of all innovation since the dawn of our species. But I digress...

Over time, a few techniques and technologies were developed to help solve the problem in a more elegant way, those usually involved piggybacking some external technology on the web browser via plug-ins such as Adobe Flash, Java Applets or using proprietary browser technologies, but none of them became the universal de-facto standard, with Adobe Flash being the one that came closest to claiming that prize.

A few years ago, around 2009, work began on a new way of realizing the elusive goal of having a standards-defined, universally-supported and lightweight technology that allowed full-duplex communication over a single TCP socket. That work, over a few iterations, spawned RFC 6455, better known as the definition for The Websocket Protocol.

So now that you have a shiny spanking new and well supported standard, is it time to rewrite every single web app ever written to use websockets.? Well as is the case with mostly everything web, the answer is: it depends. Some applications will surely benefit from this new technology, for others, it will be hardly noticeable, moreover, the websockets standard is not alone in the race for the ultimate real-time solution for the web as we know it, lower level protocols such as SCTP, BEEP and Google's SPDY are being developed and evolved as you read these lines and could spell a short reign for websockets, or maybe not.

What are you planning to do (or have already done) on real-time?

Street Lamp at San Cristobal de La Laguna, Tenerife.

Photo Credit: Paulo Márquez Herrero
[Coming Soon: Websockets and the real-time web, part II (let us code) ]
PM/pm