React Browser Notification vs. React Desktop Notification: Choosing the Right One for Your Needs

Integrating a notification system into your React codebase is already a heavy lift, so taking time to figure out exactly what type of notifications you want to deploy is imperative to the process.

Rather than just bombarding users with that little white notification box asking for permission, you can give them a better experience by letting them know how notifications will improve their experience.

While notifications have become standard on mobile devices, web apps haven’t adopted them in quite the same way, failing to keep up with mobile counterparts. The data you have on your users—such as their operating system, devices, and navigation habits—can help you decide whether you want browser, desktop, or both types of notifications.

One thing to keep in mind as a basic overview is that a React web push notification mimics mobile push notifications, and a React browser notification mimics mobile in-app notifications.

We’re going to take a look at each one and how they can integrate into web apps.

As Salt, Pepa, and Spinderella would say: Push it

Web push notifications can be sent to a user’s desktop even if your web app isn’t loaded, focused, or in the foreground.

These notifications can provide information, alert to forgotten tasks and follow-up requests, or remind users about active deals. Web push notifications are noticeably comparable to their mobile counterpart, which means there are rules regarding permissions and engagement.

Regardless of how awesome you might think your notifications are, users still need to opt in to receive them. Once you have permission, you can send notifications to the user if their browser is open, even if they don’t have your web app up. Permission has to be granted per browser—if you’re granted permission in Chrome, your notifications won’t show up in Safari until a user also grants permission there.

We won’t get too much into the strategy of web push, but generally speaking, there are three main types of web push notifications: alerts, segmented, and trigger-based. And these types encompass notification categories for all product types, like new deals and promotions for e-commerce sites, new tasks assigned in workflow tools, and follow-ups needed for business tools.

Aside from strategy, the implementation and support of this technology should guide your decision on whether or not to implement it. Web push notification didn’t become widely supported across browsers until 2019, and it differs between devices and operating systems.

In addition to your React front end, you’ll need service workers and a server to send web push notifications. A third-party tool like Firebase Cloud Messaging or MagicBell offers JavaScript support and can be implemented for web push notifications.

If notifications aren’t your core business, using a third-party tool will lift some of the load to create and maintain these systems.

If you didn’t want to implement a third-party tool, a custom solution with the Push API is another way to go and will probably come up when searching for web push implementation strategies. But it’s important to know this API is still in an experimental stage and is not fully supported, with no support in Safari—Safari has its own push API for desktops.

Even with third-party tools like Firebase Cloud Messaging, you’re limited by the same Push API compatibility.

While people have been waiting for years for Apple to roll out web push for Safari iOS, Chrome’s version 80 update has already tightened the notification strings and created a “quieter” notification permission UI to deal with web apps that spam users with permission requests.

“[W]ith the quieter notification prompt, it's possible to continue your browsing journey without making any decision at all if you wish, and the prompt is easy to dismiss, less intrusive of the viewport over the web content.” — PJ McLachlan, Google Chrome PM

To avoid a spam-like reputation, forgo the native opt-in and partner with a designer and copywriter to create a customized experience for your web app. This can be a curated notification message, much like the native opt-in, but much better designed.

Another option is to have a small banner with some text on top of the page that requests users to engage. These banners can explain to the user why notifications are a beneficial part of the experience, and once a user does engage with the banner, the native or customized opt-in message can appear.

On Safari, there is a double opt-in message that appears after interacting with the initial permission request. Since web push notifications can be confusing for a user to turn off, Safari makes it clear where a user needs to go to unsubscribe.

Since unsubscribing is different between browsers and systems, try to make it clear to your users how they can unsubscribe. People may be more willing to try notifications if they know they can easily turn them off.

Desktop push’s less spammy cousin: React browser notifications

Browser notifications can’t be sent to a user when the web app is not loaded, but they can be sent to a user even if they’ve switched tabs or switched to a different web app. Because these notifications appear when users are still actively using the web, they can be seen as less invasive from a user perspective.

Does anyone fully quit their browsers anymore, or do we all just close them out instead? Seriously asking.

The Notifications API is more widely supported than the Push API but is still not supported on Internet Explorer or mobile browsers. The mobile counterpart of a React browser notification would be in-app notifications on mobile. If your product has an app, you’ll be building your in-app notifications there instead of on the web.

But the Notifications API can be used to mimic your app’s in-app notifications on your web app.

Since opt-in consent is a best practice for any type of notification, just like the Push API, the Notifications API runs on a consent-based system. In the same vein as Chrome cracking down on spammy desktop notifications, Firefox v72+ blocks all notifications that aren’t explicitly granted permission by the user. To receive permission from your user, the

Notification.requestPermission() method can be sent in response to a user action, like clicking a permissions button. This returns a promise of granted or denied—if a user choice is unknown, it will return default and act as though permission was denied.

The Notification API also uses service workers, but instead of being invoked through service workers like push, this type of notification is the action of the service worker that displays information.

Although there’s a crossover between desktop and browser notifications (follow-up requests and reminders), because the expectation with a React browser notification is that a user is on your web app, there’s more opportunity available.

Notifications can be sent with tips on navigating the site or points of interest.
With over 9,000 downloads a week, React-web-notification is an extremely popular go-to solution for the implementation of the Notifications API. Visually, these notifications won’t look different from the examples in the previous section. The standard design is true for both types of notifications:

Picking a solution for your web app

Deciding what notification solution to include in your web app might not start with you. If you’re already at the implementation stage, these decisions have most likely been made and handed down to you. But that doesn’t mean they’re infallible decisions.

Knowledge gaps and silos exist, especially when it comes to data, so sharing knowledge and opinions with decision-makers can be useful. Start with the data. Examine user behavior and make conclusions about how notifications will help them.

Did a lot of users leave an item in a cart and not check out? This would be a good use case for a React desktop notification.

If a user closes your web app without purchasing the item in their cart, a timed notification after 24 hours might entice them back to the site to make the purchase. Did a user navigate to a very specific page and then navigate out immediately? This would be a better use case for a React browser notification. The next time the user interacts with the navigation, a message can be sent giving them tips on how to navigate the site.

Another data point to consider is device and browser compatibility. If we’re just looking at the Push API and the Notification API, if the majority (or a solid portion) of users are on Safari, you’d have to weigh whether taking the time to implement the specific Safari Push API in addition to the Push API is worth it.

If your product revolves around social media or news, your users are more likely to continue to enjoy and engage with notifications, according to data from HubSpot. These types of products will probably have more users opting into desktop notifications. If this isn’t you, maybe consider the less intrusive browser notification.

Need more information? Check out all our resources about React Notifications.

Improve your notification offering

Workflow notifications are some of the most important notifications in someone’s day-to-day. Can you imagine if Slack didn’t send notifications and you had to go back to the app to see whether someone needed something from you? 💀

MagicBell is a notification system for workflow tools. With both in-app, web and push notifications as a part of the free-tier service, MagicBell can integrate into your product in less than an hour and get users the notifications they need to keep their workdays on track.

Sign up and start free today.

Related articles:

• How to Implement React Native Push Notifications with Firebase
• Building a React Notification System: What You Need to Know