Re:Back to basics: Why we chose long-polling over websockets
by CharlieDigital on Sunday January 05, 2025 @07:17AM
(#42601301)
As the other two comments mentioned, this is a restriction with HTTP/1.1 and it would apply also to long polling connections as well.
Re:Back to basics: Why we chose long-polling over websockets
by _heimdall on Sunday January 05, 2025 @07:24AM
(#42601325)
Syncing state across multiple tabs and windows is always a bit tricky. For SSE, I'd probably reach for the BroadcastChannel API. Open the SSE connection in the first tab and have it broadcast events to any other open tab or window.
Re:Back to basics: Why we chose long-polling over websockets
by bn-l on Sunday January 05, 2025 @06:34AM
(#42601118)
…if you’re using http/1.1. It’s not an issue with 2+
Re:Back to basics: Why we chose long-polling over websockets
by Klonoar on Sunday January 05, 2025 @06:43AM
(#42601156)
Not an issue if you’re using HTTP/2 due to how multiplexing happens.
Re:Back to basics: Why we chose long-polling over websockets
by bioneuralnet on Sunday January 05, 2025 @02:49PM
(#42604449)
I've gotten around this by using the Page Visibility API - https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibi.... Close the SSE connection when the page is hidden, and re-open when it becomes visible again.
One of the drawbacks, as I learned - SSE have limit on number of up to ~6 open connections (browser + domain name). This can quickly become a limiting factor when you open the same web page in multiple tabs.