Downside of using Server-Sent events for bidirectional client-server communication (instead of WebSockets)

Question

Recently I\'ve found out of Server-Sent events as a much simpler alternative to WebSockets for doing push from the server. Most places that compare them (like here, here and her

Answer 1

SSE Advantages over WebSockets:

• No special web server or web proxy changes required.
• Define custom events (otherwise, client API is basically the same)
• Easier integration of existing authentication mechanisms (OAuth, OpenID, etc)

SSE Disadvantages compared to WebSockets:

• Unidirectional communication channel (server to client). Client to server requires a separate channel.
• Browser support is more limited (no native IE support whereas WebSockets is supported in IE 10): WebSockets, SSE
• Relies on client to verify origin (possibly more vulnerable to XSS attacks than WebSockets)
• No native support for binary types (WebSockets supports raw frames using ArrayBuffers and Blobs).
• Requires a full fledged web server even if the SSE endpoint is not serving static web content (a standalone WebSocket server can be fairly simple)
• SSE with AJAX for bi-directional communication will have MUCH higher round-trip latency and higher client->server bandwidth than using a WebSocket connection. This is due to the overhead of connection setup for every client->server AJAX request. Also, server->client latency can have spikes with SSE since in many configurations the long-held connection will eventually be closed (often every 30 seconds) and need to be re-opened causing a temporary spike in server->client latency as well.

References:

• http://www.html5rocks.com/en/tutorials/eventsource/basics/
• https://developer.mozilla.org/en-US/docs/Server-sent_events
• https://developer.mozilla.org/en-US/docs/Server-sent_events/Using_server-sent_events
• http://dev.w3.org/html5/eventsource/