| ▲ | hackingonempty 6 hours ago |
| > The quick rule: if you need bidirectional, low-latency communication (chat, collaboration, games), WebSocket; if you only push from the server, SSE is simpler and cheaper to operate. For most apps just use SSE and the built-in code for making HTTP requests (Fetch) instead of hacking up your own client side JS to make requests over a WebSocket. The latency is the same because modern browsers multiplex HTTP requests over a single TCP connection that is left open. Maybe if you are making many client requests per second there is an advantage to not sending full headers/cookies/etc... on each request but not if you're sending requests in response to user clicks/touches. Any sufficiently complicated SPA contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Fetch. |
|
| ▲ | clappski 5 hours ago | parent | next [-] |
| > The latency is the same because modern browsers multiplex HTTP requests over a single TCP connection that is left open. In my experience this isn’t true; firstly you’re relying on an implementation detail of the platform that you’re executing on, of which you have no control over on the client side. Secondly, even if you aren’t opening a new connection per request, you’re still travelling through an entire HTTP stack implementation rather than the incredibly simple WebSocket protocol - effectively a length and a mask to get the contents, rather than some (in http1 land) fuzzy parser. If you can guarantee you’re hitting http2 or http3 then you might be closer in latency, but due to the complexity of both I would imagine plain http1 negotiated persistent WebSockets provide the best latency. |
| |
| ▲ | galaxyLogic 2 hours ago | parent | next [-] | | But, if you can do things on the client (with JavaScript) you don't need to send (so many) requests to the server, making latency less of an issue. Doing things on the client means user's CPU is doing some work which else would need to be done on the server, for maybe thousands of clients at the same time. So I understand some people don't like JavaScript, but then I think the solution would be WebAssembly. I mean the point of distributed computting is that the computational load can be distributed. Perhaps counter-intuitively that often also means less need fo communications and latencies. | |
| ▲ | paulddraper 44 minutes ago | parent | prev | next [-] | | WebSockets have head-of-line blocking. HTTP/2 does not. | | |
| ▲ | zero_shift 37 minutes ago | parent [-] | | But surely it does? It is TCP, even with multiplexing I thought that was the whole motivation for building HTTP/3 on QUIC (UDP)? | | |
| ▲ | paulddraper 15 minutes ago | parent [-] | | Well, yes. There is always some form of it on TCP. But your HTTP/2 reverse proxy won't block fast responses on slow responses. As long as your WebSocket reverse proxy does the same, you're fine. (And same stipulation for your client.) |
|
| |
| ▲ | jallmann 3 hours ago | parent | prev [-] | | Sure, but SSE connections in the browser - the typical use case - are persistent, so there shouldn't be frequent re-connecting. Unlike WebSockets, browser SSE also has a built-in recovery mechanism so you don't miss events across reconnects (`Last-Event-ID` header), although this does require explicit support from the server-side app. Given that the WebSocket handshake has an additional round-trip, SSE would typically be faster in terms of time-to-first-byte. > you’re still travelling through an entire HTTP stack implementation rather than the incredibly simple WebSocket protocol Both protocols have their own minimal framing, but "an entire HTTP stack" is a stretch. It's hard to argue that `data:value\n\n` is more complex than the WebSocket binary protocol. Simplistic, sure (no binary payloads), but also simple enough to, say, pipe through a regex. Good luck doing that with WebSocket. | | |
| ▲ | crabmusket an hour ago | parent [-] | | > faster in terms of time-to-first-byte Yes, but all these approaches are optimised for long sessions, not TTFB. If that were very important (say, ecommerce) you might prefer a framework that can hydrate and send the full page on first request, rather than setting up a socket to get data. > data:value\n\n I believe the poster was referring to requests from the client to the server having to traverse the HTTP stack, not data coming down from the server via the SSE stream. |
|
|
|
| ▲ | simlevesque 2 hours ago | parent | prev | next [-] |
| No mention of WebTransport makes me very doubtful of this article. It's 2026, all browsers support it and it's bidirectional and lower-latency than WebSocket. |
| |
| ▲ | opendomain an hour ago | parent [-] | | I just looked on the w3c WebTransport is in proposal stage - it is not official yet |
|
|
| ▲ | dzonga 2 hours ago | parent | prev | next [-] |
| yep 100%. the SSE version is less headache and can easily scale. |
|
| ▲ | sublinear 5 hours ago | parent | prev [-] |
| > Any sufficiently complicated SPA contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Fetch. Sound advice otherwise, but you could have left this part out of the comment :D You underestimate how many "sufficiently complicated SPAs" are slapped together low-code projects. Their maintainers have no idea what you're even talking about. |
| |
