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.

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