What is the difference between Forever-frame and server sent events?

Question

This question is really similar with this question:What is the difference between web sockets, long polling, server-sent events and forever frame?

However, this question's answer doesn't mention the difference between SSE and Forever-frame.
Let me give you brief explanation about them.

Regarding to SSE, the system really resembles Comet, but the point which is different with Comet is not breaking the connection after data being sent. So, connection from a server to a client is long-alive and the client receives series of fragments of a whole data.

On the other hand, forever frame seems to be very similar to me. In Forever frame, first the client receives the page including an iframe tag, establishing a long-lived connection inside the hidden iframe. And then the client receives chunked datas from the server and manipulates the DOM with some functions on the first document the client already has.

I assume the difference is Forever-frame uses iframe tag in the mechanism, but SSE doesn't and SSE can be realized by more ways. Am I right?

Answer 1

I'd not heard of Forever-frame by that name before! (It is covered in ch.7 of my book, Data Push Apps with HTML5 SSE, in the "iframe" section).

Long-polling: make a request (using XMLHttpRequest, i.e. ajax), keep it open until the data is ready on the server. Then the socket closes. Re-connect to get the next bit of data.

XHR polling: make a request (using XMLHttpRequest2, i.e. ajax), but listen in to the readyState==3 signals. The back-end server has to know to keep the connection open, and the client has to know to listen to readyState==3. (Does not work in IE9 and earlier, because that browser never delivers the readyState==3 messages, but goes straight to readyState==4)

iframe: open a hidden iframe to the back-end process. Regularly go look at the source code of the iframe, and see if anything new is there. (Technically it works on all browsers, but IE8 and IE9 were the only ones in my (2013) tests with low enough latency for the updates to be useful.)

SSE: An HTML5 standard that basically works like XHR polling (Firefox and Chrome, at least, implement it directly on top of XMLHttpRequest2), but with the complex details hidden from you. It also adds auto-reconnect if the socket goes down, and a few other high-level features like that.

At the end of chapter 7 of the afore-mentioned book, I show code to get all the techniques to work in just about any browser. The order of preference is:

• SSE if available
• else XHR if available
• else iframe if IE8 or IE9
• else longpoll

There is one other difference: the XHR and iframe techniques are storing the entire message history in memory. So, if you intend to keep the socket open for a long time and/or send a lot of large messages, this may cause a memory issue that wouldn't happen with SSE.

Executive Summary: Don't worry about "forever-frame" unless you have enough customers still using IE8/IE9 that the longpoll approach would create noticeable additional load on your infrastructure.