> 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 42 minutes ago | parent | prev | next [-]

WebSockets have head-of-line blocking.

HTTP/2 does not.

▲

zero_shift 35 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 13 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.