From a pragmatic developer perspective, what's the alternative at this point? I was always hopeful that HTTP/2 Server Push might one day replace the need to have WebSocket infrastructure lying...
From a pragmatic developer perspective, what's the alternative at this point? I was always hopeful that HTTP/2 Server Push might one day replace the need to have WebSocket infrastructure lying around for applications that need live-emitting of data.
Is it really just a case of continuing with WebSockets?
They seem to be working alright. Are there major downsides? Also, from my minimal understanding of PUSH, it didn't seem like it was going to be a live-data thing, but rather a preemptive-loading...
They seem to be working alright. Are there major downsides?
Also, from my minimal understanding of PUSH, it didn't seem like it was going to be a live-data thing, but rather a preemptive-loading thing.
When it was introduced I certainly remember talk of how HTTP/2 push would be an easy way to replace WebSockets. There's no downsides to WebSockets, it's just more technical overhead and something...
When it was introduced I certainly remember talk of how HTTP/2 push would be an easy way to replace WebSockets. There's no downsides to WebSockets, it's just more technical overhead and something else to manage (usually you need a dedicated websockets server, etc)—and if you're a one person band, you've already got a million other things to do, so condensing things is usually a smart move if it's achievable.
Right, server pushes could only be combined with a response to a client-initiated request. The purpose of server push is for the server to say "I see you're requesting X, and I'm pretty sure...
Right, server pushes could only be combined with a response to a client-initiated request. The purpose of server push is for the server to say "I see you're requesting X, and I'm pretty sure you'll want Y too because of that, so here's Y included with the X you asked for". It can't be used for the server to initiate communications with the client spontaneously. For that, you can use server-sent events, websockets, webrtc, or the upcoming webtransport standard.
They posted an Intent to Remove a while back. It seems like the feature was being used by a tiny fraction of sites (<0.1%), and hadn't seen any increase despite the rapid growth of HTTP/2. Seems...
They posted an Intent to Remove a while back. It seems like the feature was being used by a tiny fraction of sites (<0.1%), and hadn't seen any increase despite the rapid growth of HTTP/2.
Seems reasonable enough to remove a feature that adds "significant code complexity" for no benefit.
Besides, weren't people harping on Google for making things so complicated that "no one else can compete"? This simplifies the HTTP/2 implementation.
The headline is kind of misleading because it's not dead; Firefox and Safari make their own decisions. If this feature were actually important then it would give the other browsers an edge. The...
The headline is kind of misleading because it's not dead; Firefox and Safari make their own decisions. If this feature were actually important then it would give the other browsers an edge.
The announcement seems to be based on what seems to be pretty solid evidence that almost nobody is using it? So though they are making this call, it's based on listening to input from everyone else. This seems to be a feature that only a few large websites were even interested in?
From a pragmatic developer perspective, what's the alternative at this point? I was always hopeful that HTTP/2 Server Push might one day replace the need to have WebSocket infrastructure lying around for applications that need live-emitting of data.
Is it really just a case of continuing with WebSockets?
They seem to be working alright. Are there major downsides?
Also, from my minimal understanding of PUSH, it didn't seem like it was going to be a live-data thing, but rather a preemptive-loading thing.
When it was introduced I certainly remember talk of how HTTP/2 push would be an easy way to replace WebSockets. There's no downsides to WebSockets, it's just more technical overhead and something else to manage (usually you need a dedicated websockets server, etc)—and if you're a one person band, you've already got a million other things to do, so condensing things is usually a smart move if it's achievable.
Right, server pushes could only be combined with a response to a client-initiated request. The purpose of server push is for the server to say "I see you're requesting X, and I'm pretty sure you'll want Y too because of that, so here's Y included with the X you asked for". It can't be used for the server to initiate communications with the client spontaneously. For that, you can use server-sent events, websockets, webrtc, or the upcoming webtransport standard.
They posted an Intent to Remove a while back. It seems like the feature was being used by a tiny fraction of sites (<0.1%), and hadn't seen any increase despite the rapid growth of HTTP/2.
Seems reasonable enough to remove a feature that adds "significant code complexity" for no benefit.
Besides, weren't people harping on Google for making things so complicated that "no one else can compete"? This simplifies the HTTP/2 implementation.
The headline is kind of misleading because it's not dead; Firefox and Safari make their own decisions. If this feature were actually important then it would give the other browsers an edge.
The announcement seems to be based on what seems to be pretty solid evidence that almost nobody is using it? So though they are making this call, it's based on listening to input from everyone else. This seems to be a feature that only a few large websites were even interested in?