3 ms·

I agree with this. There is probably some hidden 4d chess business reason at Google for building yet another competing solution. Given that the article emphasi

I agree with this. There is probably some hidden 4d chess business reason at Google for building yet another competing solution. Given that the article emphasizes it supports reliable and unreliable modes, seems to me that the overarching goal is "single interface for everything that's not /HTTP\/[12]/". Maybe it's just that QUIC is slightly better than TCP/HTTP. Probably the real Google reason is "make another thing that Apple and Mozilla have to build", and "eventually they'll die or move to Chromium".

josephg 4y ago
It’s not a Google project. And you don’t have to guess what it’s about - there have been public meetings about it for years, and there’s a public spec. (Both at IETF for the network parts, and at W3C for the javascript APIs). The objective is to make a websockets equivalent for HTTP/3 which can take advantage of h3’s features. The headline features are UDP support and proper multiplexing with other parallel requests. It’s like websocket but it works over h3 and optionally unreliable. And it’s faster. And it’s sort of like webrtc data channels but it’s much more “webby” - it’s server-client not p2p. It works over http, and it’s not a huge inconsistent mess.
- deleted 4y ago
  [deleted]