Hacker News Reader

Comment by echeese | Hacker News Reader

I hate to be pedantic but these are not push notifications. Those are the ones that can be sent even if the webapp is closed, for example, this Chrome demo: https://developers.google.com/web/fundamentals/getting-start...

View on HN

Sort of. There's nothing stopping you from using script inside a Service Worker to send those notifications. Calling them push notification is troublesome as the Web Push API and Notification API are actually two entirely separate things.

Ok we replaced 'push' with 'desktop' which is what the Github page says.

WebPush is (going to be) an IETF standard: https://datatracker.ietf.org/wg/webpush/documents/

Yikes, that really seems like abuse of HTTP/2 semantics to me. My understanding has always been that server push in HTTP/2 is only intended to prime the client cache for requests you know they're about to (or likely to) make. [1]

> Pushed responses are always associated with an explicit request from the client.

I'd rather see additional frame types defined that allow for bidirectional communication (i.e. websockets 2.0) than overriding and conflating the PUSH_PROMISE frame type.

[1] https://tools.ietf.org/html/rfc7540#section-8.2

I've built a plug & play app for Web Push Notifications. It comes with an analytics dashboard and an interface for users to manage their subscription. If anyone is interested to try it, you can see the demo at https://www.pushroll.com

unsure here but isnt it the same but in this case it is just not yet using a service worker to listen for new push notifications ?

Reply on news.ycombinator.com