Building a PWA - For Everyone Who Is Scared To
•2 likes•844 views
Download to read offline
Report
My slides for my introductory PWA (progressive web app) talk.
Recommended
More Related Content
What's hot
What's hot(20)
Similar to Building a PWA - For Everyone Who Is Scared To
Stapling and patching the web of now - ForwardJS3, San FranciscoChristian Heilmann
12.9K views•65 slides
Similar to Building a PWA - For Everyone Who Is Scared To(20)
More from Raymond Camden
More from Raymond Camden(10)
Recently uploaded
Recently uploaded(20)
Building a PWA - For Everyone Who Is Scared To
- 1. 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. . .
- 3. FOOD TIPS
- 5. DO EAT GUMBO • Chicken and Sausage • Seafood
- 7. EAT BOUDIN!
- 9. JUST EAT IT! T R U S T M E !
- 10. RAYMOND CAMDEN • Senior Developer Advocate for Auth0 Extend • Auth0 Extend, serverless, web and Enterprise Cat demos • Blogging at raymondcamden.com • Tweeting at @raymondcamden
- 11. THE PLAN • Cover the basics of PWAs • Show an example • Do this in <50 minutes
- 12. THE GUIDE • By: Tal Ater • http://shop.oreilly.com/product/06 36920052067.do
- 13. WHAT THE HECK IS PWA? Progressive Web App
- 14. OK - BUT *WHAT* IS IT? • A term • Coined by Frances Berriman and Alex Russell in 2015 • Set of Guidelines • Technical Baseline
- 15. GUIDELINES • Progressive • Responsive • Works offline, or in poor network conditions • App-like • Fresh • Safe • Discoverable • Re-engageable • Installable • Linkable Source: https://en.wikipedia.org/wiki/Progressive_web_app
- 16. THE TECH STACK • Manifest • Service Workers • App Shell
- 17. MANIFEST • "Web App Manifest" • Just a JSON file (woot!) • Allows for "installable" web apps • Controls behavior when launched
- 18. MANIFEST • The name (as it appears in the shortcut) • Icons (of various sizes) • Splash screen and colors (bg and toolbar) • Chrome • Forced Orientation • The starting URL (handy for passing a param to note the launch) – https://(something)/index.html?utm_source=homescreen
- 19. ADDING TO HTML • <link rel="manifest" href="/manifest.json">
- 20. SAMPLE
- 21. DEMO • Show manifest1 and 2
- 22. (AUTO) ADD TO HOME • AKA Web Install Banners • *Current* criteria is: – manifest with short_name, name, 192x192 icon (png only), start_url – service worker – https – "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/
- 23. OLD SCHOOL ADD TO HOMESCREEN
- 24. WHAT IT LOOKS LIKE
- 26. THANKS IOS • Doesn't support manifest :( • But you can configure... • https://developer.apple.com/library/content/doc umentation/AppleApplications/Reference/Safari WebContent/ConfiguringWebApplications/Confi guringWebApplications.html
- 27. SERVICE WORKERS
- 28. SERVICE WORKERS - INTRO • JavaScript • A script registered via a script • Now - forget everything you know about <script>
- 29. "REGULAR" JS • 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
- 30. 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
- 31. 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
- 33. DEMO • Show sw1, debugging
- 34. CACHING! • CacheStorage API (LINK) • Keyed by name (this is how you version) • Ability to add one or multiple URLs • Ability to read from the cache (and delete)
- 37. DEMO • Show sw2 (just fetch handler) and sw3
- 43. EXCEPT... • 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?
- 44. GOOD NEWS/BAD NEWS • Good News: Caching Strategies exist • Bad News: You're responsible for figuring it out • See "The Offline Cookbook" - https://developers.google.com/web/fundamentals/instant-and-offline/offline- cookbook/
- 45. EXCEPT ROUND TWO... • iOS - no support for Service Workers • But officially "in development" for WebKit • AppCache
- 46. BACKGROUND SYNC • 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 • https://developers.google.com/web/updates/2015/12/background-sync
- 47. EXAMPLE
- 48. EXAMPLE
- 49. PUSH NOTIFICATIONS • Two APIs - Push and Notification • Notification - https://developer.mozilla.org/en-US/docs/Web/API/notification • Request permission to show a notification • You can show it
- 50. EXAMPLE
- 51. NOTIFICATIONS
- 52. NOTIFICATIONS
- 53. PUSH • 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)
- 56. STUFF I DIDN'T COVER • ServiceWorker to browser communication • Client-side storage
- 57. RESOURCES • https://developer.mozilla.org/en-US/Apps/Progressive • https://developers.google.com/web/progressive-web-apps/ • https://jakearchibald.github.io/isserviceworkerready/ • https://developers.google.com/web/tools/lighthouse/ • https://pwastats.com • https://pwa.rocks/
- 58. LIGHTHOUSE
- 59. JUST BUY THIS
- 60. LAST DEMO C O N F E R E N C E S
- 61. CONFERENCE "APPS" • Web, not native • Because - duh • No marketing, just text • Works offline • That's it.
- 62. H T T P S : / / C F J E D I M A S T E R . G I T H U B . I O / I C E C O N F D E M O / T H E M O S T AW E S O M E D E M O E V E R
- 63. SO – ABOUT THE APPLE IN THE ROOM...
- 64. 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- we-have-a-problem-2ff49fd7d6ea
- 65. ANY QUESTIONS? • Email me at raymondcamden@gmail.com • Visit my awesome blog at raymondcamden.com • Follow my awesome Twitter account at @raymondcamden
Editor's Notes
- Note - I'll share more resources at the end
- 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
- First off - it's JavaScript. woot! We all know JS, right? 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