[The_rationalist]

Do web-transport obscolete push? https://w3c.github.io/webtransport/

I had read a technical comment once that told that HTTP 2 push was superior to websocket but couldn't remember why. Also what's the difference between push and server sent events?

[johncolanduoni]

Web transport isn’t used for transferring HTTP requests/responses by the browser. It’s essentially an expansion of WebSockets to include multiple streams and optional UDP-like delivery, while still being encapsulated in HTTP/3 and suitable to be called by JS. Server sent events similarly only works if you have JS on the client receiving it, the browser doesn’t know how to render the events inherently.

[peterwwillis]

WebTransport is the kind of stuff that makes me lose faith in the capacity for humanity to consciously evolve.

It's like your great-great-great-grandparents built a house out of brick. Each new generation there's more people. Everyone wants to live in the same house, but they can't all fit. They try to build the house larger, but it will only work so high with brick. So they start shoving tin and iron and steel into each new floor to reinforce it. Eventually you have a skyscraper where the top floors are built out of titanium, and the bottom floor is several-hundred-years-old brick. But hey, we have a taller building!

You could say this is a perfect example of evolution, like big bright red baboon butts. But if the evolution were conscious, we'd want things to improve over time, not just make the same crap scale larger.

[johncolanduoni]

Or maybe, people want to do real-time networking in the browser without having to delve into the mess that is the all-singing, all-dancing WebRTC? Or they want battle tested protocol encryption libraries and flow control in their native app that can do unreliable and out of order delivery?

It’s great fun to write these metaphors about HTTP/N and friends, but the last one improved network performance for mobile devices very substantially while half of HN was jeering at it. There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples.

[skissane]

> There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples

I'd love to know which RFCs you'd call "camel-like"

[johncolanduoni]

I was referring to "a camel is a horse designed by committee" :P

[skissane]

I was asking which IETF standards you would describe by that phrase.

[saurik]

WebRTC does not seem intrinsically more difficult to work with than WebTransport (as someone who works with WebRTC daily at super low levels and also has read about WebTransport and even watched talks about it at the standards committee and is now just annoyed as they didn't even have the decency to replace all of the WebRTC data channel use cases :/). WebRTC is actually a ridiculously easy stack: it is seriously just SCTP over DTLS (with a small bit of ICE, to maintain the connection, that isn't really required anyway). To the extent to which the code sucks--and that's frankly the core problem literally everyone has with it--it can be fixed pretty easily rather than tacking more BS on top, but somehow everyone wants to fix it with new specifications rather than improving the engineering (which I think is related to the problem the other comment brings up); even just some better build engineering would make it easier to compile (which is the #1 reason people seem to hate on WebRTC, not that it is actually *that difficult to compile... but it certainly isn't an invalid complaint).

[duskwuff]

> Do web-transport obscolete push?

No, it solves a completely different problem.

HTTP/2 Server Push is a mechanism where the server can send HTTP responses for resources it believes the client will need soon. (For example, if a client has just requested a web page with a bunch of images on it, the server could use Push to send those images without having to wait for the client to encounter the image tags and request the associated image resources.)