2 ms·

As I commented yesterday[1], accelerating page loading was only one use case for http Push frames. Alas it's the only ude case Chrome ever acknowledged or cared

As I commented yesterday[1], accelerating page loading was only one use case for http Push frames. Alas it's the only ude case Chrome ever acknowledged or cared about or have ever seemingly recognized (in spite of it under-the-hood powering Push API). Push also could have been useful to replace theess of non-web non-resourceful ad-hoc protocols people have endlessly kept reinventing atop WebSockets/WebTransport/SSE/Long-polling to push things like new chat messages to the browser. The author cites Jake Archibald's struggle using Push for page loading. But Jake also was interested in expanding past this incredibly limited use case, and threw together a mini-proposal to let Fetch hear of incoming Pushed resources[2]. Chrome though largely have never acknowledged this desire, even though it's been asked for for ~7 years now. So the web is still request & response & there's still no natural obvious way for the browser to hear of new resources that are ocurring. Chrome didnt listen to developers, never let us actually use the feature, and now they're killing it, and we're stuck where we were two decades ago, scabling to figuring out what to do to get some bidirectionalism beyond request-response. [1] https://news.ycombinator.com/item?id=32514159 https://news.ycombinator.com/item?id=32514159 [2] https://github.com/whatwg/fetch/issues/607 https://github.com/whatwg/fetch/issues/607

chrismorgan 4y ago
> in spite of it under-the-hood powering Push API The Push API <https://w3c.github.io/push-api/ https://w3c.github.io/push-api/> is a completely different thing with absolutely nothing in common with HTTP/2 PUSH frames (Server Push), just like Server Push is nothing to do with Server-Sent Events. PUSH frames would be unsuitable for the Push API, which is all about not having to keep a connection alive. (The rest of your comment is still valid, though I reckon you overstate the practical usefulness/superiority of Server Push somewhat—sure, the ability to push multiple streams instead of just one is useful in some cases, helping avoid head-of-line blocking or subprotocol complexity, but in practice I suggest that most scenarios can’t actually use that power at all.)
- rektide 4y ago
  The only standardized implementation of Push API is Web Push Protocol, which uses HTTP Push frames to push new message resources. https://datatracker.ietf.org/doc/html/draft-ietf-webpush-protocol https://datatracker.ietf.org/doc/html/draft-ietf-webpush-pro... You've listed some fine advantages of Push frames, but the one most near & dear to me is that it is supported by HTTP itself & delivers http resources. This is an incomparable advantage versus everything else: slotting nicely into the existing ecosystem. With QUIC based semi-connectionless HTTP3, the advantagea would only have been further accelerated, no longer even needing a TCP connection to be maintained.
  - tehbeard 4y ago
    That's not a standardized implementation it's a draft spec that's years old and expired.
  - chrismorgan 4y ago
    Better link, https://datatracker.ietf.org/doc/html/rfc8030 https://datatracker.ietf.org/doc/html/rfc8030. I see now that I misunderstood what you were speaking of by “under-the-hood”. I was thinking about the developer-facing parts of the Push API, but you actually meant the bit in the browser’s control, opaque to the developer. I retract my quibble.

chrismorgan 4y ago

> in spite of it under-the-hood powering Push API The Push API <https://w3c.github.io/push-api/ https://w3c.github.io/push-api/> is a completely different thing with absolutely nothing in common with HTTP/2 PUSH frames (Server Push), just like Server Push is nothing to do with Server-Sent Events. PUSH frames would be unsuitable for the Push API, which is all about not having to keep a connection alive. (The rest of your comment is still valid, though I reckon you overstate the practical usefulness/superiority of Server Push somewhat—sure, the ability to push multiple streams instead of just one is useful in some cases, helping avoid head-of-line blocking or subprotocol complexity, but in practice I suggest that most scenarios can’t actually use that power at all.)

rektide 4y ago
The only standardized implementation of Push API is Web Push Protocol, which uses HTTP Push frames to push new message resources. https://datatracker.ietf.org/doc/html/draft-ietf-webpush-protocol https://datatracker.ietf.org/doc/html/draft-ietf-webpush-pro... You've listed some fine advantages of Push frames, but the one most near & dear to me is that it is supported by HTTP itself & delivers http resources. This is an incomparable advantage versus everything else: slotting nicely into the existing ecosystem. With QUIC based semi-connectionless HTTP3, the advantagea would only have been further accelerated, no longer even needing a TCP connection to be maintained.
- tehbeard 4y ago
  That's not a standardized implementation it's a draft spec that's years old and expired.
- chrismorgan 4y ago
  Better link, https://datatracker.ietf.org/doc/html/rfc8030 https://datatracker.ietf.org/doc/html/rfc8030. I see now that I misunderstood what you were speaking of by “under-the-hood”. I was thinking about the developer-facing parts of the Push API, but you actually meant the bit in the browser’s control, opaque to the developer. I retract my quibble.