Blink: Intent to Remove: HTTP/2 and gQUIC server push
groups.google.com
Blink: Intent to Remove: HTTP/2 and gQUIC server push
1–10 of 142 posts
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#2This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it.
With the variety of streaming options available now, it really seems antiquated.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#3This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.
It's too bad they didn't realize it sooner, or it could have been removed from HTTP/3 before IETF finalizes it. Probably too late now?
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#4So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages?
Crafting a fast website is going to be messy and difficult for a good while still.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#5This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.
Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#6So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.
Or use I guess (bonus: local caching still works).
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#7Server push never made any sense anyway for most subresources. The server doesn't know about the state of the browser's cache, so using server push for a subresource could cause it to needlessly push a subresource that was already cached by the browser.
Maybe it is useful outside of the browser context, e.g. in gRPC.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#8Do 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?
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#9So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.
A "fast website" is super-easy to create if you don't add dozens of megabytes of useless crap to each page.
Two decades ago: hardware was slower, bandwidth was far more constrained, and browsers didn't have so many features nor take up so much resources --- and yet the speed of page loading was often much better than it is today!
Indeed, most of the "problems" web developers complain about are self-inflicted.
Re: Blink: Intent to Remove: HTTP/2 and gQUIC server push
#10This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.
Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.
And the problem there is shoe horning RPC requirements into a hypermedia transport.
I feel we've made a big mistake following Google's micro service requirements for what should be a ubiquitous hypermedia back bone.
It's bewildering that so many smart people could end up conflating the two for our standard protocols.