3 ms·

> 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 thin

> 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.

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.