Re: [w3c/ServiceWorker] Should EventSource and WebSocket be exposed in service workers? (#947)

> So I would rephrase as:
> 
> 1. Built-in message segmentation.
> 2. Dedicated connections (no multiplexing overhead).

The other factor is lower per-message overhead, when messages are sent individually.

> @ricea FWIW Sandstorm.io (my previous project / startup) had a number of longstanding bugs that would manifest when WebSockets weren't available. In practice I don't remember ever getting a complaint from a single user who turned out to be on a WebSocket-breaking network. We did get a number of reports from users where it turned out Chrome had incorrectly decided that WebSockets weren't available and so was fast-failing them without even trying -- this was always fixed by restarting Chrome.

That's great news, thanks. We only have client-side metrics, so we don't have much insight into why things are failing in the wild.

The bad news is that Chrome has no logic to intentionally make WebSockets fail fast when they're not available. So if it's doing that then the cause is unknown.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/947#issuecomment-336792466