Oh hey, bullying companies with threats of antitrust works. We should do that more often.
----
This is a really big deal, but it's also a little bittersweet, because Push Notifications very heavily motivate developers to introduce serverside components to apps that don't need them. Web Push is a standard where I can really see Google's influence, and I think it influenced the standard for the worse. It's a standard built around the way that Google and large companies build products, it's not built around indie development or hobby projects.
You can send a notification to whatever server is registered and it gets delivered to the phone, great. In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.
And yes, sometimes you do need a serverside connection for things like message notifications, but there are a lot of uses for notifications where you know upfront what the notification needs to say and when it needs to be shown -- and that's not supported. In my opinion because Google doesn't really think about that kind of architecture and the idea that you wouldn't contact a server alongside every user action is foreign to them.
There was effort for a while to get offline alarms, scheduled notifications, even scheduled actions working through web workers, but as far as I know that stuff has all died off. It stinks, because I regularly run into scenarios where I could probably flat-out replace an app on my phone with a website, and I can't even on Android, because I'm unwilling to set up an account system and start tracking a bunch of data. I'm happy we have something, but I'm still remembering the parallel world we lost, where it would have been possible to have a much broader push towards completely offline PWAs that never transmitted user data anywhere. The idea of being able to replace native apps with a static Netlify page is very appealing to me.
And maybe that'll change? But I'm not holding my breath; it seems like a lot of companies have decided that push notifications are good enough and that they were going to require user accounts anyway.
> In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE* tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.
Unfortunately, not schedulable as far as I know, the notification needs to be sent while the web worker is running. Again, I'd very much love be wrong about that, but I don't think there is any way for, just as an example, a habit tracking PWA to say "ask the user at 10:00AM every day if they've gone for a morning bike ride."
But you can get that behavior... if you set a web server and force the user to make an account and then log all of their habits in your server and then send out the notification yourself. Because... it's unfair for me to blame Google in this instance, I don't know it's their fault, but I do blame Google and I suspect it's their fault. I could be wrong though.
I don't know how fine grained you want your notifications to be, but you can get pretty far without storing user data by splitting notifications by topic on the queue, or by filtering client-side in the service worker itself.
But even then, the UX seems pretty bad; when I first created an app with web push, a few years ago, there was zero guarantee that notifications would ever show up, and they seemed to fall through very often, when the client (at least with Firefox Android) sits in the background; https://stackoverflow.com/q/60809681
i can't tell if the situation has improved recently -- anecdotally it seems like it's a bit better now -- but depending on what sort of notifications you want to push, that quickly becomes a complete showstopper.
> there was zero guarantee that notifications would ever show up, and they seemed to fall through very often, when the client (at least with Firefox Android) sits in the background
That could also be a longer conversation, but yeah, that was also my conclusion, and again... I don't have proof that this is Google's fault, but it stands out to me that notifications as they're built today are primarily useful for spammy advertisements and engagement requests and are extremely unreliable for everything else.
If your primary use case for notifications is telling the user that your blog published a new article or reminding them to check into their account or advertising a sale, then notifications are great; and you don't really care about reliability in that instance.
If you want notifications to be something the user can really rely on, ie calendar appointments, sign-in attempts, etc... they don't seem like they're trustworthy enough to do that.
Of course, we need those OS-level restrictions around notifications to stop abuse and spam, but that's only because it's super-easy to start spamming the user in the first place. And my pet conspiracy theory is that Google on some level looked at notifications and said "it's more important that it be easy for a blog to get somebody to click yes on this, than it is for us to build a transparent process to the user that would allow us to make the delivery more granular and more reliable." Instead of making it harder for websites to get notifications permissions in the first place, Google made them less reliable; the model is that you will have a bunch of sites that can spam you but they'll spam you unreliably.
Again, I can't prove that, and maybe things have improved, but it's just weird how the entire spec seems designed around advertisements/spam, even to the detriment of everything else.
You don't need an account and you can encrypt the message before queuing it on the server. Silly stupidity inefficient and won't work offline but it is quite easy to make a generic push message scheduling server that just pushes around blobs as requested by client-side code.
That's an interesting point. It's still pretty messy and inefficient, but you're right, you could at least get away with not exposing user data, even if you're still transmitting it around.
That's a good suggestion, I should play around with that some time.
Am I missing something? Firestore is an online database that requires setting up a Google account. It's sort of like responding to "I wish I didn't need to include a serverside component" with "Linode".
----
This is a really big deal, but it's also a little bittersweet, because Push Notifications very heavily motivate developers to introduce serverside components to apps that don't need them. Web Push is a standard where I can really see Google's influence, and I think it influenced the standard for the worse. It's a standard built around the way that Google and large companies build products, it's not built around indie development or hobby projects.
You can send a notification to whatever server is registered and it gets delivered to the phone, great. In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.
And yes, sometimes you do need a serverside connection for things like message notifications, but there are a lot of uses for notifications where you know upfront what the notification needs to say and when it needs to be shown -- and that's not supported. In my opinion because Google doesn't really think about that kind of architecture and the idea that you wouldn't contact a server alongside every user action is foreign to them.
There was effort for a while to get offline alarms, scheduled notifications, even scheduled actions working through web workers, but as far as I know that stuff has all died off. It stinks, because I regularly run into scenarios where I could probably flat-out replace an app on my phone with a website, and I can't even on Android, because I'm unwilling to set up an account system and start tracking a bunch of data. I'm happy we have something, but I'm still remembering the parallel world we lost, where it would have been possible to have a much broader push towards completely offline PWAs that never transmitted user data anywhere. The idea of being able to replace native apps with a static Netlify page is very appealing to me.
And maybe that'll change? But I'm not holding my breath; it seems like a lot of companies have decided that push notifications are good enough and that they were going to require user accounts anyway.