4 ms·

You don't need websockets SSE works fine for realtime collaborative apps. Websockets sound great on paper. But, operationally they are a nightmare. I have had

You don't need websockets SSE works fine for realtime collaborative apps. Websockets sound great on paper. But, operationally they are a nightmare. I have had the misfortune of having to use them at scale (the author of Datastar had a similar experience). To list some of the challenges: - firewalls and proxies, blocked ports - unlimited connections non multiplexed (so bugs lead to ddos) - load balancing nightmare - no compression. - no automatic handling of disconnect/reconnect. - no cross site hijacking protection - Worse tooling (you can inspect SSE in the browser). - Nukes mobile battery because it hammers the duplex antenna. You can fix some of these problems with websockets, but these fixes mostly boil down to sending more data... to send more data... to get you back to your own implementation of HTTP. SSE on the other hand, by virtue of being regular HTTP, work out of the box with, headers, multiplexing, compression, disconnect/reconnect handling, h2/h3, etc. If SSE is not performant enough for you then you should probably be rolling your own protocol on UDP rather than using websockets. Or wait until WebTransport is supported in Safari (any day now ). Here's the article with a real time multiplayer Game of Life that's using SSE and compression for multiplayer. https://example.andersmurphy.com https://example.andersmurphy.com It's doing a lot of other dumb stuff explained a bit more here, but the point is you really really don't need websockets (and operationally you really don't want them): https://andersmurphy.com/2025/04/07/clojure-realtime-collaborative-web-apps-without-clojurescript.html https://andersmurphy.com/2025/04/07/clojure-realtime-collabo...

EarthLaunch 1y ago
Useful take, thanks for mentioning specifics. Some of these I wasn't aware of. - What makes load balancing easier with SSE? I imagine that balancing reconnects would work similar to WS. - Compression might be a disadvantage for binary data, which WS specializes in. - Browser inspection of SSE does sound amazing. - Mobile duplex antenna is way outside my wheelhouse, sounds interesting. Can you see any situation in which websockets would be advantageous? I know that SSE has some gotchas itself, such as limited connections (6) per browser. I also wonder about the nature of memory and CPU usage for serving many clients on WS vs SSE. I have a browser game (few players) using vanilla WS.
- andersmurphy 1y ago
  Thanks. - Load balancing is easier because your connection is stateless. You don't have to connect to the same server when you reconnect. Your up traffic doesn't have to go to the same server as your down traffic. Websocket tend to come with a lot of connection context. With SSE you can easily kill nodes, and clients will reconnect to other nodes automatically. - The compression is entirely optional. So when you don't need it don't use it. What's great about it though is it's built into the browser so you're not having to ship it to the client first. - The connection limit of 6 is only applies to http1.1 not http2/3. If you are using SSE you'll want http2/3. But, generally you want http2/3 from your proxy/server to the browser anyway as it has a lot of performance/latency benefits (you'll want it for multiplexing your connection anyway). - In my experience CPU/memory usage is lower than websockets. Obviously, some languages make them more ergonomic to use virtual/green threads (go, java, clojure). But, a decent async implementation can scale well too. Honestly, and this is just an opinion, no I can't see when I would ever want to use websockets. Their reconnect mechanisms are just not reliable enough and their operational complexity isn't worth it. For me at least it's SSE or a proper gaming net code protocol over UDP. If your browser game works with websockets it will work with SSE.
  - EarthLaunch 1y ago
    I appreciate the answers. For others reading, I also just ran across another thread where you posted relevant info [0]. In the case of my game, I'm going to consider SSE, since most of the communication is server to client. That said, I already have reconnects etc implemented. In my research I recall some potential tradeoffs with SSE [1], but even there I concluded they were minor enough to consider SSE vs WS a wash[2] even for my uses. Looking back at my bookmarks, I see that you were present in the threads I was reading, how cool. A couple WS advantages I am now recalling: SSE is one-way, so for situations with lots of client-sent data, a second connection will have to be opened (with overhead). I think this came up for me since if a player is sending many events per second, you end up needing WS. I guess you're saying to use UDP, which makes sense, but has its own downsides (firewalls, WebRTC, WebTransport not ready). Compression in SSE would be negotiated during the initial connection, I have to assume, so it wouldn't be possible to switch modes or mix in pre-compressed binary data without reconnecting or base64-ing binary. (My game sends a mix of custom binary data, JSON, and gzipped data which the browser can decompress natively.) Edit: Another thing I'm remembering now is order of events. Because WS is a single connection and data stream, it avoids network related race conditions; data is sent and received in the programmatically defined sequence. 0: https://news.ycombinator.com/item?id=43657717 https://news.ycombinator.com/item?id=43657717 1: https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html https://rxdb.info/articles/websockets-sse-polling-webrtc-web... 2: https://www.timeplus.com/post/websocket-vs-sse https://www.timeplus.com/post/websocket-vs-sse
realharo 1y ago
What do you mean by "inspect in browser"? All major browsers' devtools have supported WebSocket inspecting for many years. Many of the other issues mentioned are also trivial to solve (reconnects, cross-origin protection). Also, doesn't WebTransport have many of the same issues? (e.g. with proxies and firewalls). And do you have any data for the mobile battery claim? (assuming this is for an application in foreground with the screen on)
- andersmurphy 1y ago
  The fact that you are saying they are trivial to solve means you probably need more visibility on your system. Reliable reconnect was the nightmare we saw regularly. Unfortunately, I can't go into much detail on the mobile battery stuff, but I can give you some hints. If you do some reading on how antenna on phones work combined with websockets heartbeat ping/pong and you should get the idea.
  - Chaosvex 1y ago
    > If you do some reading on how antenna on phones work combined with websockets heartbeat ping/pong and you should get the idea. The implication is that the ping/pong keeps the system active when it wouldn't otherwise be necessary, but else are you receiving data or detecting lost connection with the other mechanisms? The lower layers have their own keepalives, so what's different? I looked into it a little since it didn't make sense to me, unless you're comparing apples and oranges, but the only research I could find either didn't seem to support your stance or compared WebSockets to the alternative of just simply not being able to receive data in a timely manner.

EarthLaunch 1y ago

Useful take, thanks for mentioning specifics. Some of these I wasn't aware of. - What makes load balancing easier with SSE? I imagine that balancing reconnects would work similar to WS. - Compression might be a disadvantage for binary data, which WS specializes in. - Browser inspection of SSE does sound amazing. - Mobile duplex antenna is way outside my wheelhouse, sounds interesting. Can you see any situation in which websockets would be advantageous? I know that SSE has some gotchas itself, such as limited connections (6) per browser. I also wonder about the nature of memory and CPU usage for serving many clients on WS vs SSE. I have a browser game (few players) using vanilla WS.

andersmurphy 1y ago
Thanks. - Load balancing is easier because your connection is stateless. You don't have to connect to the same server when you reconnect. Your up traffic doesn't have to go to the same server as your down traffic. Websocket tend to come with a lot of connection context. With SSE you can easily kill nodes, and clients will reconnect to other nodes automatically. - The compression is entirely optional. So when you don't need it don't use it. What's great about it though is it's built into the browser so you're not having to ship it to the client first. - The connection limit of 6 is only applies to http1.1 not http2/3. If you are using SSE you'll want http2/3. But, generally you want http2/3 from your proxy/server to the browser anyway as it has a lot of performance/latency benefits (you'll want it for multiplexing your connection anyway). - In my experience CPU/memory usage is lower than websockets. Obviously, some languages make them more ergonomic to use virtual/green threads (go, java, clojure). But, a decent async implementation can scale well too. Honestly, and this is just an opinion, no I can't see when I would ever want to use websockets. Their reconnect mechanisms are just not reliable enough and their operational complexity isn't worth it. For me at least it's SSE or a proper gaming net code protocol over UDP. If your browser game works with websockets it will work with SSE.
- EarthLaunch 1y ago
  I appreciate the answers. For others reading, I also just ran across another thread where you posted relevant info [0]. In the case of my game, I'm going to consider SSE, since most of the communication is server to client. That said, I already have reconnects etc implemented. In my research I recall some potential tradeoffs with SSE [1], but even there I concluded they were minor enough to consider SSE vs WS a wash[2] even for my uses. Looking back at my bookmarks, I see that you were present in the threads I was reading, how cool. A couple WS advantages I am now recalling: SSE is one-way, so for situations with lots of client-sent data, a second connection will have to be opened (with overhead). I think this came up for me since if a player is sending many events per second, you end up needing WS. I guess you're saying to use UDP, which makes sense, but has its own downsides (firewalls, WebRTC, WebTransport not ready). Compression in SSE would be negotiated during the initial connection, I have to assume, so it wouldn't be possible to switch modes or mix in pre-compressed binary data without reconnecting or base64-ing binary. (My game sends a mix of custom binary data, JSON, and gzipped data which the browser can decompress natively.) Edit: Another thing I'm remembering now is order of events. Because WS is a single connection and data stream, it avoids network related race conditions; data is sent and received in the programmatically defined sequence. 0: https://news.ycombinator.com/item?id=43657717 https://news.ycombinator.com/item?id=43657717 1: https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html https://rxdb.info/articles/websockets-sse-polling-webrtc-web... 2: https://www.timeplus.com/post/websocket-vs-sse https://www.timeplus.com/post/websocket-vs-sse

realharo 1y ago

What do you mean by "inspect in browser"? All major browsers' devtools have supported WebSocket inspecting for many years. Many of the other issues mentioned are also trivial to solve (reconnects, cross-origin protection). Also, doesn't WebTransport have many of the same issues? (e.g. with proxies and firewalls). And do you have any data for the mobile battery claim? (assuming this is for an application in foreground with the screen on)

andersmurphy 1y ago
The fact that you are saying they are trivial to solve means you probably need more visibility on your system. Reliable reconnect was the nightmare we saw regularly. Unfortunately, I can't go into much detail on the mobile battery stuff, but I can give you some hints. If you do some reading on how antenna on phones work combined with websockets heartbeat ping/pong and you should get the idea.
- Chaosvex 1y ago
  > If you do some reading on how antenna on phones work combined with websockets heartbeat ping/pong and you should get the idea. The implication is that the ping/pong keeps the system active when it wouldn't otherwise be necessary, but else are you receiving data or detecting lost connection with the other mechanisms? The lower layers have their own keepalives, so what's different? I looked into it a little since it didn't make sense to me, unless you're comparing apples and oranges, but the only research I could find either didn't seem to support your stance or compared WebSockets to the alternative of just simply not being able to receive data in a timely manner.