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 onare 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'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:/ 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's folks were on top of it). Sometime around 2006 / COMET was introduced. Here is what it would look like:
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 thatcame 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.
- 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:
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.
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).
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 fromon 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:
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:
- Withbased 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.
- In my scenario one time we kept some of the Long Polling in house solutions alive.
- Slowly move to Websocket, knowing that it's not going to be the ultra loaded side of the service.
- Using alternative solutions that have been built on things like"
- One famous implementation of it is called:
- 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:
- : site , perhaps their CTO can shed the light here.
- : site , perhaps some folks over can tell us more as well.
Bigger scale and control over lower layers of the app:
- (I love this, I use it in some Analytics)
awesome article about this:
OR (this is a big or here notice:)
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 ator or Nowadays 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 / .
On Quora I answered another question around a similar topic:
Which might be relevant somehow here to explain the other pieces not mentioned in detail.
,(The Architect behind the legendary
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.