Hey all. Today we're going to be talking about progressive web apps and more specifically how you can build one from the comfort of your own home. Because. Because I guess that's the new norm, working from home, sheltering in place whatever it is going on with you. So my name is Michael Slotty and I am primarily a web developer with specifically a background, mostly in angular. But today's talk isn't an angular focus, so don't worry about that. I'm actually going to try to cover concepts that are framework agnostic and also include a little bit here and there about some framework specific solutions to the concepts and tooling that I discuss. I also happen to be a developer program engineer focusing on web infrastructure. So if you're interested in anything that I discuss today, I recommend checking out the website that I work on. It's called Web Dev, which the URL is just web dev. Besides my love for angular, I just love the web. I grew up on the web and I remember what things were like in the in our modern web environment. I love it. It's compelling, it's exciting, and we have such incredible tools to make amazing and compelling experiences for others. I will also mention that I do have a mass product. If you're not familiar with what makes means, mass stands for means as a service. Just making a hard pitch right there. It's memogram.com. Check it out, hopefully you like it. Let me know what you think. And I will finally mention that I behave made a lot of mistakes, and I mean a lot. So I'm hoping that maybe I can share some of the painful things that I had to learn along the way. That way you can avoid making the same mistakes as you build pwas yourself. So what exactly is a PWA or a progressive web app? And that's not right. I would say it's not this. What you're seeing here is definitely not what a progressive web app application should be. Pwas really are just web applications that have amazing experiences. And the reason for that is because they're fast. They're going to respond quickly, whether that's loading or responding to a user's interactions. They're integrated because they show up on a user's home screen and they have access to things like sensors and Bluetooth and can handle push notifications. They are reliable because they're going to load instantly and you're never going to see the dinosaur like we just saw. And finally, they are engaging. They feel like a natural app that deserves to be on a user's device. With these immersive user experiences. And if ever you doubt your ability to make a web application like that, I'm telling you that you can. And if you want, you can just repeat this simple mantra and that's you spit hot fire at Chappelle jokes. Anyway. So why pwas? Well, users spend most of their time in native applications rather than websites, and that's mostly because apps end up being more predictable. They're available on a user's home screen, so it's an easy one touch to get there. And push notifications allow applications to reengage users back into the app. So maybe if they haven't opened the app in a while, you can just send them a notification and that will get them back into using your app or your web experience. Another important thing is that space on the home screen is really, really valuable. Roughly 78% of the time a user spends on their phone is within their favorite three application. So what we're really asking for two, be an app on a user's home screen is a commitment for time and space. And this is especially important when an average user installs no new apps a month while they are more likely to visit websites. So PWAs are essentially web applications that provide a near native experience on mobile devices. I ended up liking this quote, which I think came from the Google Developers website. But building a high quality progressive web application has incredible benefits, making it easy to delight your users, grow engagement and increase conversions. When progressive web app app criteria are met, Chrome will actually prompt users to add the PWA to their own home screens. With tools like service workers, you can send less data on the initial page load and less data to complete transactions. With push notifications, you're able to increase engagement, allowing users to get updates as well as your ability to re engage users to use your application. And when users are typically averse to installing apps from the play or App Store, and rather would visit a website like Facebook, a lower barrier to entry for a website may be all you need to be a citizen on their home screen. Native apps start quickly, work in the background and they work offline. They have access to all different types of sensors and there's different versions for different platforms. Web applications have one incredible benefit though iOS, that they have great reach because it is one site for every platform and it can be safe and it can handle a lot of these same features that I discussed. But we need to introduce these into our web applications to make them feel more native. So this is an experience that I think really describes what a good PWA would look like and this is the Twitter web application. The application loads thus far. The UI looks almost identical to that you'd find on the Play store or App Store. It feels and looks native. I'm able to attach pictures, it opens up the camera right away, and I'm able to upload makes. And again, everything looks compelling. And it's a really good example of what the PWA is capable of. And a big thing like, one of the big things that moved me to use the PWA Twitter application rather than the native application is there was a period of time where I kept both apps installed on my phone. And when I decided to go to my installed apps, I looked at them side by side and I saw how much space they were taking. And in both situations I saw the number 200 and 5250. But I didn't look hard enough at it at first. I looked at it just maybe a few more seconds later, thinking, what's the difference? And I realized that the Twitter native application, while installed on my device, was taking roughly 250 megabytes of storage versus the progressive web app location, which was taking 250 big of a difference in size. Without any real compromises in what the application was providing me. I moved to the web application and I have not looked back. So let's talk about a simple PWA that we have. And it's a fairly simple. It's designed to showcase popular movies. I have it running over here, and you can see that if you clicked into a movie, you can view some more information specific to the movie. And a lot of things it kind of looks like what you might expect a native Android app to look and feel like. And that's because it follows material design guidelines for the aesthetic. And there's a few things under the hood that I do to make the app behave more quickly and more like a progressive web application. And that's all fine and dandy, but does it really qualify as PWA? And that's a simple thing that we can check. We can test it against a tool called Lighthouse. And so here's a video of a lighthouse audit. Tests are running and nothing really there, at least not a positive score. So in a lot of cases, this application isn't really doing what we need. It's not getting any green check marks saying that, yes, this is a PWA. And why is that the case? Well, the first thing is the page isn't responding with the 200 status code. If we're building a PWA, we might want to use a service worker. That way this application will work even if we're disconnected from the Internet. Secondly, like I said, we'd want to use a service worker, but this web application as it is now, isn't even registering a service worker that will tell the browser what pages to load. So our service worker is really the technology that enables our apps to use many of the features of Pwas, one of them being offline. But also with the service worker we're able to actually add the web app onto a user's home screen and handle push notifications. Without the web app manifest file, it doesn't really meet the requirements for installability. So browsers can actually proactively prompt users to add their web application to the user's home screen, which leads to higher engagement. It's not configured for a custom splash screen, and this is one of those things that can be set in the web app manifest file. But when you open Twitter or Facebook on your phone, you end up seeing the Twitter or Facebook load two go for a quick second while the app loads in. We can do that with web applications as well. There's other things about setting the address bar, theme, color, ensuring that the website still works with JavaScript disabled. And that last one is actually really important in my opinion. I remember a time when I worked at a webshop and we were doing a lot of great work on a client's website, but no matter what we did, the client repeatedly told us that the site that we were working on and hosting for them would not work on their iPhone and legit. We had no idea why. I will say we were all Android users, so we didn't have that much experience with iOS. So my boss decided to do the most reasonable thing, and that was to bias all iPod touches. We all got iPod touches, not iPhones, but we weren't able to replicate the issue until one day we actually met with the client in person. We just looked at her phone to discover she kept JavaScript disabled on her phone, and we ended up spending a lot of time and effort trying to troubleshoot this when we didn't necessarily do anything wrong. The user didn't do anything wrong too. It's their decision to have JavaScript disabled, but we could have accounted for that and we could have provided some sort of experience if JavaScript was disabled, might not be the full experience, it might just be a warning that hey, JavaScript is disabled, you might not get the full experience that you expect. But because we didn't do anything to account for that, the user didn't know what was wrong with the site. And if you're doing this out in the wild, they might abandon your site. As it sounds right now, this application is not fast, it's not integrated, it's not reliable, and it's not engaging. So one thing I actually mentioned a little bit earlier was lighthouse. And for those of you who don't know what Lighthouse is, it's an open source and automated tool for improving the quality of web pages. You can run it against any web page, whether it's public or it requires authentication, and it has audits for things like performance, accessibility, and whether an application is a PWA and more. It definitely handles more than that. So you can actually run lighthouse straight from inside of the chrome devtools. You can run it as an extension that's available for Chrome and I believe there iOS a version of this extension available for firefox and it exists as a NPM module that you can install and use in your build processes or just as a command line tool. So let's make this application better. And one thing that we really want to do is we want to make sure that this application is reliable. When something's reliable, that means there really shouldn't be any surprises like a chromosaur or dinosaur popping in when a user iOS visiting your application. So when we talk about being reliable, when the user launches the web application from the home screen, we can use service workers to improve this and what the service worker is going to do. It's going two enable a PWA to load instantly, regardless of what the network state is. The service worker is written in javascript and it's kind of like a client side proxy and puts you in control of things like the cache and how to respond to resource requests, whether that's post get requests, makes, et cetera. And so by pre caching key assets and resources, we can eliminate the dependence of the network, ensuring that our applications are instantaneous and reliable. An example of how that could work is what we have here, and this is a cache first example, which is ideal if you're building an offline first experience. So this is how you'd handle a majority of requests. The page would make the request that would go through the service worker. The service worker would check the cache. If the resource doesn't exist in the cache, it'll then go to the network, make the network request, return it to the page, while also caching that network request for next time. And there's other strategies that you can use to implement with your service worker. But introducing a service worker to your site can be super, super easy. If you use angular, there's an angular schematic that you can install and apply to your project with just the command Ng add. At angular PWA, it ends up adding the angular service worker and configuring the build to include the service worker. And there's a lot of other things it'll do to get your application PWA compliant, but it's a really simple, easy to do step just from the get go for you. Another thing is if you use create react app to create react applications, since 2017, it has included service worker and PWA support from out the box. You haven't had to do any configuration or any work to have that. And finally, also since 2017, the view CLI has made it easy for you to enable service workers with the view create command. What you would want to do is manually select features, and then you would just enable PWA support and we can let the default settings for the rest of that stuff work. Now, customizing configuring your service worker is something you're going to need to do regardless of what framework you end up using. And while the platforms can guide you with what you should and shouldn't do, they can't know everything that you need. So taking view, for example, you can modify aspects of the service worker by configuring a PWA property of either your view config file or a view field inside of the package JSOn. But something cool with view and react is that the tooling used to generate the service worker is built on top of a library called workbox. So workbox is a library that bakes in a set of best practices and removes the boilerplate that every developer has to write. When working with service workers, and it's available on NPM, I invite you to go tinker with it and take a look at it. And on web dev we actually host an article about workbox. It's written by Jeff Posnik. He's part of the Google web developer relations team and specifically works on workbox itself. So you can find the article here. I definitely recommend giving it a read if you want to get a better insight into how workbox works. But with the service worker, our site is now definitely reliable. It's going to work offline because we're caching the key resources and assets in order for the site to work. And it's going to be a bit faster because with those assets and resources cached, it doesn't necessarily need to go to the network and wait for server responses in order to process the requests. So we're faster, but we want to be even faster than that. And that's important because the average load time of mobile sites is roughly 19 seconds on 3g connections. 53% of users will abandon the site if it takes longer than 3 seconds to load. And once it's loaded, users expect these sites to be fast. They don't want janky scrolling or these slow to respond interfaces. People on average expect the site to load within like 2 seconds, and almost half of people say that waiting on a page to load is what they dislike the most when browsing the web on their mobile devices. Luckily, with their service worker that we configured in the previous section, we've addressed a lot of these concerns. However, we can still optimize this initial load, parse, compute and rendering of our web applications, and that comes with this massive concern that we have. And that's the cost of the Javascript we're actually running now. I'm kind of stealing this slide from a friend and an amazing propagandist for the web who works on the Chrome team adiosmani. So keep in mind, if we want to be fast at JavaScript, it has to be downloaded, parsed, compiled and executed quickly. But not all bytes weigh the same. A 200 kb JavaScript file has a very different set of costs than a 200 kilobyte JPEG file, and this is outside of the raw network transmission times. For both sets of bytes they might take the same amount of time to download, but when it comes to processing, we're dealing with very different costs. A JPEG image may need to be decoded, rasterized and painted onto the screen, versus a JavaScript bundle that needs to be downloaded, parsed, compiled, executed. And there's actually a number of other steps that an engine needs to complete. Just be aware the costs are not equivalent, and by remembering that the JavaScript being sent down the wire has two be computed and rendered out for our spas for single page applications. Pwas progressive web app this takes time, but we can actually remove some of this burden off of a user and these devices and onto our server with server side rendering. Now luckily, all the major frameworks have pretty good support for SSR, and as a front end developer who doesn't want to write a full backend solution, some of these solutions are really really good. And there's non first party solutions that streamline the daunting task of configuring your own SSR environments. In the react world you have next js, and in view you have nuxtjs. But again, assuming you want to take a framework agnostic solution, you can actually use puppeteer. Puppeteer is a node library which provides a high level API to control chrome or chromium over the devtools protocol. Puppeteer runs headless by default, but can be configured to run full non headless chrome or chromium. And you can do a lot like generate screenshots of pages or pdfs. You can run tests in Chrome or crawl a single page application. And most importantly, you can use it to generate pre rendered content, I. E server side rendering lines, workbox. You can find puppeteer on NPM and this is actually a really simple implementation of creating a SSR server with puppeteer. So now we've built a site that is both reliable and fast, but we want our application to now be engaging and interactive. It should feel like a natural app on the device with an immersive user experience. And Pwas are installable. They live on a user's home screen without the need of an app or play store. They offer these immersive full screen experiences with the help of a web app manifest file, and can even reengage users with push notifications. Now the web app manifest allows you to control how your app appears and how it's launched. You can specify things from home screen icons, the page to load when an app is launched, and even whether or not to show that it's running inside of chrome. And it's actually really easy to do. There's a great site like Appmanifest, firebaseapp.com, and I'll actually do this right here for you guys to see. So here I can just type in the full name of the application, which I will just call popular movies, and we can put in the short name, which is the name that will end up appearing if the full name is too long to show up the theme color iOS kind of like that color you would see in the status bar or whatever. And as I'm setting the colors, you can kind of see the colors changing here, and the background color is the color of the splash screen. So when the user first opens up the application, the screen will turn into whatever color this is. I'll just choose plaque black display mode. We're going two use full screen mode orientation. We'll lock it into portrait, though you can allow for any orientation or lock into landscape. And finally, I'm just going to click on icon and I am going to choose this app icon here, open it, generate this up. Oh no. Well, this might have been broken recently, but I am sure this will be up and running again. I will probably have to pass this information on anyway, you can generate this nice and easy. Might be broken for the time being. Hopefully it'll be fixed by the time you guys are seeing this. Until then, check out this URL to tinker with the tool. It's a great resource, and once you have downloaded the zip and gotten the files you need, there's actually just really little work you need to do. The first thing you need to do is you need to move the images or the resize icons into whatever folder that you're storing your image assets in. And then finally you're just going to set these two lines here. The first one is manifest, which is going to point to the manifest JSOn generated, which is going to dictate how the app experience is going to be. And secondly, the theme color, which is the cooler of the status bar in chrome or the Chrome bar omnibox on mobile devices. With that in mind, with the manifest in place, our app can now live like a native application on a user's screen. The application iOS fast integrated, reliable and engaging. So here is the application with all these things in place, we're going to run the lighthouse test and we're going to see how this goes. So I'm going to cross my fingers by kind of know how this is going to work out. Well, there we behave it. That's a lot of green. The application is doing everything it needs to. We have that green Chuck mark knowing that our application is a PWA. If you guys want to check out the application, test it. Check the source code. You can find it at PWA, O-T-A dev. If you want to look over the slide deck, you can find it at building PWA camel casing. It's case sensitive, so be careful with that. And finally, if you can take anything away from this talk, I will say no matter how much fun or how much we all love the chromosome, or hopefully the chromosaur can go the way of the dinosaur which iOS makes extinct. Again, thank you. You can find me on the web, on Devto, LinkedIn, GitHub and Twitter with just my name, Michael Slotty and Adios.