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.
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.
> 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.
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.