4 ms·

> I would have preferred if the author gave a way deeper answer of this rather important question. Like the paragraghs that come after it?

orliesaurus 4y ago
I read the whole thing, my point is that it DOES NOT do a good job at explaining the reasoning behind build this. In fact the real answer is hidden here: > If you need something that works "out of the box" with common server setups, and with broad web client support, WebSockets is a better choice today.
- markdog12 4y ago
  I politely disagree. The article seems to intentionally compare existing APIs, and explains its relation to websockets fairly well, IMO. https://web.dev/webtransport/#is-webtransport-a-replacement-for-websockets https://web.dev/webtransport/#is-webtransport-a-replacement-...
- tomxor 4y ago
  That's only referring to current maturity... the differences are more nuanced. I'd recommend reading the article, it's not super long.
- yeeticus 4y ago
  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]

orliesaurus 4y ago

I read the whole thing, my point is that it DOES NOT do a good job at explaining the reasoning behind build this. In fact the real answer is hidden here: > If you need something that works "out of the box" with common server setups, and with broad web client support, WebSockets is a better choice today.

markdog12 4y ago
I politely disagree. The article seems to intentionally compare existing APIs, and explains its relation to websockets fairly well, IMO. https://web.dev/webtransport/#is-webtransport-a-replacement-for-websockets https://web.dev/webtransport/#is-webtransport-a-replacement-...
tomxor 4y ago
That's only referring to current maturity... the differences are more nuanced. I'd recommend reading the article, it's not super long.
yeeticus 4y ago
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]