*Feb 2025* Today in #datastar Discord there was a discussion about #server-sent-events vs Websockets: > Websockets are not http, they don't support compression, or standard headers, they don't support cookies, they can't be multiplexed over a http2 connection, they don't handle disconnects, missed events, retries etc. All of that has to be handled in user land or by the websocket library you are using. Oh and a lot of corporate firewalls block them so your library has to fall back to polling Another input: > So we used websockets at scale at a gambling company. The pain points we ran into were: > - firewalls and proxies, blocked ports > - unlimited connections non multiplexed (so bugs lead to ddos) > - So you try to limit to one connection, but websockets don't have multiplexing. Now you have to roll your own multiplexing because everything is going over the same pipe in both directions. Which then means you end up sending more data to send more data (your multiplexing implementation). > - load balancing nightmare > - no compression. You have to do that yourself on the client! it's not done for you automatically by the browser like http (again sending more data to handle more data) > - no cross site hijacking protection > - Absolutely nukes mobile battery because it uses and abuses the duplex antenna. You're basically rolling your own http. Websockets are a nightmare for day 2, month 2 problems. If you are communicating with a browser you shouldn't be using websockets. Also, a related article: - [Server-Sent Events: the alternative to WebSockets you should be using - germano.dev](https://germano.dev/sse-websockets/)