> WebRTC data channels support peer-to-peer communications, but WebTransport only supports client-server connection. If you have multiple clients that need to talk directly to each other, then WebTransport isn't a viable alternative.
That's disappointing. I have a peer-to-peer application where I'd like to be able to use QUIC streams rather than the current SCTP-based WebRTC data channels. In particular, it seems to me that QUIC streams would be better for transferring files peer-to-peer in a way that takes full advantage of available bandwidth without causing congestion or doing excess buffering on the sending end.
As a user of QUIC, I've found it to be pretty much everything I've been wanting for the last 20 years. Hopefully WebTransport can grow the features required (e.g. by stealing them from WebRTC) to make real P2P WebTransport possible.
Do you see any resources on hole punching with QUIC, and NAT traversal? So far I can't even easily find a reference in existing QUIC libraries if it is possible to just send single QUIC packets to perform only hole punching while having separate streams to be established when the punch packets pass through.
There's nothing stopping QUIC from being p2p. In fact, the original version of WebTransport was called QuicTransport and was p2p, but there was more interest in client/server use cases, so we switched focus to that.
(I'm one of the original authors of the WebTransort spec and when I worked at Google years ago, some excellent engineers on my team shipped the original QuicTransport behind a field trial).
> Using WebTransport [...] means that you don't have to worry about head-of-line blocking, which can be an issue with WebSockets.
I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets.
> Additionally, there are performance benefits when establishing new connections, as the underlying QUIC handshake is faster than starting up TCP over TLS.
Huh? This isn't a problem for HTTP/3 in general, because there's only a single quic connection (as long as you're talking with a single endpoint). So creating new Websocket streams should just create a new quic stream within the same connection transparently – I mean... this is the main point of HTTP/3. This sounds like an argument against adding another almost identical standard. Can someone explain?
If they want datagrams (which I can kinda understand), why not just add that as an extension to the Websocket spec?
Websockets are implemented everywhere, though, to the point where they shouldn't have been (server side events are often a much better fit).
Maybe your products don't use Websockets but the days of polling HTTP requests are long gone. Almost every web framework I know has some kind of support for websockets in its design and every proxy I know can easily handle websockets.
Sure, stuff like lambdas don't work but that's because the proprietary cloud provider API chooses not to implement them, probably for good reason. These types of programs are abstractions on top of abstractions, taking away all difficulty in multi server scaling at the cost of low level control over your code, and it turns out Websockets are just that: low level, stateful APIs that people wanted the browser to have.
The reason WebTransport is implemented is that people wanted UDP websockets. Unity developers have been asking for this stuff for years, for example, because running game logic over TCP out even QUIC can be terribly slow and stuttery. The websocket stack isn't really built for datagram exchange and support for the new feature depends on other factors (HTTP/3, for one) so I think it makes sense to make this a separate API. The mental model of what APIs are out aren't lossy is a lot clearer this way.
> The reason WebTransport is implemented is that people wanted UDP websockets. [...] because running game logic over TCP out even QUIC can be terribly slow and stuttery.
Http/3 already uses quic so this is just using quic datagrams, which is sane.. But why not an extension to websockets (only available over http/3) when everything else is the same?
EDIT: Got annoyed enough to look it up and I think this is the key:
> While WebSockets starts as a HTTP/1.1 protocol, WebTransport works on top of several different protocols, including some that WebSockets doesn’t support.
So apparently you have to start websockets over http/1.1 before upgrade which necessitates a separate connection per stream. Still, couldn't this be.. Fixed within the existing spec, or a major version bump? In either case, I guess it doesn't matter much, but I suspect a lot of people will be confused with the name.
Yes, websockets follow an HTTP upgrade path and can't leverage datagrams.
An breaking update in the HTTP spec would be quite painful, especially for backend libraries that are often updated only when absolutely necessary.
The fact the API isn't even finished yet, let alone standardised, also makes it a good idea to add it as a new feature. I don't think browsers should mess with standardised protocols to implement some draft that's still in progress because they're very likely to break something, especially since this particular type of socket is only available to a small number of websites and use cases (those on servers supporting transferring raw HTTP/3 to the application server, so probably not most CDN/DDoS protection services).
Primarily load balancers and other cloudy middleware stuff. Most existing infrastructure is built on the request-response model (for good and bad). Maintaining a long lived connection makes more sense in the traditional single-beefy-server world, but with lambdas, containers, reverse proxies and everything being transparent and ephemeral it was too big of a game changer for cloud providers, in particular PaaS, I think.
100% this. Scaling websockets is fine if your app sees consistent load or don't mind paying for unused capacity.
While it's certainly doable, it's disruptive to horizontally scale websockets servers and depending on how you use it, can result in significant amounts of duplicated data transfer.
From cost and UX perspectives, it's just not worth it. Either use websockets and accept the fact that you'll always be paying for all the capacity you might need or give up and poll a low latency endpoint.
Isn't a viable horizontal scale solution to have a central allocator, that assigns a new client to a pool instance that then has a direct websocket with the client? So there's no central choke point or "websocket load balancer that all frames flow through"
That's how I've always done it for scalable deployments of my remote browser isolation service.
> The best way to experiment with WebTransport is to start up a compatible HTTP/3 server.
I'd really like a little more getting started advice here. I'm not sure which if any http3 implementations have webtransport support.
I went looking last week for webtransport support, interested in playing around. I thumbed through QUIC implementations[1], and came close to concluding I was just too early to try to use webtransport. Even though it shipped in Chrome 97, >9 months ago.
Does anyone know of any websites/applications that utilize WebTransport? The only thing I've come across are the Showcase demos from https://github.com/yomorun/presencejs
The lack of good examples mostly stems from the fact that there isn't really that many publicly available server libraries yet. The two I can name off the top of my head are aioquic (Python) and the Google QUIC implementation used in Chromium and ENvoy -- the latter is sadly not trivially embeddable by third-party code (I work on it, and I've been trying to make it easier to use, but given that it's a large C++ codebase with a lot of dependencies, this has been taking a while).
I think it's too new. HTTP/3 has only recently been standardized, and Web Transport is built atop that. New tech, not many users yet. I suspect we'll see many web games utilize this in the near future.
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 but have since verified it myself that at least Chrome v103 on Android 12 does indeed support WebTransport.
We’ve done some cool things with Pion, like running GIMP server-side and streaming it to a browser[1]. So thanks!
I’m not the one who worked directly with Pion so I don’t have direct feedback on it, but one thing I think would do a lot of good for WebRTC data channels becoming widespread is client and server nodejs bindings that abstract away all the complexity so that it is as easy as using websockets. If developers could implement this stuff without having to learn acronyms like TURN and STUN, I think it could be pretty popular.
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 and run my STUN server embedded in my HTTP server. I do do anything but point my `PeerConnection` at `my-service.com`
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.
I don't know of one. In my remote browser app where I stream the remote browser viewport over webRTC I just use simple-peer on the server and exchange connection info over websocket. It works well.
But then I test every xth frame to see if the peer or the socket is faster and switch to that. Websocket is often faster, but not always, so in practice I end up splitting the stream over both websocket and webrtc in real time.
> 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.
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.
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.
> 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.
> 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"
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.
> 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.
> 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.
> 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?
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.
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.
WebSockets is built on top of TCP, whereas WebTransport is built on top of UDP. This makes WebTransport better suited for handling latency-sensitive applications like multiplayer games.
Don't many modern web standards start off with a single browser experimenting and implementing something? This seems like a common criticism when it comes to new features that's disconnected from the reality of how web standards are made. If I remember right, proposals can't even progress to being considered a web standard by the standards groups until after multiple browsers have implemented it.
> Don't many modern web standards start off with a single browser experimenting and implementing something
Yes. Key word: experiment
> new features that's disconnected from the reality of how web standards are made
Ah yes. Disconnected from reality in which... a standard is not a standard until all parties agree on it, and there are at least two independent implementations before the standard is considered safe to move from experimentation stage.
No-no. We live in a new reality where Google couldn't care less about the process and release features with full disregard of any of that.
PWAs are a collection of standards, many if which are broadly supported. E.g. service workers. Additionally they are progressive so PWAs should be designed to function without the specific features.
You'd have to be more specific. As far as I know the main features service workers are supported everywhere, web manifests are supported everywhere, and as of iOS 16 this week push notifications are supported everywhere.
>As far as I know the main features service workers are supported everywhere, web manifests are supported everywhere, and as of iOS 16 this week push notifications are supported everywhere.
Manifests are not supported by iOS in any browser, making PWAs DOA for any serious app. And service workers/push notifications were not the promise of PWAs. It was that they would allow for seamless universal apps distributable in any app store (or outside of one). That has not, and will not ever happen without the other browsers onboard with manifests, which is likely never happening.
I don't think Apple disabling features that WebKit supports perfectly fine don't make PWAs nonstandard. Every other platform supports these, even Webkit-derived GNOME Web.
Firefox removed support for some obscure reason and Apple doesn't want to jeopardise its billion dollar app store but that doesn't mean most devices in the world don't support them. Just throw the PWA into a free, open source, prebuilt wrapper if you must please Apple, it's a lot less work than going the other way around.
> There's no such thing as a "PWA standard". There are half a dozen to a dozen various standards, and Safari supports the vast majority of them.
The parent talks about the webmanifest standard which is essential for PWAs (it describes the application and its package in a standard way). Safari does not support this, which is a pretty major standard to not support.
> Firefox usually clearly documents the reasons
I disagree. They state they have done user research (no information available on this) and that there is "little to no benefit" for a feature that was buggy and hidden behind configuration flags while at the same time enabling full support by default in their mobile browser.
> Ah yes, jeopardizing by ... supporting 99% of what passes for standard PWA features.
...except for notifications on iOS (which are coming, apparently, but it's taking them until somewhere next year) or A2HS on desktop (which they do support on iOS except in alternative browsers), which are pretty major limitations. The 1% remaining is still significant, the rest of the PWA standards Apple supports are just normal web standards that PWAs happen to use.
In all these discussions on HN the set of "essential standards" is always in flux, and is different for different people.
> They state they have done user research (no information available on this) and that there is "little to no benefit" for a feature that was buggy and hidden behind configuration flags while at the same time enabling full support by default in their mobile browser.
Because it's quite possible that it's buggy and confusing on desktop, but not so on mobile. Not so different from Safari, BTW which also has A2HS on iOS, but not on MacOS
> The 1% remaining is still significant, the rest of the PWA standards Apple supports are just normal web standards that PWAs happen to use.
So... The other ones are not normal web standards? Or are all web standards normal?
HTTP/2 Server Push is largely just a "bonus" on HTTP/2, and removing it isn't exactly going to break a ton of things. Any chance you're thinking of server-side events, which are still supported?
Yeah, in previous discussions I've seen about HTTP/2 Server Push, it seems like a lot of people are confused about what it was and thought it could be used to let a server spontaneously message a client (like you can do with websockets or server-side events). The only thing Server Push does is let a server respond to one request with multiple responses together ("I see you're requesting X, but I know clients who ask for X end up asking for Y shortly after, so here's Y with your X so you can cache it for later").
Server push doesn't let a server spontaneously communicate with a client like a socket does. It's purely an optimization to let the server include in a response to the client extra resources for the client to cache for later, possibly making it so the client doesn't have to request them later. If server push doesn't happen, then it just means the client might not have certain resources pre-cached and will have to request them later.
It's a shame server push wasn't used more often, it's such a simple and logical API to use (at least if you have the right reverse proxy installed). Add a Link header to the styles, fonts, javascript and whatever and your server will try to automatically push the resources necessary for rendering your page correctly to the client. Or configure your proxy to send the CSS/JS along with any file ending in .html, whatever you prefer.
Would this be a good API to communicate with say a local server that communicates with a native application, live the Native Messaging API for extensions?
I'm not sure I understand. UDP is connection-less so it doesn't matter if it's client-server. In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP
*> In a TCP connection, the client initiates the connection so that firewalls aren't an issue and that isn't a thing with UDP
That is a thing with UDP too.
Firewalls (whether NAT or SPI) keep track of connection state with UDP in a similar way to how they do with TCP. Because UDP doesn't have the TCP SYN/ACK/FIN/RST flags, those firewalls have to use simpler heuristics for UDP, but they do keep track of connections.
In detail, this means your client needs to send a UDP packet to your server, so that the firewall will add a connection entry to its table to allow more packets through in the server->client direction. Then your server needs to reply with a UDP packets back to the client's IP:PORT. After that there needs to be a steady trickle of traffic from the client, or the firewall will remove the connection entry. Firewalls vary, and some of them require the server sends from the same IP:PORT the client->server packet was sent to; some UDP server software fails to do this correctly, especially if the server has multiple IPs.
This makes sense with NAT, because it's required for rewriting the IP:PORT values as they pass through the NAT firewall. But even without NAT, SPI firewalls operate a similar connection table and block server->client packets if there is no connection entry created and maintained by client->server packets first.
With QUIC and HTTP/3 you can sometimes have a little more packet inspection than with plain UDP.
This asymmetry means the client-server concept exists for UDP in practice, the same as with TCP.
WebTransport wasn’t designed or “declared” by Google. It came through the IETF. I’m not sure who wrote the initial draft, but the WG chairs are at Google and Microsoft, and the current draft has authors from Apple and Facebook.[1]
I was there in the early BoF sessions for webtransport in Montreal / Singapore. We had dozens of people from all over the tech landscape chiming in and contributing.
The IETF is an open, participatory community. Claiming its run by Google is completely wrong, and honestly pretty demeaning to the work people put in to design specs.
If you want more independent voices at IETF, instead of inventing false claims to whinge about on HN, why don’t you be part of the solution and get involved? The mailing list for Webtransport is just a Google search away. Here it is now.[2]
It started in the W3C and the IETF group was added later. But thank you for pointing out that a lot of effort is put into making these standards a joint effort across the industry.
(I was one of the original authors in the W3C but left shortly after the BoF happened).
Doesn't matter where it came from. It's not a complete standard yet. Firefox's only reaction was "yeah, it's worth prototyping". Chrome just released it as if it was a finished and accepted standard.
Yeah, the browser can download a page via HTTP 3 - sure. My point is, I want to be able to use the full capabilities at my discretion from my JS code, not just a "dumb" fetch(...). HTTP 3 can do more than just offer webpages for download. And WebTransport is exactly that.
WebRTC is more complex than "simple client-server communication", but is it really more complicated than QUIC? It is literally just SCTP over DTLS with only a SMALL bit of ICE (I think almost none when using ice-lite) for the equivalent use case...
gQUIC != QUIC, though it definitely inspired it (the same way SPDY inspired HTTP/2).
QUIC went through the IETF and HTTP/3 is supported in all modern browsers now.
It also has a lot of technical advantages over previous versions. Google doesn't always do the right thing but I haven't heard a solid argument over why their contributions to QUIC and HTTP/3 are bad.
I'm with ya, but it wasn't just google. Google easily convinced the other megacorps like Microsoft that QUIC was good for their use cases and together they managed to whitewash it through the IETF. It wasn't just google. But it is just mega-corps. QUIC is a bad standard for human persons but excellent for corporate persons.
As for webtransport, this is the first time I'm hearing of it. My browsers definitely don't support it.
I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API.
People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.
You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person.
For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.
Let's Encrypt doesn't work with HTTP 3 or what do you mean?
Human persons need strong encryption much more than legal persons. Legal persons can't die/have their health damaged/be thrown in prison/be lynched by a mob. This is a way to make it available to everyone.
It's not hard to setup your CA and add a profile with it if you just want to communicate with other human persons and it must be HTTP 3. Of course browsers don't include random humans' CAs... I am happy about that.
And why don't you just use HTTP 1/2 over amateur radio? That your 0.0000001% usecase (don't tell me you yourself do it more often) isn't supported doesn't mean the whole thing is bad.
HTTP/3 is HTTP/2 over UDP[0]. The advantage of this is that packet loss no longer delays processing of independent streams: if you lose a packet of one image it doesn't delay processing the rest of the CSS.
HTTP/2 is HTTP/1.1+TLS with a custom binary encoding that allows stream multiplexing. This lets browsers download the image and the CSS over the same TCP connection without having to incur slow-start penalties every request. It's the reason why "reduce number of requests" is no longer good web dev practice.
HTTP/1.1 is the usual plaintext protocol people think of when they think "HTTP".
[0] Specifically a UDP overlay protocol that allows selective TCP-like delivery guarantees, called QUIC
Actually I've seen more and more evidence over the past two years that even with multiplexing, reducing the number of requests is still at the top of the list in improving page speed. It's the single most impactful thing that can be done.
I don't keep these bookmarked and I can't seem to find the really good one I remember seeing on HN but here's a random one: https://backlinko.com/page-speed-stats
I'd say reducing the number of requests is still a very high priority practice for web devs.
I may have misspoke. It's not bad advice to reduce your requests, it's just less critical.
In the HTTP/1.1 days, requests were so expensive that you could drop an order of magnitude in load time by aggregating your resources. Like, to the point where if you had a big JS library that only one page used, you'd aggregate it anyway, because TCP Slow Start is a cruel mistress.
Now, you'd probably want to do some measuring and comparisons first in that situation, because you might be able to get away with saving page weight on pages that don't use the library rather than aggregating it everywhere to save the request.
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".
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.
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.
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.
That's disappointing. I have a peer-to-peer application where I'd like to be able to use QUIC streams rather than the current SCTP-based WebRTC data channels. In particular, it seems to me that QUIC streams would be better for transferring files peer-to-peer in a way that takes full advantage of available bandwidth without causing congestion or doing excess buffering on the sending end.