Re: [w3c/push-api] Declarative Web Push: mutable field (Issue #391)

While we wait for an answer, I thought I'd try to once more explain why we think declarative plus mutable is necessary.

- Our platform experience with push has shown to us that purely declarative is not workable for many types of apps.
- Declarative push in combination with mutable, relative to imperative push, fully eliminates the possibility of intentional or accidental silent pushes. It removes the need for heuristics that will penalize a website for sending silent pushes as well. For that reason alone we think it's worth trying to move the entire ecosystem over to declarative push and therefore we want to make the opt-in as easy as possible.
- As stated before declarative push in combination with mutable allows for removal of the website's storage (including service workers) in certain scenarios where that may be necessary without impacting the website's ability to push an important message to the end user. (I don't really understand why this would not impact Chrome. What if the website went unused for over a year? Presumably there is some cutoff for non-persistent storage.) And note that even websites that go unused for that long might still need to deliver an important message, such as a government alarm service of some kind.
- Declarative push in combination with mutable indeed does not provide all the efficiency gains, but without mutable there's much less chance of adoption. With mutable you can adopt it from day 1 and easily polyfill in older user agents, slowly iterating towards a more declarative future.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/issues/391#issuecomment-2653670386
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/push-api/issues/391/2653670386@github.com>

Received on Wednesday, 12 February 2025 13:10:35 UTC