Recently, I was analyzing ways to improve the User Experience based on real time events. The very first thought that popped up in my mind was Web Sockets. It’s widely used and everyones favorite. I was curious to see if there is any alternative to Web Sockets and if so what are their usages , advantages etc. During the research , I came to across Server Sent Events (SSE) also known as Event Source.

WebSockets and Server-Sent Events are two different technologies that define how browsers and clients communicate with each other. In this post, we’ll look at the individual features of these technologies and showcase both their similarities and differences. Before we get into it, it is worth noting that they’re not competing technologies and neither is explicitly better than the other.

WebSockets

WebSockets is an advanced technology that allows real-time interactive bidirectional communication between the client browser and a server. In simple terms, WebSockets make it possible for data to be transferred from the client to the server and vice versa in real time. With WebSockets API, you can send messages to a server and receive event-driven responses without having to poll the server for a reply. A good example of an application that could use websockets is a chat application.

Server Sent Events (SSE)

Server Sent Events technology provides one way communication between server to client. 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.

Apart from the fact that these two technologies operate through HTTP connections, the most noticeable similarity is that they function exactly the same way. They both push data from the server to client, a process also known as server push.

Why would one choose Server-Sent Events over WebSockets?

One reason SSEs have been kept in the shadow is because later APIs like WebSockets provide a richer protocol to perform bi-directional, full-duplex communication. Having a two-way channel is more attractive for things like games, messaging apps, and for cases where you need near real-time updates in both directions. However, in some scenarios data doesn’t need to be sent from the client. You simply need updates from some server action. A few examples would be friends’ status updates, stock tickers, news feeds, or other automated data push mechanisms.

SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working. WebSockets on the other hand, require full-duplex connections and new Web Socket servers to handle the protocol. In addition, Server-Sent Events have a variety of features that WebSockets lack by design such as automatic reconnection, event IDs, and the ability to send arbitrary events.

Advantages of SSE over Websockets:

• Transported over simple HTTP instead of a custom protocol
• Can be poly-filled with javascript to “backport” SSE to browsers that do not support it yet.
• Built in support for re-connection and event-id
• Simpler protocol

Note: SSEs suffer from a limitation to the maximum number of open connections, which can be especially painful when opening various tabs, as the limit per browser is six.

Advantages of Websockets over SSE:

• Real time, two directional communication.
• Native suport in more browers
• WebSockets can transmit both binary data and UTF-8, whereas SSEs are limited to UTF-8.

Note: Compared to SSEs, WebSockets are a lot more complex and task-demanding to set up. This has its pitfalls, as it requires a lot of upfront work. Be that as it may, it also makes for a very stable and extensible application setting. SSE is a simpler and faster solution, but it isn’t extensible. If, for instance, your web application requirements were to change, it would need to be refactored using WebSockets, which are more versatile with the ability to handle complex projects

Ideal use cases of SSE:

• Stock ticker streaming
• twitter feed updating
• Notifications to browser

Conclusion

In this post, we have compared these two similar yet different technologies to expose their individual strengths and weaknesses to offer you a better chance at understanding them and making the right choice for usage. Like I mentioned earlier, no one is better than the other — whether you should be using WebSockets or SSEs depends on your own specific use case.