4 ms·

I grep'd for websockets the first line is: > Is WebTransport a replacement for WebSockets? # Maybe. Seriously? You start with maybe? I would have preferred i

I grep'd for websockets the first line is: > Is WebTransport a replacement for WebSockets? # Maybe. Seriously? You start with maybe? I would have preferred if the author gave a way deeper answer of this rather important question.

have_faith 4y ago
> 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]
eyelidlessness 4y ago
Did you go on to read the rest of the section? It seems pretty clear to me that the “maybe” addresses two factors: 1. Whether you use the Streams APIs (suitable for WebSocket use cases) versus the datagram APIs (not suitable as a general replacement). 2. The standard is relatively new, so the WebSocket ecosystem is currently more mature. I would be more concerned if the author glossed over those fairly important distinctions to say “yes”.
- strbean 4y ago
  I think the succinct answer is "Yes, but you probably want to wait for the ecosystem to mature". If you use WebSocket, you are stuck with streams. You can migrate those to WebTransport. Then you also have the option of datagrams if those make sense for you.
marcosdumay 4y ago
Do you really expect a deep discussion of the subject in a TL/DR line?
- orliesaurus 4y ago
  No but a better one line answer, sure!
  - cush 4y ago
    Maybe answers your question. It does in some cases and not in others. So it might replace your need for websockets.
jeroenhd 4y ago
WebTransport isn't a replacement for all WebSockets. It's a replacement for some websockets in some use cases. "Maybe" is exactly the right answer because the person writing this introduction doesn't know your exact use cases and requirement. Answering yes or no would be inaccurate.

have_faith 4y ago

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

eyelidlessness 4y ago

Did you go on to read the rest of the section? It seems pretty clear to me that the “maybe” addresses two factors: 1. Whether you use the Streams APIs (suitable for WebSocket use cases) versus the datagram APIs (not suitable as a general replacement). 2. The standard is relatively new, so the WebSocket ecosystem is currently more mature. I would be more concerned if the author glossed over those fairly important distinctions to say “yes”.

strbean 4y ago
I think the succinct answer is "Yes, but you probably want to wait for the ecosystem to mature". If you use WebSocket, you are stuck with streams. You can migrate those to WebTransport. Then you also have the option of datagrams if those make sense for you.

marcosdumay 4y ago

Do you really expect a deep discussion of the subject in a TL/DR line?

orliesaurus 4y ago
No but a better one line answer, sure!
- cush 4y ago
  Maybe answers your question. It does in some cases and not in others. So it might replace your need for websockets.

jeroenhd 4y ago

WebTransport isn't a replacement for all WebSockets. It's a replacement for some websockets in some use cases. "Maybe" is exactly the right answer because the person writing this introduction doesn't know your exact use cases and requirement. Answering yes or no would be inaccurate.