They considered “2.0” and decided the ship was more sinking than going the wrong way. They explicitly decided to call it “WebTransport” instead, so the steering committee wouldn’t say “2.0” either but from IETF sessions they sure seem to consider it a competing technology and eventual replacement.
Edit: I do agree WebTransport will never compete or replace WebSockets for HTTP/1.1, since it won’t be implemented. Once you have the choice, WebTransport are technically superior to do the same job as WebSockets on HTTP/2 or HTTP/3. You at the very least save 2 bytes per frame. In best cases, the significant reduction in HoLB with congestion control is a big deal.
Once you have the choice, WebTransport are technically superior to do the same job as WebSockets
I disagree. WebTransport is great if what you wanted was a raw-bytes socket (with still more ceremony than needed on it, but past that you get raw bytes so it’s pretty good). WebSocket is a message-framed protocol that is useful in its own right.
Like WebSocket, WebTransport is a messaged-framed protocol that is useful in its own right for the same WebSocket type of bidirectional streaming with equivalent browser support. The IETF draft spec and public IETF WEBTRANS public minutes show how it very much can be used to replace WebSocket and that it’s top of mind.
Are you thinking QUIC or focusing on the datagram-only aspect of WebTrasport, perhaps? Do you disagree with the IETF WEBTRANS take or feel I got it wrong in the talk? Disregarding the elephant in the room, HTTP/1.1, where would you use WebSocket over WebTransport assuming both are available in HTTP/3 variants? Why?
This is the first I’ve heard of framing in the WebTransport context, and looking at the specs again I don’t see a mention of it. AFAICT WebTransport is some ceremony after which you can do raw QUIC (in either reliable or unreliable mode). You can of course layer framing in top of this so it’s more flexible than websockets which always have framing, but are you saying there’s also some kind of native framing (perhaps optional)?
Ah, sorry for being slow on the uptake, but I think I’m following now! I was focused on the framing aspect and being able to frame a message. A high level browser Web API that fields messages elegantly is a great point. Gotcha! It’s been floated and “add in future version” has been mentioned but the early interfaces do just have a few awkward “piping to and from” steps to approximate the Web API of WebSocket.
I tend to hand wave the web side, but it’s critical of course and you’re right pointing it out as a current gap. I saw it as a “growing pains” issue not a “will never have” but how nice the message receiving API gets is a great open question. Assuming WebTransport next adds a WebSocket-level message interface and HTTP/1.1 fades to the sands of time I could see it replacing entirely.
Great point that an elegant or at least message-usable web interface is a blocker for many, many uses. The transport layer has no issues I’m aware of for framing messages, so I’d expect we need Web API improvements that may be years away. It seems like some folk are hoping the “piping” tactics will work with the current interface but make it more flexible. I suspect a higher level messages API would indeed be quite nice, and a major aspect of usage parity!
I definitely wouldn’t say “websockets 2.0”
WebTransport is good and exciting, but it’s not a replacement for or competitor with websockets
They considered “2.0” and decided the ship was more sinking than going the wrong way. They explicitly decided to call it “WebTransport” instead, so the steering committee wouldn’t say “2.0” either but from IETF sessions they sure seem to consider it a competing technology and eventual replacement.
Edit: I do agree WebTransport will never compete or replace WebSockets for HTTP/1.1, since it won’t be implemented. Once you have the choice, WebTransport are technically superior to do the same job as WebSockets on HTTP/2 or HTTP/3. You at the very least save 2 bytes per frame. In best cases, the significant reduction in HoLB with congestion control is a big deal.
I disagree. WebTransport is great if what you wanted was a raw-bytes socket (with still more ceremony than needed on it, but past that you get raw bytes so it’s pretty good). WebSocket is a message-framed protocol that is useful in its own right.
Like WebSocket, WebTransport is a messaged-framed protocol that is useful in its own right for the same WebSocket type of bidirectional streaming with equivalent browser support. The IETF draft spec and public IETF WEBTRANS public minutes show how it very much can be used to replace WebSocket and that it’s top of mind.
Are you thinking QUIC or focusing on the datagram-only aspect of WebTrasport, perhaps? Do you disagree with the IETF WEBTRANS take or feel I got it wrong in the talk? Disregarding the elephant in the room, HTTP/1.1, where would you use WebSocket over WebTransport assuming both are available in HTTP/3 variants? Why?
This is the first I’ve heard of framing in the WebTransport context, and looking at the specs again I don’t see a mention of it. AFAICT WebTransport is some ceremony after which you can do raw QUIC (in either reliable or unreliable mode). You can of course layer framing in top of this so it’s more flexible than websockets which always have framing, but are you saying there’s also some kind of native framing (perhaps optional)?
Ah, sorry for being slow on the uptake, but I think I’m following now! I was focused on the framing aspect and being able to frame a message. A high level browser Web API that fields messages elegantly is a great point. Gotcha! It’s been floated and “add in future version” has been mentioned but the early interfaces do just have a few awkward “piping to and from” steps to approximate the Web API of WebSocket.
I tend to hand wave the web side, but it’s critical of course and you’re right pointing it out as a current gap. I saw it as a “growing pains” issue not a “will never have” but how nice the message receiving API gets is a great open question. Assuming WebTransport next adds a WebSocket-level message interface and HTTP/1.1 fades to the sands of time I could see it replacing entirely.
Great point that an elegant or at least message-usable web interface is a blocker for many, many uses. The transport layer has no issues I’m aware of for framing messages, so I’d expect we need Web API improvements that may be years away. It seems like some folk are hoping the “piping” tactics will work with the current interface but make it more flexible. I suspect a higher level messages API would indeed be quite nice, and a major aspect of usage parity!