What’s your opinion about WebSockets and using it in production over XHR and more folklore strategies?

Answer by Yad Faeq:

To answer your question and avoid any biases or wrong suggestions I will walk through each of those technologies that relate to the topic, then explain what I think of them, including XHR:

First let's start with what we have come along to since early days of Web, otherwise my comment on WebSockets are going to sound like am grilling it:

  • Web started static, let's say around 1995 people / majority of public got on. CGI was used perhaps to generate some content.
  • Then around 2005, Ajax came along. Remember those little tiny cool things on Yahoo! (company)'s front page? It was to change the content without the user refreshing the page. Content getting exchanged in the background.
  • Then somewhere around 2006 more improvement of Ajax + Http came along:
    / XMLHttpRequest: thread in the background running while user is making interactions with the page.

  • There are instant improvement on these technologies from different communities that work on them (at that time Oracle (company)'s folks were on top of it). Sometime around 2006 Long Polling / COMET was introduced. Here is what it would look like:

    Another scenario:

    OR this cluster mess when PHP was in the arena at that time:

  • It's an illusion of the actual feature not the actual feature working, and the feature being instant update (real-time).
    Technically the connection is hold for a little more time to wait for the next event.
  • I can say that HTTP Streaming came around afterward, but not so common by this time. The response body was never closed after sending the event. This was cool, since it brought application level into the game. However, the magic difference technically was something like this:


    HTTP Streaming would force:

  •   The state of many web applications is inherently volatile.  Changes can come from numerous sources, such as other users, external  news and data, results of complex calculations, triggers based on the  current time and date.
  • HTTP requests can only emerge from the client. When a state  change occurs, there's no way for a server to open connections to  interested clients.
    src:  HTTP Streaming – Ajax Patterns
  • Server Sent Events was introduced to start over clean and bring the nitizens of world together. But it was technically an open technology on it's own, rather than using a specific Framework to perform and make it happen. This is what it looks  like in work:
  • Or:

Now, most of the above ways had issues such as: timeouts due to heavier requests. Some routers / networks wouldn't let partial responses to be sent or data buffering over the network bandwidth. There were / are hundreds of hacks to fix and patch issues with the above ways to achieve live updates, yet not the ideal.

  • Around 2010 and the following years till 2013, late 2012 WebSockets was introduced from different projects and communities.

    RFC 6455 – The WebSocket Protocol
       The WebSocket Protocol enables two-way communication between a client    running untrusted code in a controlled environment to a remote host    that has opted-in to communications from that code.  The security    model used for this is the origin-based security model commonly used    by web browsers.  The protocol consists of an opening handshake    followed by basic message framing, layered over TCP.  The goal of    this technology is to provide a mechanism for browser-based    applications that need two-way communication with servers that does    not rely on opening multiple HTTP connections (e.g., using    XMLHttpRequest or <iframe>s and long polling).

    WebSockets were better from COMET and some earlier methods in regards of upstream, but still can't do full streaming. In websockets, TCP's support was all in, fully controlled. This was possible earlier with Applets, but I guess not too adaptable, hence WB became that standard every client says I want to talk on to when the web services called.

    The TCP opens the connection up, and HTTP starts playing around, this was the jam at this point.

    Now for, Websockets VS it's earlier cousin HTTP streaming. Here is an awesome comparison from Alex Recarey on Stack Overflow explaining it in this way:

    • Websockets and SSE (Server Sent Events) are both capable of pushing  data to browsers, however they are not competing technologies.
    • Websockets connections can both send data to the browser and receive  data from the browser. A good example of an application that could use  websockets is a chat application.
    • SSE connections can only push data to the browser. Online stock  quotes, or twitters updating timeline or feed are good examples of an  application that could benefit from SSE.
    • In practice since everything that can be done with SSE can also be  done with Websockets, Websockets is getting a lot more attention and  love, and many more browsers support Websockets than SSE.

    However, it can be overkill for some types of application, and the  backend could be easier to implement with a protocol such as SSE.

    I don't want to copy the rest, but read the answer here:

    Source: WebSockets vs. Server-Sent events/EventSource

I can say for sure that the different attempts on Ajax Push approaches set the foundation for WebSockets soon with HTML5. Now, I don't want to go deeper for what have been better and what not. Since, there are lots of tension (biases) at least to my understanding in between supporting which technology and which not to let the sun shine on them. One major bottleneck is that few key players among startups / companies might bash the other, sometimes the joke becomes real and actually the technology runs out of support, hence it dies slowly and gracefully in between the server /\ client.

Here is what I can tell you have been a good practice for me:

  • With REST based web apps there are already too much to deal with when the codebase grows. Brining another layer of complexity can mess things up if the team is not that big, budget is low, if the project is going to have a major reshape and such.
    1. In my scenario one time we kept some of the Long Polling in house solutions alive.
    2. Slowly move to Websocket, knowing that it's not going to be the ultra loaded side of the service.
    3. Using alternative solutions that have been built on things like "The Bayeux Protocol"
      • One famous implementation of it is called: Faye

      Authored by James Coglan

  • Perhaps looking into new solutions from the Application layer would be good idea (improve web apps to overcame the connection issues).

In case if this was too much to deal with, there are solutions that offer quite a huge amount of requests for free and to test out, here are some of them:


Bigger scale and control over lower layers of the app:

OR (this is a big or here notice:)
Google Cloud: Architecture: Real Time Stream Processing – Internet of Things:

More: on Real-time Gaming with Node.js + WebSocket on Google Cloud Platform

Just don't get stuck in the middle of building product and realizing the technology you chose is not fitting at all. Best way to look at it as I mentioned before asking questions like:

  • $$, Budget around the project?
  • Human cap, how much the team can get done?
  • Smooth transitions, how to build web apps that can have loose coupling and ability to be changed over time?
  • Community and support around the technology?
  • What does the folks at Google Products and Services or Facebook or Nowadays Amazon Web Services think about it?

I skipped a lot in the timeline to reach the WB topic, otherwise during that time there were other things offered (still), such as Wsdl / SOAP (Simple Object Access Protocol).

On Quora I answered another question around a similar topic:
Yad's answer to What are the technical challenges of building a realtime messaging platform?
Which might be relevant somehow here to explain the other pieces not mentioned in detail.

Harold Carr ,(The Architect behind the legendary SOAP),
gave an awesome talk back in 2013 around all of this, I would highly recommend it if you are interested to learn more:


Feel free to suggest any corrections, because I've most probably missed few things if not a bunch here.

What's your opinion about WebSockets and using it in production over XHR and more folklore strategies?


Leave a comment

Filed under Life

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s