Re:Back to basics: Why we chose long-polling over websockets
by csumtin on Sunday January 05, 2025 @06:47AM
(#42601166)
I tried using SSE and found it didn't work for my use case, it was broken on mobile. When users switched from the browser to an app and back, the SSE connection was broken and they wouldn't receive state updates. Was easier to do long polling
[ Parent
| on HN ]
Re:Back to basics: Why we chose long-polling over websockets
by CharlieDigital on Sunday January 05, 2025 @07:16AM
(#42601293)
Not sure about the default `EventSource` object in JavaScript, but the Microsoft polyfill that I use (https://github.com/Azure/fetch-event-source) supports `POST` and there's an option `openWhenHidden` which controls how it reacts to users tabbing away.
Re:Back to basics: Why we chose long-polling over websockets
by josephg on Sunday January 05, 2025 @08:26AM
(#42601593)
The standard way to fix that is to send ping messages every ~15 seconds or something over the SSE stream. If the client doesn’t get a ping in any 20 second window, assume the sse stream is broken somehow and restart it. It’s complex but it works.
The big downside of sse in mobile safari - at least a few years ago - is you got a constant loading spinner on the page. Thats bad UX.