 I'm a Google Developer Expert in Web Technologies. More specifically, my focus is on Angular and Google Maps these days. I started working with AngularJS and Frontend Development a long time ago back in 2011. So what is a progressive web app? So when we build a progressive web app, what we're doing is that we are working on a way to have one code base instead of three. The idea is you build a web app, and that web app is going to be your app that's going to work for the web in a browser and is also going to be what you use on Android and on iOS for mobile devices. So the idea is you write the code just once, and then all of your users, no matter their platform, are going to be using that same web app. So this is something that's been kind of a dream for a long time, to be able to have one code base and then just use that code on any platform and not having to maintain an Android application, an iOS application, and a web application. So PWAs help a lot with that. One of the main things with PWAs is to make that a possibility, a reality. So we'll see how it helps and what are the features that we have available to help with that. The main big thing about PWAs is to reduce friction. And what I mean by friction is that when you go to a store, you have to, well, first go to this app store, then look for an application. You'll be presented with tons of options, usually. So you have to pick which app you actually want to install. And then you're going to install it. And if you're lucky, meaning if you live in a place where you have pretty good network and LTE is stable and all of that, then the download is going to happen in a few seconds, minutes, usually seconds. But if you're not that fortunate, which in most of the world is really not the case, people are still using 3G in a lot of different countries. When you're asked to download 250 megabytes of application code, that is just friction, meaning people come to that or it will take forever and then just give up. So regular native apps have that issue that they are huge. They are really huge. And it can be frustrating from time to time that a common example that happens to me all the time is I have my insurance company. And instead of sending me the documents and I approve of insurance and say, hey, use our app. So I'm like, oh, OK, that's a good idea. I can use an app to do that. If I ever have to need that document, I could use the app and just put it up and I have the document. Well, the thing is when you get to download the app, you realize it's at least 50, 100 megabytes of code just to show a PDF to someone. So that's a little bit too much. So regular mobile apps are big, usually, and that's an issue. That's a thing that can prevent you from having your application downloaded by users because they don't have a network. They don't have the space on their phone. That's also a thing that happens very frequently. In the US, people like to get the latest phones and they're already up to date and they have devices with tons of space. But in developing countries, that's not the case, they still have phones that we would have here five, six years ago. So they are more space limited. They have all of these restrictions that we don't have anymore. So as a result, installing big apps is a problem. And if we want to have an app that's truly easy to install for everyone, no matter where they are, no matter what their phone is, PWA is a great option. So the idea is, and it almost sounds too good to be true, when you use a progressive web app, it's win-win all over the place in the sense that it's going to be fast for the user. It's going to be an easy experience. They don't have to go to an app store. And the download is going to be pretty much painless because what you're giving the user is a web app. So if they know about your web app, it's because they are already displaying it in the browser. And if they're displaying it in the browser, they already have the code downloaded, which means they're all set. So PWA is really using the web technologies and building upon on top of that to make things even easier for us developers to make those apps accessible on all platforms. So this sounds absolutely great. I'm going to write my code in HTML, JavaScript, CSS, and everyone is going to be able to use it. And I don't have to worry about the app stores. So it seems like something that everyone would want, right? And people wonder, well, is it just a marketing speech that you're doing here or does this actually exist? PWAs do exist. And one of the most widely used PWAs is this one. So this is a progressive web app from Starbucks. And when you think about it, a business like a coffee shop like Starbucks, they want you to be able to use the app to order and to pay in just a few seconds. So for them, it's really super important that you don't have to download 200 megabytes of code and wait before you can do your order. It has to be instant. So a PWA, from their perspective, makes perfect sense. And there was a lot of use cases where we just want to get this app to show up, do something, and you're done. And you're not going to use it for a few days after that. So PWAs are fast. And so this one, the one from Starbucks, I'm actually going to show you a quick demo. Because by showing you a demo, I'm going to show you what a progressive web app actually does, what it can do, and what are the different features behind it. So demoing on a phone is not easy at a conference because a lot of things can go wrong. So I record in my screen and I'm playing a video right now. So on my phone, I'm going to Google and I'm going to look for Starbucks. So this brings me to this app. The Starbucks PWA is the one that's going to show up right away. And you can see that at the bottom of my screen, there is this kind of pop-up that showed up that says, add Starbucks to home screen. So this is the progressive web app prompt that comes from that website. This is a website running in a browser, but now it is prompting me, hey, do you want to install? Do you want to add this to your home screen? So I'm going to access that. I'm going to say, okay, I use Starbucks pretty often. So I'm going to tap on that banner. And when I do so, I'm going to have a confirmation that's going to show up. There it is. Do you really want to add Starbucks to your home screen? Yes or no? And if I do it, then the install is happening in the background and that install is really just adding a link to my home screen. So now I have a Starbucks logo in there and that's my PWA installed. So it just happens in one or two seconds because all of the code is already there. And when I tap on it, you can see that the Starbucks app shows up again, but the rendering is slightly different than before because if you look at the top of the screen, there was no browser URL anymore. It is now showing up full screen. So I'm not running this in Chrome or in any browser anymore. This is the app taking its own entire space just like a regular native app would do. The banner at home screen is gone as well. And so I'm going to toggle between different apps so we can see that even more easily. There you go. So now if I use the Android application switcher, you can see at the very bottom of my screen that there is a Starbucks app that is showing up. That's my PWA with the Starbucks logo and the theme, the green color and all of that. And on top of that, there's my Google Chrome, which still has Starbucks open because I went there earlier, but the app is now different. It's now separated from a browser and it's live. It has its own lifecycle really. It's as if we took that browser tab and we turned it into its own app. That's really what it is doing. And of course, just like any app, you can kill it from here. So I could just close everything, switch between those apps and you can see that the behavior is really just like a native application. So now next thing I'm going to do is just close all of my apps. So I just close the PWA and I'm going to tap back on Starbucks. And when I do so, I'm going to pause. So I'm going to pause right now. Usually it's pretty quick, but I want it to pause so you can see that there is a splash screen showing up with PWAs. So that's another behavior that a progressive web app brings to the table. You can add a splash screen with your logo, your text, your theme, anything you want to customize that splash screen. Usually it goes away pretty quick because again, all of the JavaScript HTML or CSS was already downloaded. So the app just shows up right away and is ready to be used. So from a user perspective, it's great. It's just super fast. You install in one second, you just load the application in one second as well and that's a great, great thing. So these are the basic features that any progressive web app would have. So installability from a browser. So this prompt that's going to say, hey, do you want to install this PWA on your device? Then you'll have this shortcut. It's really a shortcut on your home screen to navigate back to that application. And then you can have some, so we get into the more advanced features very soon, but these are the basic characteristics using the splash screen, loading full screen, showing up on the home screen of your phone. Once you have that, you have a progressive web app. And what's important to remember is that all of this is just HTML, JavaScript and CSS. There is no native code here at this point. And I just use basic HTML, JavaScript, CSS, and so it's a Starbucks for their own PWA. So there's more to progressive web apps. We saw the basic behavior, but because the idea is to behave like a truly native application, progressive web apps can do notifications as well. So you can try to re-engage the user by notifying, adding that notification is going to look and feel like a native one. It's just going to behave the same way. So for Starbucks that could be saying, hey, your order is ready. You can pick it up right now, or that kind of thing. Another big feature is offline capability. By caching data images and extra JavaScript upfront, you can make your PWA work offline. Now of course, not all apps are meant to be working offline because some of them do require a server for interactions with a backend. But if your app has a few features that make sense to make available offline, you can also do that. And finally, you can uninstall. So just like we can install, you can uninstall the app, which is really just going to clear the cache on the device to remove everything that got installed earlier. So now that we saw what a progressive web app looks like, I'm pretty sure that you want to know how do I make one? What is required to build a PWA? Because this sounds great. So how do I get started? This is actually the best part of it because building a PWA is incredibly easy in the sense that you can do it without even writing any code. The bare minimum required for a progressive web app is two things. The first one, a manifest file. So a manifest.json, which is really going to be a config of what the PWA should look like. So it's really giving a name to your app, giving an icon, defining how the splash screen, what the splash screen should look like, what are all the colors that you're going to use, the theme, all of these different things. Do you want your app to show a full screen or just like a regular browser application? All of these sort of information, that's what's going to go into manifest.json. If you have that manifest and you add it to your web app, so in your index HTML, you would just have a reference to that manifest.json. Just like you reference external CSS or JavaScript, you would load the manifest.json and then the browser is going to recognize that. And as the browser sees that manifest, it's just going to enable all of the features that we just saw. So the install prompt, the splash screen, the icon, everything just comes from that manifest. There is another second thing that is required. So the manifest in itself is going to enable these features. If your app is running on HTTPS, and that's the other very important thing that is absolutely needed. If you want to PWA, you need a certificate on your backend. You need SSL, you need HTTPS. If you just do regular HTTP, then the browser is not going to pick up the manifest.json and it's not going to enable that behavior. So that's the two things that you need. HTTPS and manifest.json. If you have these two, you have a progressive web app. So this can be done in five minutes, really. We'll see a few tools that can actually help generate the manifest.json, but that's all you need. These two things, you have a PWA that can get installed, splash screen, all of that. If you want to get into more advanced features, then you are going to need a service worker. A service worker is a script. So this is JavaScript code that you can set up to do all of the caching. So if you want to do offline with your app, you would write a service worker that is going to specify what you want to cache. So this CSS file, this font, these images, these data requests to the backend, all of that, I want it to be cached. And only a service worker can do that. Same thing for notifications. If you want to do the native notification support, it would have to happen through that service worker. Because the nice thing with service worker is that it is going to run in your browser, kind of like a background process. You can really think of a service worker as a script. It's always there in the background, and that can send requests to your server, even when the user is not using your application. So that service worker could pull your server, ask for some info, and then show a notification, even if your app is not actively running in the browser. So these are very, very powerful things. And if you're not familiar with the idea of the service worker, I'm pretty sure that you've seen, that you've at least seen one in action recently, because over the past couple of years, it's become very popular for blogs or news websites to just ask you, hey, do you want to get notifications from us? And if you say yes, then the service worker is gonna get there, is gonna basically pull their backend in the background, and send you a notification, hey, we have this new post that showed up, hey, we have this new article ready for you, and all of those features rely on service worker. So you can use service worker without a PWA, doesn't have to be just for a progressive web app. But usually, progressive web apps are a nice addition, service worker are a nice addition to a progressive web app because of the offline capability and the native notifications. So I mentioned, I mentioned manifest.json, the file that we need to enable progressive web apps. That's an example, that's what it looks like. So again, it's just a simple JSON object that has keys and values, and these keys are, while the name of your app, a shorter name, start URL, the kind of display that you want. So here it is set to standalone, which means it's gonna show and behave like a standalone native app. As a background color to use for the splash screen and the header, to the description of your app, and then a set of all of the icons that you want to use. You can add as many sizes and definitions as you want to support ultra high depth screens or smaller phones as well. And that's really the only part that's kind of native, having to provide all of these different icons. You don't need to provide hundreds of them, by the way, just one or two can do. It really depends on how good you want them to look like on any sort of device. So this manifest JSON is a config file, really keys and values. And if you want to create your own, you can use a generator. So there's this one, which comes from Google. So appmanifest.firebaseapp.com. If you go there, you can just enter a bunch of values and then click a generate button and then you have your manifest.json. So that's as easy as it gets. You fill out a form, click a button, and you can download your manifest that you just then include to your index HTML and you're all good to go. You have a progressive app. So on the side of service workers, in terms of syntax, it can be a little bit more complex because that's where you're gonna have all of the logic that you want to implement if you do pre-caching. Or while you're caching alone or pre-caching, which means fetching data and images upfront so that the app would keep working if you go offline. So in that code example, we see a first block where we define a bunch of URLs that we want to pre-cache. So here are the index HTML, all of the styles and a demo.js. And then the service worker has its listener code that is going to make sure that everything gets installed. And once the app is ready, add all of the pre-cache URLs and try to download them and cache them. So writing a service worker can be complex. There's a lot of things you can do with service worker and in terms of syntax, it can get a little bit tricky. Which is the reason why there are more and more libraries to help with this. And one of the most popular library used to date for this is called Workbox. So Workbox is a library that has all of the, let's say shortcuts to help you with the boilerplate that would be needed to write a service worker. So Workbox knows about pre-caching, runtime caching, all of the different strategies that you want to use for caching, such as do I try to get new data every time I'm online or do I just always use the cache? How often do I want to refresh that data? Once a day, once a month, never, that's up to you. You can define all of these strategies and Workbox enables all of that in a pretty straightforward way. Routing, background sync, debugging, and yeah, basically brings a ton of features on top of service worker to make it easy to create your own service worker and build some features on top of it. So if, my example earlier was using the Starbucks application. So if we want to take a look at how they've done it, you can go to that website, app.starbucks.com in your browser. So I'm using Google Chrome. And in Chrome, I opened the DevTools. And in the DevTools, I went to the application tab. And in that application tab, you can see that at the top, so top left corner of the DevTools, we have this section where we can click on manifest. And that would show us the manifest.json used by Starbucks in that case. I can even open this one in a new tab and that shows me exactly what their manifest looks like. So they actually kept it pretty nice and easy. It's fairly straightforward. Only two different sort of icons. And they also added references, links to their other truly native apps. So there was a link to the iTunes store for the iOS and to the Google Play for their Android application as well. But yeah, you can see that display standalone, default orientation, portrait, the theme color, background color, start URL, the name of the app. And that's it. All of that. All you can see on my screen right now is what you need as a manifest to get things started. And even this one is actually a little bit more complex than a base manifest. Related applications is not needed. You could really just have a name and an icon, and that would do. So it could be even more basic than this. So in the Chrome DevTools, I can explore the manifest. So these are all of the icons found in the manifest. There's a different colors and everything. And I can even see the service worker. So there is a service worker link up here, which is going to show me when it was installed. So the last time it was received and is it running or not. I could force to unregister that service worker or force to update it. I can simulate offline from here. So I could click offline and then I would see how this app behaves if I go offline, for instance. And if I want to see the source code, there's a link to the source as well. So if I click on here, I get to the source and I can tell right away that the service worker for Starbucks was built with Workbox because it shows right here. And that they're pre-caching a lot of things, such as images, CSS, JavaScript, which makes perfect sense. If you want the app to show up offline without any connection or to be able to reload pretty quickly, you would need to cache all of that upfront. So that's how they've done it. And they use the Workbox to make this happen. So another feature I mentioned earlier was notifications. So these notifications, you can use them in regular JavaScript these days. So you don't need a PWA to do notifications per se. But it could be a nice addition to your app if, of course, these notifications bring value to the user. There was a website that you can use. So this one up here is a notification generator that shows you all of the options available to play with notifications in a browser. And you'll see that it's actually quite a lot. There's a lot of options here. You can add icons. You can add actions to your notification. So buttons like yes, no, or OK can solve those sort of things. You can make the notifications silent. You can decide what happens when the notification gets closed as well. So I encourage you to take a look at this website and play around with it. Try to customize the notifications. And then you can click the display button down here. And it will show you the notification in. So if you're using a web browser on a PC or laptop, you would see the native operating system notification rendering for that. If you're using it on your phone, then you would see the native behavior for your phone in here. And one more tool I want you to talk about, which is very important when you build a progressive web apps, is Lighthouse. So Lighthouse is another tool from Google that you can use to audit your progressive web app. And it can be found in the DevTools of Google Chrome. So if you go to a web app, you navigate to the audits section. You'll see a button, perform an audit. And when you run that audit, it is just going to take the app and run a bunch of tests on it. These tests are, so there are several sections. One of them is PWA. It's also going to test your app for search engine optimization, speed, all of these different things that you can think of to make your app better. So if I go to Google Chrome and navigate to audits, I have my app open multiple times. So I have to close that. Yeah, I'm not sure it's going to work here, but that's okay. It looks like I have this open in too many different places. So it's not going to run the report, but that's where you can find it. So in your DevTools, you go to audits. This is a Lighthouse tool. And it can run reports on all of these categories. So performance, PWA, best practices, accessibility, and SEO. And the nice part about Lighthouse is that it's going to give you a score on all of these categories. And if you're doing something wrong, it's going to tell you exactly what to do to fix it. So for instance, a common mistake that people make is that their images are too big, way too big. And this would catch it and say, oh, this image here is like five megabytes. You have to do something with it because it would never load on a smartphone or those sorts of things. So pretty impressive too when you run it to learn a lot. And it's going to give you great insights about what to do to make your app better. So yeah, from a progressive web app perspective, it's going to check your manifest. It's going to check that your icons are all good, that your service worker gets installed, and all of these different things. It takes probably a couple of minutes to run the audit, but it's definitely worth it. It saves a lot of time in the long run and gives you a ton of info. So the title of my talk was Our Progressive Web Apps for the Future. And the thing is there are still work in progress in a sense that not all browsers support progressive web apps right now. It is getting close to it. Apple has been a little bit slower in adopting progressive web apps because, well, you can really see that as some sort of competition to iTunes. So it's been a little bit slower on Apple's side to go with PWAs, but it's happening and should be there if not already this year. Because the thing is progressive web apps are a W3C standard. So the app manifests, the service workers, the notifications, everything I talked about, it has to be supported by every single browser. They have to. It's part of the spec. It's part of the W3C standard, which means that it's going to happen and it's going to become universal support all over the place at some point. And the Starbucks app that I showed you probably started at least two or three years ago. I've been doing this talk for a while and yeah, I would say two or three years ago. So progressive web apps have been around for a few years already. The support is becoming much better over time and hopefully this year we'll be able to just use them in any browser and we'll have all of these features enabled no matter which mobile device we're using. You can already find a few directories of PWAs. So there are two examples here, pwdirectory.appspot.com and pwd.rocks. These ones date from years ago when PWAs got started. There are a lot of tiny games or kind of to-do list examples. Most of them work offline. They do notifications. They do all of these things that I talked about. So if you want to play around and test a few progressive web apps, that's a great place to go and take a look at. All right, that was my last slide.