What is Declarative Web Push?

Declarative Web Push is a new proposal to improve the Push API by removing the need of a service worker.

Currently the Push API standard depends on Service Workers for many aspects:

1. In order to use the PushManager methods, like subscribe() and getSubscription(), you first need to register a service worker and get a serviceWorkerRegistration.
2. The push subscription generated in this way is associated to the service worker.
3. When you send a push message to a push subscription using the Web Push standard (RFC 8030) the service worker associated to that subscription is activated and the push event is triggered.
4. The JavaScript callback function defined in the service worker for the push event is executed and it should display a Notification to the end user (the developer is responsible for that, otherwise there is a fallback notification to prevent silent push).
5. When the user clicks the notification, the service worker is activated again, the notificationclick event is triggered and the JavaScript callback function should open a URL in a browser window.
6. There are also other aspects related to the Push API that are managed by service workers, like the pushsubscriptionchange event.

This means that the Push API, as defined in the original version, is heavily dependent on the service workers. However this has some drawbacks:

• Service Workers introduce a lot of complexity for developers, for example:
  • scope and difficulties on some CMS
  • difficult to update
  • unreliable when users clear browser data
• Some privacy concerns and increased battery usage since the JavaScript functions defined in the service worker can be executed even when the website is not open (for example, when a push message is received)

The new Declarative Web Push specification wants to solve these issues by allowing push messages to bypass the service worker and directly display a notification to the end user.

The steps for web push described above would become simpler using the Declarative Web Push specification:

1. You can subscribe a user to notifications even without a service worker and accessing the PushManager interface would be straightforward (window.navigator.pushManager)
2. The push subscription is not necessarily associated to a service worker (although a service worker in the root scope could access to the subscription created by window.navigator.pushManager and vice versa)
3. When you send a push message using the Web Push standard (RFC 8030) you can specify an HTTP header (Content-Type: application/notification+json) to opt-in to use the new behavior
4. When the browser receives the push message from the push service, detects the presence of a specific key ("web_push": 8030) in the JSON payload of the message that indicates a declarative push message and displays a notification directly to the end user without a service worker (based on the properties of the notification object in the JSON)
5. When the user clicks the notification, the navigation URL specified in the JSON payload of the push message is opened in the browser directly (the navigation URL is a new property introduced by the Declarative Web Push spec, which was not available for traditional Notification objects)
6. Other parts of the proposed spec are still evolving and it's not clear how the pushsubscriptionchange event or other parts of the current spec will be replaced.

At the time of writing, Declarative Web Push is experimental and is supported only by WebKit / Safari 18.4 Beta. Support for other browsers is discussed in their respective bug trackers (Chromium issue, Firefox issue).

Pushpad will consider supporting this new feature, ensuring backward compatibility, only when it becomes more stable and more widely supported.

For more information, check out the following resources:

• Discussion about Declarative Web Push on GitHub
• Pull request for adding Declarative Web Push to the Push API