4 ms·

There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport

by eis 4y ago

There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport. I think it's missing a killer app. But I am not sure what WebTransport would enable that isn't already possible with current APIs. Unreliable datagrams? WebRTC. Reliable bidirectional communication? WebSockets. WebTransport probably would make some of the usecases easier or more efficient but it's value proposition isn't well communicated or better yet, demonstrated. To be clear: I like WebTransport and want to see it supported widely. But it needs a bit better communication of its value proposition. It needs a bunch of examples for both client and server side. Ideally with a comparison to their WebSocket and WebRTC counter parts to highlight the advantages. EDIT: Chrome on Android DOES support WebTransport. I previously claimed it doesn't based on the incorrect info on https://caniuse.com/webtransport https://caniuse.com/webtransport but have since verified it myself that at least Chrome v103 on Android 12 does indeed support WebTransport.

markdog12 4y ago
> Chrome on Android doesn't either Interesting, do you have a source? Or did you try it? > I am not sure what WebTransport would enable that isn't already possible with current APIs. Unreliable datagrams? WebRTC. Reliable bidirectional communication? WebSockets. WebTransport probably would make some of the usecases easier or more efficient but it's value proposition isn't well communicated or better yet, demonstrated. The article does seem to answer these questions.
- strbean 4y ago
  Can I Use[1] gives mixed messages on this. Seems like it is either partially supported or fully supported and one of the entries is just misleading? [1]https://caniuse.com/?search=webtransport https://caniuse.com/?search=webtransport
  - eis 4y ago
    The information there is indeed incorrect. I have updated my comment accordingly.
- eis 4y ago
  > Interesting, do you have a source? Or did you try it? https://caniuse.com/webtransport https://caniuse.com/webtransport > The article does seem to answer these questions. Not for me. There's no usecase mentioned that is not possible today unless you count using it from inside a worker as a usecase I guess. I wonder btw why they compare WebTransports datagrams to WebSockets reliable streams. The equivalent to WebSockets would be the reliable Streams API of WebTransport. The issue with Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol.
  - markdog12 4y ago
    > https://caniuse.com/webtransport https://caniuse.com/webtransport Yeah, it seems there's an older entry in there that's confusing. Not sure. > There's no usecase mentioned that is not possible today WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods. > Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol. Yes, and solving it within the protocol is simpler and more efficient. > It needs a bunch of examples Agreed, that would be nice.
    - eis 4y ago
      > Yeah, it seems there's an older entry in there that's confusing. Not sure. I have just tried it on Chrome 103 on Android 12 and WebTransport worked. The information on caniuse.com is indeed incorrect. > WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods. Yup, that's why I want to see it widely supported. Any simplification is good for the web. Though WebTransport unfortunately does not improve on every aspect of the existing APIs. It also has limitations that WebRTC does not have like P2P or easily piping media for using in MediaStreams.
strbean 4y ago
> Unreliable datagrams? WebRTC It's was an interminable wait for WebRTC data channels. Is there a trivial way to get a WebRTC connection to a server now, without pretending that server is a peer and doing the whole handshake dance?
- Sean-Der 4y ago
  Do you still see challenges with doing WebRTC on a server? I work on https://github.com/pion/webrtc https://github.com/pion/webrtc so would love to hear what could be better :)
  - ptrwis 4y ago
    And are you going to run a dedicated signaling service and do all that STUN karate to just connect the peer to a publicly available server?
    - eis 4y ago
      You don't need STUN to connect to a publicly available WebRTC server.
    - Sean-Der 4y ago
      > dedicated signalling For my small projects I run my HTTP + WebRTC in the same server. My signaling is one POST. Maybe I am missing the complexity, but I don't feel any additional pain compared to running any network service? > STUN Karate Mind explaining more? You don't use STUN for connecting to a world routable host. If you need it I use https://github.com/pion/turn https://github.com/pion/turn and run my STUN server embedded in my HTTP server. I do do anything but point my `PeerConnection` at `my-service.com`
      - ptrwis 4y ago
        What I mean is that compared to, for example, WebSockets and WebTransport, WebRTC is more difficult to use (not through third-party libraries but "native" WebRTC data-channel API). But you are right and I was wrong, STUN is not necessary.
nonethewiser 4y ago
> To be clear: I like WebTransport and want to see it supported widely Given all you've said, why? Why do you like it? I am trying to understand its purpose but you haven't really articulated its value proposition either. How could it have value if there are better alternatives to both things it offers?
- eis 4y ago
  Good question :) When it comes to reliable streams and WebTransport vs WebSockets I really don't see much improvement. Where I do see a simplification is when it comes to WebTransport vs WebRTC data channels. It's just a simpler API and protocol.
  - josephg 4y ago
    Even reliable streams benefit from webtransport. Right now (as I understand it) WebSocket is HTTP1.1 only - which means if you’re using HTTP2/HTTP3 and want to use websockets, the websocket connection will create a separate TCP connection just for WS. This is slow to start - both due to needing another handshake and TLS dance. And you can run into a bunch of problems due to per-domain browser connection limits. Reliable streams over webtransport will solve these problems. They’ll be faster, more reliable and a better fit for HTTP/3.
dmitriid 4y ago
> There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport. Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin"
- josephg 4y ago
  Well, it’s been in the works for years (since at least 2019 from recollection). It’s made it’s way through the IETF and W3C, and it’s been implemented in Chrome and Edge since the start of the year. It won’t see adoption until firefox adopts it and HTTP/3 starts gaining traction. But I’d say it’s a lot further along than the “coffee stained napkin” stage. It’s older than covid.
  - dmitriid 4y ago
    > Well, it’s been in the works for years So? > It’s made it’s way through the IETF and W3C It's status at W3C is "editor's draft" > and it’s been implemented in Chrome and Edge since the start of the year. Which makes it a Chrome-only non-standard. > It’s older than covid. Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track.
    - josephg 4y ago
      > Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track. There's a process to get features like webtransport into browsers and available everywhere. The process started with some proposals at W3C, continued with some discussions and specs being written up at both the IETF and the W3C. The work more-or-less concludes with broad browser support and applications being written using the spec. The process takes years and its nearly complete. Webtransport has been in the works since at least 2019. Support has landed in Chrome and Edge. Hopefully we'll soon see the spec be ratified, get implementations in Firefox and Safari and then we can start using it in production software. You said: > Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin" We've come a long way from "a draft on a coffee-stained napkin". A draft on a coffee-stained napkin wouldn't have shipping code in Chrome. Just because you can't use it yet in Firefox doesn't mean there hasn't been a helluva lot of work put into making WebTransport come to life so far, from a whole lot of people who have done a lot more work improving the web than most of us will ever know.
vasilvv 4y ago
> There seems to be not too much interest in or hype about WebTransport. I feel like this is partially because the main value of the API comes from working better on lower-quality networks, rather than providing the ability to do something completely brand new. > FF and Safari don't support it yet. For what it's worth, Mozilla are positive about it [0] and are actively involved in the standards process. I don't believe the WebKit team has stated their position, though there are Apple people who are involved in the standards process too. > I think it's missing a killer app. But I am not sure what WebTransport would enable that isn't already possible with current APIs. When we started out working on WebTransport, there were two major use cases we had in mind: live media and web games. IETF MoQ working group [1] will hopefully address the first one. I don't know whether anyone is using it for building games, but I don't actually have that much visibility into what's going on in that space. [0] https://mozilla.github.io/standards-positions/#webtransport https://mozilla.github.io/standards-positions/#webtransport [1] https://datatracker.ietf.org/wg/moq/about/ https://datatracker.ietf.org/wg/moq/about/

by eis 4y ago

markdog12 4y ago

> Chrome on Android doesn't either Interesting, do you have a source? Or did you try it? > I am not sure what WebTransport would enable that isn't already possible with current APIs. Unreliable datagrams? WebRTC. Reliable bidirectional communication? WebSockets. WebTransport probably would make some of the usecases easier or more efficient but it's value proposition isn't well communicated or better yet, demonstrated. The article does seem to answer these questions.

strbean 4y ago
Can I Use[1] gives mixed messages on this. Seems like it is either partially supported or fully supported and one of the entries is just misleading? [1]https://caniuse.com/?search=webtransport https://caniuse.com/?search=webtransport
- eis 4y ago
  The information there is indeed incorrect. I have updated my comment accordingly.
eis 4y ago
> Interesting, do you have a source? Or did you try it? https://caniuse.com/webtransport https://caniuse.com/webtransport > The article does seem to answer these questions. Not for me. There's no usecase mentioned that is not possible today unless you count using it from inside a worker as a usecase I guess. I wonder btw why they compare WebTransports datagrams to WebSockets reliable streams. The equivalent to WebSockets would be the reliable Streams API of WebTransport. The issue with Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol.
- markdog12 4y ago
  > https://caniuse.com/webtransport https://caniuse.com/webtransport Yeah, it seems there's an older entry in there that's confusing. Not sure. > There's no usecase mentioned that is not possible today WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods. > Head Of Line blocking can be easily solved by opening multiple WebSocket connections. WebTransport just has that solved instead within the protocol. Yes, and solving it within the protocol is simpler and more efficient. > It needs a bunch of examples Agreed, that would be nice.
  - eis 4y ago
    > Yeah, it seems there's an older entry in there that's confusing. Not sure. I have just tried it on Chrome 103 on Android 12 and WebTransport worked. The information on caniuse.com is indeed incorrect. > WebTransport does not really do anything that was previously impossible from an API standpoint, it improves on existing methods. Yup, that's why I want to see it widely supported. Any simplification is good for the web. Though WebTransport unfortunately does not improve on every aspect of the existing APIs. It also has limitations that WebRTC does not have like P2P or easily piping media for using in MediaStreams.

strbean 4y ago

> Unreliable datagrams? WebRTC It's was an interminable wait for WebRTC data channels. Is there a trivial way to get a WebRTC connection to a server now, without pretending that server is a peer and doing the whole handshake dance?

Sean-Der 4y ago
Do you still see challenges with doing WebRTC on a server? I work on https://github.com/pion/webrtc https://github.com/pion/webrtc so would love to hear what could be better :)
- ptrwis 4y ago
  And are you going to run a dedicated signaling service and do all that STUN karate to just connect the peer to a publicly available server?
  - eis 4y ago
    You don't need STUN to connect to a publicly available WebRTC server.
  - Sean-Der 4y ago
    > dedicated signalling For my small projects I run my HTTP + WebRTC in the same server. My signaling is one POST. Maybe I am missing the complexity, but I don't feel any additional pain compared to running any network service? > STUN Karate Mind explaining more? You don't use STUN for connecting to a world routable host. If you need it I use https://github.com/pion/turn https://github.com/pion/turn and run my STUN server embedded in my HTTP server. I do do anything but point my `PeerConnection` at `my-service.com`
    - ptrwis 4y ago
      What I mean is that compared to, for example, WebSockets and WebTransport, WebRTC is more difficult to use (not through third-party libraries but "native" WebRTC data-channel API). But you are right and I was wrong, STUN is not necessary.

nonethewiser 4y ago

> To be clear: I like WebTransport and want to see it supported widely Given all you've said, why? Why do you like it? I am trying to understand its purpose but you haven't really articulated its value proposition either. How could it have value if there are better alternatives to both things it offers?

eis 4y ago
Good question :) When it comes to reliable streams and WebTransport vs WebSockets I really don't see much improvement. Where I do see a simplification is when it comes to WebTransport vs WebRTC data channels. It's just a simpler API and protocol.
- josephg 4y ago
  Even reliable streams benefit from webtransport. Right now (as I understand it) WebSocket is HTTP1.1 only - which means if you’re using HTTP2/HTTP3 and want to use websockets, the websocket connection will create a separate TCP connection just for WS. This is slow to start - both due to needing another handshake and TLS dance. And you can run into a bunch of problems due to per-domain browser connection limits. Reliable streams over webtransport will solve these problems. They’ll be faster, more reliable and a better fit for HTTP/3.

dmitriid 4y ago

> There seems to be not too much interest in or hype about WebTransport. FF and Safari don't support it yet. MDN does not contain a single mention of WebTransport. Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin"

josephg 4y ago
Well, it’s been in the works for years (since at least 2019 from recollection). It’s made it’s way through the IETF and W3C, and it’s been implemented in Chrome and Edge since the start of the year. It won’t see adoption until firefox adopts it and HTTP/3 starts gaining traction. But I’d say it’s a lot further along than the “coffee stained napkin” stage. It’s older than covid.
- dmitriid 4y ago
  > Well, it’s been in the works for years So? > It’s made it’s way through the IETF and W3C It's status at W3C is "editor's draft" > and it’s been implemented in Chrome and Edge since the start of the year. Which makes it a Chrome-only non-standard. > It’s older than covid. Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track.
  - josephg 4y ago
    > Ah. The new definition of standards I see. The only thing that matters is how long it's been in development. Not the checks notes reality and the actual standards track. There's a process to get features like webtransport into browsers and available everywhere. The process started with some proposals at W3C, continued with some discussions and specs being written up at both the IETF and the W3C. The work more-or-less concludes with broad browser support and applications being written using the spec. The process takes years and its nearly complete. Webtransport has been in the works since at least 2019. Support has landed in Chrome and Edge. Hopefully we'll soon see the spec be ratified, get implementations in Firefox and Safari and then we can start using it in production software. You said: > Because it's not a standard. The status is "Editor's draft" which is barely above "A draft on a coffee-stained napkin" We've come a long way from "a draft on a coffee-stained napkin". A draft on a coffee-stained napkin wouldn't have shipping code in Chrome. Just because you can't use it yet in Firefox doesn't mean there hasn't been a helluva lot of work put into making WebTransport come to life so far, from a whole lot of people who have done a lot more work improving the web than most of us will ever know.

vasilvv 4y ago

> There seems to be not too much interest in or hype about WebTransport. I feel like this is partially because the main value of the API comes from working better on lower-quality networks, rather than providing the ability to do something completely brand new. > FF and Safari don't support it yet. For what it's worth, Mozilla are positive about it [0] and are actively involved in the standards process. I don't believe the WebKit team has stated their position, though there are Apple people who are involved in the standards process too. > I think it's missing a killer app. But I am not sure what WebTransport would enable that isn't already possible with current APIs. When we started out working on WebTransport, there were two major use cases we had in mind: live media and web games. IETF MoQ working group [1] will hopefully address the first one. I don't know whether anyone is using it for building games, but I don't actually have that much visibility into what's going on in that space. [0] https://mozilla.github.io/standards-positions/#webtransport https://mozilla.github.io/standards-positions/#webtransport [1] https://datatracker.ietf.org/wg/moq/about/ https://datatracker.ietf.org/wg/moq/about/