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

@annevk Part of the extra size of HTTP/2 frame headers is explained by needing stream IDs, which is an inescapable consequence of being multiplexed. I must confess I don't know what the rest is.

There were three things I think I was talking about when I said "HTTP/2 is not simple to implement":
1. From a simple engineering standpoint, implementing the HTTP/1.1 protocol is easy, as long you forget about chunked transfer encoding. I've done it several times just for personal projects. I would never contemplate implementing HTTP/2 for a personal project. The WebSocket protocol has lots of seemingly unnecessary fiddly bits, but a small simply implementation can still be put together quickly.
2. From a deployment standpoint, small scale HTTP deployments are ubiquitous and adding in WebSocket support to an existing deployment is easy in many developments. Adding HTTP/2 to a large-scale deployment where you're already using a reverse proxy setup is pretty straightforward, but for a small-scale deployment you suddenly have a whole extra bundle of complexity to deal with. I expect this part to change as even small deployments start from scratch with HTTP/2.
3. From a conceptual standpoint, TCP:TLS:WebSocket is a 1:1:1 relationship. TCP:TLS:HTTP/2:fetch is a 1:1:1:N relationship. When all you need is a single stream, multiplexing is pure cognitive overhead.

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