 Well, my name is Niko. I'm a dev developer focused on front-end development and work-dress, obviously. I'm self-employed, which means I spend an unhealthy amount of time inside a little room, I call my office, and I write custom themes, custom plugins, and all kinds of web-based software. Well, today I'm going to talk about progressive web apps, a subject that I think will be the next big thing in web development. And I've structured my talk around the three most important questions, obviously the what, the why, and the how. And I'll just start with the first question, the what, pretty easy, what is progressive web apps? Well, the answer is not that easy. I had my first talk about progressive web apps around one year ago. Since then I had some talks about the subject, and on each talk I completely changed my definition of progressive web apps. The reason behind that is I'm not very happy with the naming of progressive web apps. Because that indicates that it would be a product, like a website or a web app. There you have some differences to tell whether it's a web app or a website, or a product like an app. I always feel like that should be a product, and in the end it's not, because a progressive web app is just a website. It's as simple as that. It's based on HTML, it uses CSS, it uses JavaScript, and it runs inside the browser. But there are new features, new browser features, so I'd call it a website plus. And the fun thing is that was my very, very first definition of progressive web app. I made a quick turnaround through all kinds of definitions, and now I'm just going back to that very first basic definition. So why do we need something new? The web is great, right? We have this global network of servers. They're all talking to each other, they're all connected with each other. We have browsers, which means you have standardized scripting languages that run everywhere. And in the end, somewhere on the planet, you can publish some piece of content, it could be a blog post, it could be an image, it doesn't matter what. And the minute you publish it, I'm able to access it, I'm able to read it. Or we could create web applications, very powerful web applications that run everywhere. That means you can run that same web application on an iOS device, on an Android device, on a desktop PC, on a macOS, it just doesn't matter. And that's pretty cool, and that's already happening right now. We do have the capability of those web technologies. But then you have apps. And in that case, I'm talking about all, let's say, operating system-based software. And that's cool as well, because we can access the full potential of our devices. But in the end, we do have to write the exact same application multiple times. You have it maybe for Android, you have it for iOS, you have it for Windows, and you have your macOS. That's just four times exactly the same application. That's insane. Why would anyone do that? Why would anyone create native applications? There's reason. And that's because 87% of the time, user spends on his smartphone, he is inside native apps. That's 87%. That's huge. Because in the end, we all are web creators in some way. Our designers, our web developers, our content creators. And that means we all need to share those remaining 13%. And in the end, that means that the mobile web is there. And that's not just a number I came up, or I made up. That's from the COMSCOR report in 2015. Well, that's pretty bad for all of us. Luckily, there were some very smart people at Google. They were looking at native apps, and they were looking at mobile apps, and they were looking for what are the main features, why native apps are so much more popular than web apps. They're forward, they're fast. That means once you've downloaded them on your smartphone, they are there. They can boot up immediately. There are no network requests you have to do, or that's in theory. They are integrated. Why is that important? I like to compare it with the living room. You have stuff you use on a regular basis inside your living room. That's limited space, so you have just a small amount of stuff you use on a regular basis. And then you have the window, and you have the door, and you have the whole world in front of you. You could use anything, but that's just not inside your comfort zone. Everything we have inside our comfort zone, which is integrated in our smartphone, we use on a regular basis, and that's why it's important that those native apps feel like they are inside our comfort zone. They are reliable. That means that even if you don't have any internet connection or a bad internet connection, there is still something happening if you click on our app icon. So that's not what you have on a web application normally. And they are engaging. We can send code notifications to the native app, and re-engage our users to our app, let's say. So they were thinking about those five four words, and they were thinking about a next generation of web applications, and they called it progressive web apps. The biggest part of my talk was how do we achieve that? I was talking about new browser features, and that's one feature that's the web app manifest. And it's pretty, well, it's pretty basic. It's just a chasing file that contains some information about our website. We have here, we have a name, description, some colors. We have a display mode where we can decide whether it should be open in full device or we could still show the notification bar, we could use the browser, the browser bar as well, we can define the display mode, and you can set a whole bunch of icons in different sizes, in different formats, and the device can just pick the icon it needs. So in the end what we have here is smashingmagazine.com, which is a progressive web app, and let's say I've read that, or I've seen that article on Facebook or Twitter, I visited their website, and as soon as it matches the browser progressive web app criteria, I will see this little prompt that asks me, hey, that's a progressive web app, do you want to add that to your home screen? I can click it, and then it's right next to all the other native apps. We have this smashing magazine app right next to Chrome, it looks integrated, it looks just like a native app. So basically that's all the code it takes to make a website into a progressive web app. If you want to add it to your home screen, yes, that's really some kind of, one line of HTML, one line of JSON, we're done with the other home screen. The next time I open it, it looks for, as I said, the display mode, so the URL bar is gone, and it just takes the whole size of our screen, and it really looks like a native app. That's pretty cool, and even if you open our task manager, it's there right next to Slack, which is a native app, and right next to Google Chrome, and that's funny because Google Chrome actually powers the progressive web app, and it's still in the task manager, it's right next to the native apps and Google Chrome. That's the app to home screen with our manifest. Then we have a new thing called the service worker, and that's the actual magic thing. Because when you have a normal website, you have JavaScript files. You have some, maybe you have this theme, JavaScript file, we have a plug-in, and there's core JavaScript files, and the latest versions of JavaScript are really, really powerful. You can do a lot with them, but they have one problem. As soon as we close our website, all those files, all those, let's say, apps, they've just gone, they're dead. We can't do anything after that. So the service worker here is as well, is a JavaScript file. It's plain JavaScript, but it lives inside a different scope. It lives somewhere between the website and our device, and it lives there forever. You need to close the website, you need to close the browser. It's still there, and it can still listen to events. How does it work? Pretty simple as well. We can register it using Navigator Service Worker Register, and then we can just put the path to our service worker file. You can wrap it inside a feature detection, and then we have our service worker. As I said, it's plain JavaScript. It's event-based, so we have the installed event. That's when the browser first visits the website, it sees, oh, there's a server-circle, and it installs it. Then you have to activate the event that's happening after the server-circle was installed. And the cool thing is you have a fetch event, so every request goes through the service worker, and you can play with that request. Another cool thing is you can use ES6 because as soon as I know all browsers that support service workers also support that new JavaScript version. How can we make our website reliable? We have the same example as before. We have a website that's connected to the internet, sorry. It makes a request, it gets the answer and displays the answer. That's simple, and it works. But what if we don't have an internet connection? You will see that network connection error. In Chrome, it's the download store. It's a pretty fun thing at the first visit, but it gets really annoying and you don't have any internet connection for a longer period. Now, with the service worker, we have, first of all, we have the service worker that's between the website and the internet. And we have something new, that's the application storage. And that's very important because even if you don't have any internet connection, we still have a reliable source where we can put content and we can take content from that source. So we still have something to interact with and we have that source, that application storage. In the end, what we can do is we can, as I said before, every request goes through the service worker to the internet, comes back and then we can decide what do we want to do with that request. We can take a copy and put it inside the application storage and we can pass it to the website and we will display it on the website. That's cool. Now, with the internet connection, we can, we will see here, oh, there's my internet connection, there's a problem and we can look right here if we already have that content stored and that our application storage. And we can just take that cash source from the application storage. So having no internet connection is still pretty bad, but we do have a pretty solid fallback using service workers. When I prepared those lights, I was in Italy on the camping site and, well, in 2019, I was still in Europe, I did not have no internet. I had Wi-Fi. I had camping site Wi-Fi. Sometimes better, sometimes nothing, but on regular it was pretty, pretty bad and actually that's worse than having no internet connection because having no connection is at least honest because there is no connection, you don't get any content, you won't see anything, you get better. Having that kind of unstable or just a slow internet connection leaves us there staring on a white screen and loading, loading, loading and maybe eventually we will have something to display it, maybe not. And there's a very cool term by Jake Archibald and that's Wi-Fi, but it's just not honest. How can we get rid of that? That's the same scheme as before, but now we can make our website faster, actually faster using progressive web apps because that service worker is just JavaScript and we can play with that. In the end we can take or we can create a different caching strategy. In that case, when the website makes a request, we can look at the application search and if there is already something in there, we can just take that source instead of the internet so there's no network request and that is really fast because it's on our device already, it's already there. So there are no network requests and the cool thing is we can decide for each request we can decide whether we want to go to the internet and get the most recent version or we want to have that cache code strategy where we take this version from the storage. That means for static files like CSS, JavaScript or images, it makes sense to take the copy from the application search because that doesn't change on a regular basis but for dynamic stuff like HTML documents, pages or JSONs or REST endpoints, it makes sense to first look at the internet if there is a new version. So we can play with those kinds of strategies. The next thing is engaging. Being able to send push notification is not very new. We have the web notification API that's already there for years, I think, at least in Chrome and that allows a website to show push notifications to the user. The thing is we have seen before as soon as I closed the website all our crowd script is dead so it doesn't make sense to show push notifications to someone who is actually using our site at the moment. So having a service worker, having that infinite or that reliable thing inside our browser allows us to send or to trigger a push notification from the network to our service worker to the subscription endpoint and that service worker can then take that push, it can pass it to the device or it can display the notification on our device and then re-engage our users with our website. So it's cool because it works even if you're not using the website right now. And having that feature is very cool because if you think about not our regular news sites if you think about Twitter, Facebook, e-mail clients those are all applications that they don't necessarily have to be native apps but for them it's very, very important to be able to show push notifications. So that feature is awesome, it's very powerful but remember with great power comes great responsibility. Who knows what that is? Yeah. Nokia. Nokia. Okay. That is a browser permission request and it's not an easy to use extension of your user interface because unfortunately most of you will feel like that, right? Yes. The problem here is I've already seen so many websites that using that in a wrong way because I said that's a browser permission request that's like a camera or a microphone access you would never show a camera access right on the first on-load event that's just nobody would do that, right? But here with that push notifications permission I've ordered that there are so many pages that just throw it on the on-load event and they think well if you show it on the first time maybe someone will click yes but that won't happen because if you think about that you read an article on or you see an article on Twitter or Facebook visit their website that's the very first time you're visiting that website you have no idea how often they will send push notifications about what subjects they will send push notifications nobody would allow that but still at the moment that's a very bad or let's say that's a we call it an anti-pattern in user experience that's happening a lot right now so we have our progressive data because it's fast because we have our cache for strategies for static files it's integrated with our app to home screen functionality it's reliable because we have our application storage and it's engaging because we can use push notifications awesome and there are a lot of very good examples like Pinterest or as well to delight they're very cool progressive web applications but the thing I always ask myself is that possible to use those features for any multi-page application or for any WordPress application and that's why I created our own website as a progressive web app so you can add it to your home screen it works offline and you can receive push notifications but as you can see here it's a very decent option in footer so if you want to you can you can click on it and then it will ask you if you want to allow push notifications or not and it won't ask you just to update what kind of push notifications do you have or would you put there in that case you would receive push notifications for our blog we have blog posts maybe every six months or new projects and what about other websites what kind of push notifications can we receive if we say accept instead of decline all kinds of push notifications you're completely free if you as a developer you can send all kinds of push notifications you can send every five minutes a push notification that says hi I'm there but it can be really annoying so the developer and that's why it's a powerful feature because if you allow that you allow the website to spam you with push notifications so that's why it's very powerful and you should be aware when and why and how to ask Slack users also Slack users it okay in a browser so that makes sense as well because if you have a notification you can have a push notification and after that I created a plugin called Google SuperPress and there you can add all those features as an add-on enhancement to any existing website and I think that's pretty cool and when I created that plugin it was when I published it it was the first progressive ever plugin first fully featured progressive ever plugin and back then that was no problem but now we see a a growing number of plugins that use progressive features of themes that use progressive features maybe the manifest is something that should be managed by this theme and as soon as we have multiple modules like themes and plugins that all use those features we very quickly will have conflicts let's take the manifest file there can only be one manifest file per website if you have a theme and a plugin they both try to register a manifest file that will at least one will fail also the service worker if you have multiple service worker multiple fetch event listeners you'll quickly have some conflict between them luckily there already is a solution that's a feature plugin by XWP in collaboration with Google and the idea here is to bring standardized ways standardized APIs so we as developers can use those APIs instead of registering our own files let's take the manifest file my plugin registers a new manifest file and if we have that plugin in core I can just hook into that API and add my values to the already existing manifest file that's very important I was able to contribute to the discussion from the very beginning on and I also did some commits to the code and the cool thing as far as I know verpress is the only CMS at the moment that is working on a progressive web app solution for the core and that's a very important thing for the future and I think every CMS especially every module based CMS needs to have some kind of progressive web app implementation for the API so that's it from my side thank you very much for your attention and I think we still have time for some questions about 30 minutes for 30 minutes great what would be or is there a solution for the pop-up that hey I want to send you push notifications obviously the user doesn't know what kind can the developer put their more information like these are the push notifications that I'm going to send you if you accept or that can be put on a separate page then I guess on the website that if you are able to send you or what would be a solution for this because I think lots of users simply decline but they don't know whatever as far as I know there's no way to add more information to that prompt but the thing is how do you handle that prompt as I said it's a browser permission request and if you want to you should do those steps before you show the request and if you go to our own website you will click on the push notification then there's the pop-up explaining you hey we send push notifications I don't know why we do a blog post when we do a blog post something like that and then you can click activate and that's when the prompt is triggered and at that time it's clear for the user oh okay it's about that it's a page well I can allow it but if it's right on the online event so basically the developers at the moment most of the developers are using this in the right way it's like the google map or the geolocation request that's something if you are on the home page and you have no map or anything and you show that prompt the user will think well why do they need that I just decline it and the same thing here it has to be clear why they give that access before you show the prompt okay thank you that's our idea so two comments first one is this year at working bureau it was the first year when they created a aggressive web app where you could check all the talks and you could choose some of the talks and build your own agenda that was very useful because there are three tracks plus two workshop tracks in bureau and you just don't know I need to go now here and there and then you just see your own agenda like compiled perfect use case or you have multiple stuff on your device already and you can just create a device based information yeah it worked awesome, wonderfully and the second comment about how to make that pop-up appear more user friendly and I just think I draw some inspiration from do you remember all those websites who are forcing you to install an exit file to infect your computer like they are starting to download they start to download your exit file and they are displaying a page with html showing you an arrow please click on this file here then you will have a pop-up we need to confirm this well that's a bad purpose of course but we can I think we can draw on that inspiration and build an html page which will actually show an arrow inside of the html saying hey if you press on this button pop-up will appear there please click on the but that makes sense if you denied the request once you want that prompt will only show up once and if you blocked it it won't show up again and then you need to find another way that the user okay I blocked it before because they had a bad usage before but now we need to let's say find a way that the user actually allows it and then you have that arrow that shows you hey here in the browser settings you need to allow you need to allow it but that makes sense if that prompt is blocked by it maybe we can check from the code that it was blocked and change the graphics it was blocked for the first time this is the first time display one graphics saying hey prepare pop-up will appear here please click here this is how this scammy websites work I think we can learn from them yeah which plugin will you use your own plugin or the one that's coming in WordPress core the thing is it's not yet clear what the scope will be of the plugin in the core my personal opinion is that core plugin should be very basic so there should be maybe those core APIs are very important and maybe some fallback solutions as well but at the moment it's not clear how far that plugin will go or how far those core integration will go will you be able to send push notifications by default in WordPress core I don't think so well I don't hope so so it's still the core should provide the APIs and the plugin should do stuff on top of that and my plugin has a lot of things on top of that you can choose caching strategies for each file type send push notifications so if we started using your plugin you would in the future then also update to support those new core features it is already compatible with the xwp plugin I think that works at the moment and I'm not sure I think they will update the version that we did some days but I already implemented those I'm already working with those APIs one minute left so if I go turn the song on mobile device it's possible to receive a notification when the application is closed right we are all working with iOS because when I create an active application I need to create a certificate among the developer then upload it to a fire bed or mobile server something like that because the web push web notification API is not available on iOS I have no idea if and how that would be available that's the biggest problem at the moment the other features they work on iOS what is the last question is there a village to what kind of data can be saved on that like Google maps I'm really not sure about that there is a limit I've read something about each application can only use half of the available space on your device and there you also have limitations and I'm not sure if there is a standard defined yet and it really depends on the device depends on how much space you have on your device ok thank you very much