fetch

ush enough, & that they were going to drop it. Without ever having tried to make it useful in the first place. HTTP/2 seemed to have such promise, was such elation finally getting released in 2015. Seeing so much promise go unfulfilled & then get cancelled has been quite dark. Unlike so so many of the alternatives that we are up to for data fetching, this path was both realtime & still http/resource centric. It still felt like core web architecture, in a way few others do. The unfulfilment of this destiny, this loss, has been jarring, & continues to leave us with these open quandries of what new entirely different alternatives do we invent, over WebSockets, over SSE, over WebTransport, &c. HTTP (almost) was here. [1] https://news.ycombinator.com/item?id=25064855 [2] https://github.com/whatwg/fetch/issues/51 Edit: there was a deleted comment saying that this kind of use case is not what Push was for, is not there to send unprompted data. Technically, Push can only be done in reply to a http request, so there is a factual limitation. Web Push Protocol gets around this by holding a GET open, to allow "unprompted" data. I think a sizable amount of engineers at the time were indeed thinking of Push as an optimization, a way to get pages to load faster. But this contingent of folks who saw HTTP/2 Push enabling pushing data capabilities, who were hungry for it, who counted on it's maturation: I think they had reasonable expectations, and that we're in a very weird place on the web, with HTTP technically having the ability to push semi-unprompted, but browsers never delivering that capability that's now inbuilt in HTTP. Using Push is still possible for so called unprompted updates even! At least it was till Push got removed. The trick is that the server needed some way to tell the browser which resources to send: so the server might be pushing resources, then using SSE to notify the page of those updates, for ex.