Into The Box Notes: Building Progressive Web Apps - Raymond Camden

April 29, 2018

“Building Progressive Web Apps”
by Tal Ater
Buy this book!

What’s a PWA?
Progressive Web App
all about building features that don’t break in older browsers

don’t limit to thinking it’s just for an “app” like a banking app
regular websites can also benefit from all of this

it’s a marketing term ala “Web 2.0”
set of guidelines and technical baselines

guidelines —
progressive
responsive
works offline, or in POOR network conditions
“network status” is not a boolean!
you can be in a modern part of the world and have a terrible network connection
think about multiple layers of how your data is being sent across the wire

app-like

fresh content

safe - https for everything, it’s 2018, just DO it.

discoverable — can be indexed and found, allows Microsoft to scan for PWA’s and add them to the store, etc.

reengage-able
“hey i have new content for you, come back!”

installable

linkable
it’s on the web, duh.

make sure if i’ve navigated to part of the PWA and bookmarked it, those bookmarks work

the tech stack —
manifest
service workers
app shell

manifest -
aka “web app manifest”
just a JSON file
allows for “installable” web apps
controls behavior of what happens when a website gets “installed” or the home screen is saved on your device

manifest consists of
name as it appears in the shortcut
icons of various sizes, ipad, retina, android, etc.
- there is a bare minimum you need the rest are optional

splash screen and colors (background and toolbar)

chrome
what you see around the website
regular browser, or if you want to hide all of that

can force orientation - i.e must be used in landscape, etc.

the starting URL —
(handy for passing a param to note the launch has started)
—https://something/idex.html?utm_source=blah

service workers —
this is the BIG part of PWAs
just javascript, kind of
registered via another script - weird

now, forget all that you know about javascript

you load foo.html
has some script tags in them
code executes, can respond to events, respond to a schedule, etc.
when you close the tab, that javascript goes away

service workers
will automatically run in EVERY page in its SCOPE
page A can load a service worker
every page in that same directory can run that too
“I will be active for everything in my current folder and subfolders”
typically, Service Worker is always in the ROOT of a site
so it can take control of the root of the site and all below it
Service Workers have this idea of “installation”
b/c they are powerful, they’re not allowed to change the website, etc.
only allowed to do “setup” stuff on first visit
on 2nd+ visits, can do more powerful cool stuff
can be annoying while testing - you load once and it “doesn’t work”
that and “scope” will trip you up the most

can run even when you’re NOT on the page
can still do stuff even when you’re not in the browser

can intercept every single network request (not just ajax stuff)

gives direct access to the browser cache
never had a JavaScript way to access that cache before, now we do

can fire notifications and respond to push notifications
can help you sync data

can NOT touch the DOM (but there is a way around that)

you can (and must) check for support
requires https, but localhost is ok

Service Worker applies to a directory and ALL below it in sub directories

register a service worker:

Caching —
Cache Storage API

[code demos]

what if you want to change a file?
don’t change a file. boom.

cache strategy patterns exist
but you have to figure out your strategy first

workbox:
developers.google.com/web/tools/workbox
“the offline cookbook” — good book about this stuff

(hipster web server for local host stuffs)