SSEs had a severe connection limit, something like 4 connections per domain per browser (IIRC), so if you had four tabs open then opening new ones would fail.
Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs.
(There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't developed in a vacuum by people who had no idea what they were doing, and it wasn't developed aimlessly or without real world testing. It is used by pretty much all major websites, and they absolutely wouldn't use it if HTTP/1.1 was better... those major websites exist to serve their customers, not to conspiratorially push an agenda of broken technologies that make the customer experience worse.)
Right, but this article argues that SSE is simple and easy to debug on the wire - so is http1. Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore.
The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned.
> The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned.
It does not apply to HTTP/2, as previously noted.
> Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore.
I have literally never heard of anyone I personally know having to debug HTTP/2 on the wire. Unless you believe there are frequently bugs in the HTTP/2 implementation in your browser or the library you use, this just not a real concern. HTTP/2 has been around long enough that this is definitely not a concern of mine. I would be more worried about bugs with HTTP/3, since it is so new.
Websockets are also not especially easy to set up… they don’t work with normal HTTP servers and proxies, so you have to set up other infrastructure.
Which web servers do they not work with? They have worked everything I've used thus far (which admittedly aren't many): nginx, warp (Haskell's embedded server), relayd (OpenBSD), all with easy setup.
It also seems that compression for websockets is supported in all major browsers.
The article's argument seems to be that ws adds complexity, but this is present in pretty much all web servers already, the user needs not to deal with it. (HTTP2, too, requires the same type of complexity for that matter)
You can also make your HTTP/1.1 SSE endpoints available on multiple domains and have the client round-robin them. Obviously adds some complexity, but sometimes it's a tradeoff worth making for example if you're on lossy networks and trying to avoid HTTP/2 head-of-line blocking.
It appears to be 30 per domain, not “hundreds”, at least as of the time this answer was written. I didn’t see anything more recent that contradicted this.
In practice, this is unlikely to be problematic unless you’re using multiple websockets per page, but the limit of 6 TCP connections is even less likely to be a problem if you’re using HTTP/2, since those will be shared across tabs, which isn’t the case for the dedicated connection used for each websocket.
