I saw Matt Gaunt give a talk on Web Push at SFHTML5!

SFHTML5 is a San Francisco meetup.com users group to do with, yes, you guessed it, HTML5. On August 25th, I went to an SFHTML5 event at Google's offices in San Francisco and saw a Matt Gaunt speak on push notifications which are those little rectangular boxes that popup telling you that something new has happened at your Facebook account. (not just Facebook/other apps too) They appear even when you don't have Facebook open at your browser because they are using service workers running at the browser itself. When I shake my Windows-10-running Dell XPS laptop awake I even see these before Google Chrome is ever opened which is kinda nosebleed inspiring. I once went to a talk on using JavaScript to interface with an API for the "Metro" stuff of Windows 8 and this same sort of thing must exist for Windows 10 and service workers cross-talking with it must make the impossible possible herein. The talk didn't dive into that though. It was in many ways more elementary and yet with that came a geek out on how authentication works in this paradigm. There is a GitHub Org (an organization: boundaries and rules around group-owned repositories) called web-push-libs which, amongst other things, has web-push-csharp, and Matt heavily encourages you to use this stuff in lieu of writing something yourself that identity, called PushSubscription in this space, and public and private keys get tangled up in. Web Push is a node library for this stuff. At the very end of this talk came thoughts on bad UX and that honestly might make a for a good place to start talking about this stuff as the bad way to go probably seems normal by now. When you first visit a web site in Google Chrome and are prompted with "news.vice.com wants to: Show notifications" and buttons for "Block" and "Allow" are there this is the notification permission opt in step. This terse messaging and immediate coercion is bad. Elsewhere on a site there should be a better explanation for what you might opt into and this should be aesthetically presented and not be the first thing one sees. Also the site should have a way to turn push notifications off and this too is normally lacking in bad (all too normal) UX which forces users to go digging in Google Chrome's settings for the turning off service workers. By the way, "Service Workers" beneath "Application" is where to see the service workers running at Google Chrome listed at Google Chrome Developer Tools. Another example of bad UX is having a notification that tells you that Facebook is telling you that you have a message and then giving a link off to Facebook which redundantly tells you "facebook" at the URL. Try to maximize your use of limited real estate and not give vague clickbaitesque messages. Alright, now having talked through how things materialize for average Joe, the behind the scenes magic for the developers is such that a web site will send a push notification to a cell phone by way of sending a PushSubscription to a Web Push Protocol which then talks to a Push Service which talks to the cell phone. Upstream of this we obviously need to request permission to make toaster toast spring up and this is done with Notification.requestPermission() in the applicable API. After getting permission but before the web-site-to-web-push-protocol-to-push-service-to-cell-phone game may be played there is a step in the middle in which a Service Worker must be registered. A service worker is basically a JS file that tells a browser there is an intrinsic link between a web site and the JavaScript in the file. When the browser receives a notification it has to ask itself "Does this web site have this service worker?" and if the answer is yes we're in for some charming little messages. TTL Headers in notifications can spec a time to live. (TTL, get it?) If you want to tell someone about an immediate sale that just lasts twenty-four hours but they have their cell phone off for three days while they are pretending to hate capitalism and modernity during some soul searching (if people have souls) you don't want to inform them off the golden opportunity they missed when they rejoin neonowness. That would just be mean. Mozilla Firefox was recommended for troubleshooting and debugging (it's back!) as it actually uses Web Push whereas Google Chrome is using FCM (Firebase Cloud Messaging) which is much more opaque in its error messages in this sphere of things. I enjoyed going to Google and chitchatting with others before this event started. I learned that an "ecstatic" web site uses AOT and maybe a CDN and I learned that Google's Progressive Web Apps are reliable, never show the downasaur, and utilize good practices for distributed computing. I also met a guy who rather bafflingly feels most comfortable just working with JavaScript and not the modern frameworks or even jQuery and when I asked him how painful it is to use XHRs he explained to me that you don't have to do that anymore and that you may just use .fetch for AJAX instead in all the modern browsers. This was naturally news to me because I don't even want to think about tackling AJAX without jQuery or Angular/Observable. I kinda haven't wanted to think about push notifications either, truth be told, but here they are and they're not going away. This was a good introduction. Thanks Matt!

 
 

Addendum 9/7/2017: I may be wrong about what I say above about the Metro stuff. I found a Stack Overflow thread that suggests that if even one of your Google Chrome extensions has the "background" permission that the notifications can make it through to you even if you do not have Google Chrome open. There must be, in these cases, something else running in the background all the time (and in your list of apps to spin up upon startup on the other side of a reboot) that has the service worker needed registered and doing its thing.