> Perceived Limitations: The unidirectional nature might seem restrictive, though it's often sufficient for many use cases For my use cases the main limitation

> Perceived Limitations: The unidirectional nature might seem restrictive, though it's often sufficient for many use cases For my use cases the main limitations of SSE are: 1. Text-only, so if you want to do binary you need to do something like base64 2. Browser connection limits for HTTP/1.1, ie you can only have ~6 connections per domain[0] Connection limits aren't a problem as long as you use HTTP/2+. Even so, I don't think I would reach for SSE these days. For less latency-sensitive and data-use sensitive applications, I would just use long polling. For things that are more performance-sensitive, I would probably use fetch with ReadableStream body responses. On the server side I would prefix each message with a 32bit integer (or maybe a variable length int of some sort) that gives the size of the message. This is far more flexible (by allowing binary data), and has less overhead compared to SSE, which requires 7 bytes ("data:" + "\n\n") of overhead for each message. [0]: https://stackoverflow.com/a/985704 https://stackoverflow.com/a/985704