[jongjong]

I don't know why people keep trying desperately to avoid the simplicity and flexibility of WebSockets.

A lot of times, what people need is a bidirectional connection yet somehow they convince themselves that SSE is better for the job... But they end up with two different types of streams; HTTP for writes and responses and SSE for passively consuming real-time data... Two different stream types with different lifecycles; one connection could fail while the other is fine... There is no way to correctly identify what is the current connection status of the app because there are multiple connections/statuses and data comes from multiple streams... Figuring out how to merge data coming from HTTP responses with data coming in passively from the SSE is messy and you have no control over the order in which the events are triggered across two different connections...

You can't enforce a serial, sequential, ordered flow of data over multiple connections as easily, it gets messy.

With WebSockets, you can easily assign an ID to requests and match it with a response. There are plenty of WebSocket frameworks which allow you to process messages in-order. The reason they work and are simple is because all messages pass over a single connection with a single state. Recovering from lost connections is much more straight forward.

[gorjusborg]

I don't know why everyone... proceeds to use their own experience as proof of what everyone needs.

These are tools, not religions.

Websockets have some real downsides if you don't need bidirectional comms.

[hntrl]

who's to say your data is coming from multiple streams? You can propagate any updates you need to make in the application to a single stream (like SSE or a long-lived response) in place of a WebSocket. your http responses can just be always 204 if all they're doing is handling updates and pushing events to aforementioned single stream.

https://en.wikipedia.org/wiki/Command%E2%80%93query_separati...

[koakuma-chan]

SSE does not require a separate connection, unlike WebSockets.

[kaoD]

MDN disagrees. See the huge red warning here https://developer.mozilla.org/en-US/docs/Web/API/EventSource

Unless you mean on HTTP2? But aren't WS connections also multiplexed over HTTP2 in that case?

[koakuma-chan]

> MDN disagrees. See the huge red warning here https://developer.mozilla.org/en-US/docs/Web/API/EventSource

It should say "When used over HTTP/1" instead of "When not used over HTTP/2" because nowadays we also have HTTP/3, and browsers barely even use HTTP/1, so I would say it's pretty safe to ignore that warning.

> Unless you mean on HTTP2?

Any version of HTTP that supports multiplexing.

> But aren't WS connections also multiplexed over HTTP2 in that case?

There is RFC 8441 but I don't think it's actually implemented in the browsers.

[kaoD]

> There is RFC 8441 but I don't think it's actually implemented in the browsers.

Found this: https://github.com/mattermost/mattermost/issues/30285

[koakuma-chan]

https://chromestatus.com/feature/6251293127475200

It looks like it's supported in Chrome and Firefox but not in Safari.