Progressive is a fancy way of saying we add features that enhance the experience for people who support it and do NOT break for people who don't. The "net result" for that is we can use kick butt new features for the browsers because we know - absolutely - that if you don't support them - you can still use the site w/o any problem at all. I'm an old guy and I can remember years of "oh, this browser supports X but I can't use it because it's only available 15% of the time" - and I love being able to kinda say "so what" to that.
Web - I really hope I don't have to explain what the web is.
App - and here's the part where I disagree - strongly. I dislike the fact that a lot - not all - but a lot of discussions about PWAs focus on "web apps". Things like To Do lists or maybe your banking account. You can absolutely make use of PWA principles for non "appy" type stuff. So for example, the app I'm demonstrating at the end is a content site. Not an "app" at all. And that's totally fine. Basically I want you to think of the things we're covering today as improvements you can do to *any* site.
a term! yes - that's probably kinda dumb, but in some ways, this is a bit like how "Ajax apps" and "web 2.0" was a thing for a while. We used it as a way of describing apps that used certain technologies (like XHR) to make for better sites
Two people There are a set of guidelines that a PWA *should* follow and I'll discuss them in the next slide On top of that - there is also a set of 4 baselines that Russel used later as a "must" have. I'm probably not going to cover that because I don't want you to go ino this thinking, wow I did 3 of the 4 things and I don't have a PWA - I am a horrible, horrible, person. Heck no. If you do ONE thing to make your site better than you should be very HAPPY about that and don't use an arbitrary list as a marker for failure or success.
Progressive - we covered this already - basically don't break for older browsers (legacy) Responsive - looks good on mobile Works offline - multiple thing here to consider but note the bold text - there is MORE than just online, offline App-like - im going to kinda throw my hands up here and say "take that as you will" - I've already discussed my thoughts about "app vs content" sites and I think if your PWA looks like a blog because it IS a blog, that's ok with me Fresh - basically not serving stale content - we'll talk about that when we cover network crap and service workers in a ssec Safe - https. Done. DO it. It's free. Just - do it. And the tech I'm discussing today simply doesn't work on http. Period (although note you can run it on localhost) Discoverable refers to manifest files that identy a PWA to the system as something the user can add to their home screen - that's a tech we'll cover called manifests Re-Enagleable simply means the PWA brings you back and that's done via push Installable means being able to add to the home screen which comes back to manifests Linkable - URLs - the good ole tech - in theory you don't even have to think about this. If you ARE building an app though you need to think about app state and things like - if Im on tab 2 of my app - can I share that URL with you and when you load you get tab 2 as well..
So what does our tech stack look like?
The first is the manifest - a simple JSON file that describes our app at a meta level. This is what will allow us to "add to desktop" and get things like icons and the such.
Service Workers are the main way we'll work with the network. This is INCREDIBLY powerful. I'll be describing how they work, what they can do, but there is no way in heck I'll be able to go over every single aspect of it. Rather I'm going to give you the lay of the land so to speak. To be honest, that's more appropriate anyway right? As a developer, I want to do know I can do X with Y and I'll Google for the actual code when I need it later.
And then App Shell.... so again - I've made my feelings known on this. If you are building an app and using a modern framework like React, Angular, or Vue, then you have this baked in (technically not with Vue, you have to add stuff above the base support, but that's ok cuz Vue is awesome). So going back to what your working with - if it is an app - you will want to ensure the base HTML, CSS< etc loads immediately and content loads into the shell as you request stuff.
technically the web app manifest luckily - just a JSON file that you'll link to from your html It allows you to create an "installable" web app. Now installable is in quotes for a reason. Your web site isn't being "installed" like a native app on your device. Rather, it's like a "super" bookmark - you have control over how the web page runs when launched from the manifest - by control I'm talking mainly about how it looks - it's not magically adding native like features ala Apache Cordova or Ionic.
In terms of what you can control with the manifest
first is the name as it will appear on the home screen of the device, so your blog may be: The Many Wonderful Adventures of Raymond Camden and his too many kids - but you probably want something like "Ray Camden" when saved to the home scree you can also specify icons for different device type resolutions splash CHrome of what you see - not the browser - basically two choices with the default being a regular browse experience or full screen (what the manifest calls 'standalone') finally - you can specify a starting url - and the typical use case here is to add a query param like
Ok, I've got two demos here. Show manifest1 and manifest2
SHow manifest one, show Chrome dev tools
Unfortunately - this isn't enough to get to the "Add to Home Screen" functionality
event lets you determine if the user added it or did not, AND actually lets you defer it. So if you don't want Chrome to auto prompt, you can actually save the event and fire it yourself later, like via a button click
To be clear - this is for a MANUAL test
Secondly - this is a script (written in JS) that is registered via a script (written in JS). So basically what this means is you'll use your regular JS, like your app.js that you have for your site, and you'll say, over here I have serviceworkerawesome.js, I want you to use this as a SW
Notice I have the script tag - cuz we're not talking about some new language - instead were talking about JS that behaves in a way you aren't used to
SW have an idea of scope, basically a way of saying, I want to use a sw for ALL of foo.com, which is what you would normally do, but you CAN, if you choose, use them in a subdirectory, like /app or somesuch. But here's the thing - when registered, they always run
And if you leave your site and go to CNN.com, they still live. this is how stuff like push notifications can work to be clear, it is NOT persistent - so you can't store data in a persistent way there (but the browser already supports that)
they are -in essence - a proxy server
flip side is - they can't touch the DOM - there's ways around this
progressive - dont forget it chump
Second thing to note is - they have a life cycle you load a SW - and it becomes after you edit the SW to add some function you reload - and the new SW does NOT become available immediately- that's cuz you have one installed already that was running when the page loaded. It will only load when you've closed down the browser or navigated *away* from the site (technically scope) You CAN use devtools to get around that - thank god
Reminder about it being in your 'main' JS
SHow sw1, show the debugging of the SW It does nothing but it's there - woot
First demo sw2 OFFLINE purpose is - showing the proxy effect
then show sw3 showing it working show add to homescreen in desktop
Great! We have a cache It works offline
Tags are registered ONCE only
Notification - NOT just a PWA thing Request permission Show a modal
icon buttons vibration tag == silent update (plus renotify - shake) stuff not supported - wake screen, sound, silent
Note - I'll share more resources at the end
Building a PWA - For Everyone Who Is Scared To
BUILDING A PWA
F O R E V E R Y O N E W H O I S S C A R E D TO. . .
OK - BUT *WHAT* IS IT?
• A term
• Coined by Frances Berriman and Alex Russell in 2015
• Set of Guidelines
• Technical Baseline
• Works offline, or in poor network conditions
THE TECH STACK
• Service Workers
• App Shell
• "Web App Manifest"
• Just a JSON file (woot!)
• Allows for "installable" web apps
• Controls behavior when launched
• The name (as it appears in the shortcut)
• Icons (of various sizes)
• Splash screen and colors (bg and toolbar)
• Forced Orientation
• The starting URL (handy for passing a param to note the launch)
ADDING TO HTML
• <link rel="manifest" href="/manifest.json">
(AUTO) ADD TO HOME
• AKA Web Install Banners
• *Current* criteria is:
– manifest with short_name, name, 192x192 icon (png only), start_url
– service worker
– "Meets a site engagement heuristic defined by Chrome (this is regularly being changed)."
• Event is fired: beforeinstallprompt
• Details: https://developers.google.com/web/fundamentals/app-install-banners/
• Doesn't support manifest :(
• But you can configure...
SERVICE WORKERS - INTRO
• A script registered via a script
• Now - forget everything you know about <script>
• You load foo.html
• foo.html is all like <script src="ftw_js_is_awesome_unicorns.js"></script>
• Code executes while the tab (window) is "alive"
• Close the tab and ftw_js_is_awesome_unicorns.js goes bye bye
SERVICE WORKER JS
• Runs in parallel to pages in it's scope
• Can't actually do anything the first time it loads
• Can run when you're not even on the page
• Can intercept every single network request (to be clear, not just XHR)
• Can work with the browser cache
• Can fire off notifications while you're away (and you totally won't abuse this)
• Can respond to push notifications (and you totally won't abuse this)
• Can help you sync data
• Can't touch the DOM
MORE SERVICE WORKER
• You can (and must) check for support
• Requires https, but localhost is ok
• They have a life cycle
• Devtools will be very, very helpful
• You want to change a file
• You only want to use the cache if offline
• You want some mix of things where you use the cache first then network but then
sometimes you want to hit the network first and then cache and oh yeah maybe you
want to use the cache and that's cool but maybe you want to hit the network in the
background and passively update stuff and oh my god does this end?
GOOD NEWS/BAD NEWS
• Good News: Caching Strategies exist
• Bad News: You're responsible for figuring it out
• See "The Offline Cookbook" -
EXCEPT ROUND TWO...
• iOS - no support for Service Workers
• But officially "in development" for WebKit
• Another ServiceWorker feature
• App js tells SW js - "hey, start syncing Foo"
• SW says - "Ok, no problem. I'll get around to it."
• SW will try to do Foo (you write the logic)
• If it fails, it will try again (and again...)
• Finally, it will try one last time and *tell* you as well
• User subscribes to push messaging (two step process)
• Your server sends a message to central Message server
• Messaging server talks to Service Worker
• Service Worker does whatever (probably Notification)
SAFARI AND PWAS
• Supported in betas for macOS (really, we’re calling it this now?) and iOS
• Service Workers (Caching) and App Manifests
• No Push or Sync
• And it gets better: https://medium.com/@firt/pwas-are-coming-to-ios-11-3-cupertino-
• Email me at email@example.com
• Visit my awesome blog at raymondcamden.com
• Follow my awesome Twitter account at @raymondcamden