 How is everyone doing? Are we good? Yeah, cool. Great. I was thinking about how I was going to start this whole presentation off. And I'm terrible at starting presentations, so just be warned. But I was thinking about the structure of the entire day. And progressive web apps and how we think progressive web apps fit into the overall way that we think developers should be building, or you should be building for the web in the future. And the one thing I was thinking about was every single one of these things that we've talked about in isolation is a great thing for you to be able to take home and work on, for instance. So if you're not interested in necessary progressive web apps right now, but you want to build a great user experience for your users, then you know like Paul's talk around user experience on that side of things is great. Same with HTTP2 and SSL. We want to make the web more secure. We want to make the web faster on the network and side of things. All those things individually will be a great thing for your business and your services and your sites. But kind of putting them all together, we think that that's where the progressive web app part kind of comes together. And I think what we're trying to get to with this is this in my talk, by the way, putting the progressive into progressive web apps. I'm kind of worried about this a little bit, because there's a lot of tension between what progressive actually means in terms of progressive web applications. And one of the things I'm going to talk about is that in the research that I was doing for this talk, I was going back to when we first thought about progressive web apps and when it was first kind of talked about and it was Alex Russell and it was on his site and it was literally a year ago to this month that they coined this term with his wife, Francis Berryman, progressive web apps and progressive open web apps. And when you read the article, it's really interesting, because it starts off with this whole idea of as the user uses the experience more, it becomes more progressively installed on your system, which is not necessarily the same thing as progressive enhancement, which is a very important thing that we want to cover on the web. There was a, like we did talk about it a little bit, the idea behind it is that when you integrate a service worker and you can start intercepting the network requests, you actually progressively enhance the network, you get more speed essentially for free at that point. And I think that's actually quite an interesting way to think about it, because we talk about the progressive kind of installable nature, like if you want push notifications, you don't have to install an application to be able to do that, you can start to get these experiences. If you want them to work offline and be resilient and available, you can integrate a service worker, make them work offline, but you don't necessarily have to have them installed on the system. Your web application, your website is just better by having these features in there. But at the same time, we know that progressive enhancement is important, because we want these experiences to work in every single browser. Like whether you have service worker or not, whether you have JavaScript enabled or not, it's an important and critical point and part of the whole progressive web app experience is that these things work everywhere. And when we talk to a lot of developers around kind of what progressive web applications mean, it is like, hey, we've got service worker, we can make it work offline. And everyone always asks, does it work on iOS? It's not like, does it work in Opera Mini or unfortunately? It's great that it's on Chrome for Android, but does it work on iOS? And I think that's the wrong question that people ask. It's the wrong kind of the concept that they're going to, because our whole idea behind progressive web applications is that your application should work really well everywhere. It should excel when you've got the ability to use something like service worker. And the interesting thing is iOS has got a lot of users and those users pay, they apparently buy a lot of things, which is kind of interesting. But I think it's about 10% or 15% market share. But if you look at it, it's not one browser that's hugely dominant. There's lots of different browsers used by lots of different people. You go to different parts of the world and Tal and Oppenheimer's going to talk about that later. Different browsers like UC Mini, for instance, are incredibly popular. UC browsers in particular are incredibly popular. And we as developers, are we building for them all time? And I don't think we are building progressively across the entire platform to cater for every single type of mobile user that's out there at the moment, or desktop user. And I went through this same experience. I went through airhorner.com. This is my site. It is, Jake's got a very rude word about this, what it looks like, but I'm not going to talk about it. But Airhorner is a site that, it's a simple Airhorner. It's a very kind of small concept demo about what a progressive web application should be. I started off building it on desktop. I was like, this is going to be really easy. I can make this experience work everywhere, and it's going to be instantly accessible. And it's going to destroy the entire app store model because the app stores are littered with these kind of Airhorner's experiences. Like, go to the URL, go to the URL, start using it. You never need to download another app again. That was my thought, at least, anyway. And, hey, heard it. Who's got it? So it was kind of interesting model. I started off on desktop, and then I was like, well, I can make it like Chrome on Android is pretty good. I can make it mobile. Got it working on mobile pretty well. Used a bit of Flexbox. Brilliant, right? And then because WebKit and Blink at the time on Chrome, they're not too dissimilar. They support Web Audio and all the different APIs. Worked in iOS. It was great. And then I thought, like, UC Browser is like iOS at this point. So I was like, that's great. And then last week, someone said, doesn't work on UC, right? And I was like, well, of course it works in UC. I made it, right? I'm not completely stupid. Anyway, you get to the page. It's like that. The really interesting thing is when you start to look at the stats, 20% of the potential user base, especially on mobile, like India is a massive place. China is a massive place as well in terms of usage of this browser. 20% of the users couldn't use my site. They couldn't even see a single thing, right? I looked at the stats. UC Browser users come in. They bounce out pretty much straight away because it's completely useless for them. Hey, that's also the sign for me to get off stage as well, by the way. I haven't run over. That's pretty cool. And then I was like, OK, cool. I'll see what it's like in a Linux browser. Again, right? There's literally no content. That button isn't the actual button for the experience that I have. It's not the you press the air horn and it downloads a WAV file or something. There's an install button that's hidden behind the scenes. And it's like, I just made a lot of decisions in the wrong way. And the thing I did that wasn't the greatest thing was I kind of targeted it off one API, right? It was like, the audio API is the thing that I was building my experience around. And for me, like I said, it's a very small application. It's not probably like any of the applications that you're building today on the web. But it was a really bad thing for me. It's because I was like, audio API has got pretty good support. And I'm kind of happy with that. And I was like, OK, cool. But then I looked at the profile of my users. It turns out this is kind of, I want to use.com, which is the site that I made. But it's all backed by the can I use data. And the idea behind it was that you choose a feature and go, OK, when I use audio, what features do I get for free? I mean, use web audio API, you might get kind of CSS fonts and a whole bunch of other stuff, which I can integrate into my app. And I chose this as the model for how I was going to build the experience. And I think that was a really bad way of actually starting to build my site at the time. Like, the thing I wouldn't try and get across at this point, at least anyway, is the fact that I started off with the technology. It was a demo application. I started like, I'm going to use the web audio API because I have this thing where you press the button and you can hold it and it airhorns forever and ever and ever. And I didn't actually start with the experience that I wanted to build. I did actually want my site to work everywhere by every single user on any different browser. But I just made this kind of decision. And this is what I see when we're building kind of new web experiences, whether they're progressive web applications or just good web experiences. Here we go. I want to use this experience, but it needs a service worker. But you don't actually need a service worker for every single experience that you want to build. But when you do integrate it in, you get a better experience for users who have those browsers. And I think it's more about the features that you want to build rather than just the features. So you want to build a great mobile website. I should have, in my experience, I should have like, well, I'm going to back it off the audio element, which will then allow me to play in pretty much every single browser. And then I just won't have all the same experience inside the site. So I should have started with that whole kind of experiential kind of focus rather than the ability to actually go, OK, I can do something fancy with a web audio API. I haven't changed it. And I think one of the things I was thinking about, and when I was especially looking at Tao's keynote earlier on today, is that the progressive web app model themselves as well is it's more of just a way of thinking about how you potentially architect and construct your applications than the necessary kind of individual different APIs behind it. And I think Aliexpress is a good example. They chose to go mobile-only rather than kind of have a complete desktop solution. But they chose to pick off this kind of tactical battle first. And I think that's a good experience where they followed the kind of progressive web app model. And then they found out that all their users benefited because they were building a good web experience that just so happened to be work even better in the browser that supports service worker, whether it's Firefox, Samsung, or whether it's Chrome as well. And soon to be edging a bunch of other ones, I suppose. But that's the thing is they got more users coming through spending more money and a whole bunch of other stuff because they built a good web experience that was, in theory, kind of progressive from the start, rather than just focused on, hey, this experience is a progressive web app that needs to use a service worker and go from there, which I think is the wrong way of looking at it. And they did the right thing. So I think I'm probably preaching to the choir at this point. But the interesting thing for me when I speak to a lot of people is understanding what progressive means. And the dictionary definition, and I've got it exactly what it is here, is like developing in stages. It's like the idea of you can do things in multiple steps and build on top of them as you go along, which is a decent way of thinking about progressive web development as a whole. Now, the way that we kind of start to think about, the way I at least start to think about breaking it down is like I do want these experiences to work in every browser. Sometimes as a pragmatic developer, I have to target different kinds of experiences to different developers or different browsers, at least. But my whole kind of fundamental thing is I want to get the experience out to as many people as possible and not block on whatever browser the user is using. Because in most cases, the things that I'm building shouldn't be blocked on the fact that an API doesn't support Web Audio because audio can be played on the web. It's a good example. Now, again, with the AirHunter example, I didn't do the incremental approach to the APIs, right? I just relied on Web Audio API in this case. And if I was thinking about it again, I'd probably go back from the start. And then whether you have the diverse set of users, the importance behind why you do progressive enhancement is because you have users from all over the globe and Tal will talk about this later, all over the globe using every single different type of browser that you can possibly think of. So you have to build these experiences, catering for the fact that you have a potentially wide and diverse set of users. Now, there is this kind of... You've probably seen this before in the past. There's an illustration by Dave Stewart, at least anyway, but the core fundamental tenant from the progressive side of things is you make sure you get the content and deliver it to the user. Then you have the presentation wrapped around it. And the proper definition is around adding in CSS and then JavaScript on top. Or CSS to improve the presentation layer and then JavaScript on top of that to actually make it a little bit more functional and maybe a little bit more interactive at the time. But I think the important thing from our side of things is not every experience has a lot of content in it. Not every single site that you build, like Airhorn has not got a huge amount of content, but I still built it wrong. But this is one thing that we built in 2014. We, as in our broader team on DevRel, like Sam Thorogud and Eric Bartelman in Australia and America, built this kind of the Santa Tracker experience. And it's a great experience. Millions and millions of users use it all the time and they get a great experience out of it. But I want to talk about one specific kind of individual piece about it in terms of one of the good things about Santa Tracker is that you can say, well, where is Santa in the world, right? You sit there and go, okay, Santa is in Iceland and I live in Scotland, right? He's not that far away. I need to get to bed, in theory, with the kids, at least, anyway. So Santa exists, by the way, in case anyone's watching. So the idea behind this is like we have this idea of, like we as the developers of this piece of the software, we want to know where the user is so that we can provide some kind of level of interaction to the user. And obviously we chose Geolocation API because the Geolocation API gives us pretty much exactly where the user is based off their current GPS location, whether it's on the Wi-Fi cell towers or kind of satellites and a whole bunch of other stuff. It's a really powerful API, but the problem is like not everyone actually accepts it so you don't get a whole bunch of usage off the back of that. And this is, sorry, I've jumped to slide forward. In 2014, like this was our entire experience. We had, like, you go, well, what actually happened is you go to the page and say, where do you, where are you? And then people would either accept the permission with pretty much no context or reject it. It turns out when you prompt the user, you know, hey, where are you? They're like, I'm not gonna tell you where I am. Like, you didn't give me any context about why you need this. So we had this experience where a whole bunch of users didn't get the full rich experience of like the Santa tracker experience because they disabled the Geolocation, never used it, or, you know, they didn't have the Geolocation API even available in their browser. And we found that we didn't have a great accept rate for using that one particular feature. In 2015, it was changed up a little bit, right? It's like, we know that the GPS can give you a really accurate information about where the user is, but we want to provide this great experience and there are different ways that we can do that. We can have no experience at all, which is like the progressive way, at least in theory in my head. Like, you have no experience at all, then you basically use the IP address to get the Geolocation. And then if you can do some of the things, like if you know that the user's language is in Japanese and there's a good chance that they might be in Japan, if you can't get the Geo information, but then you can tie the two pieces together to actually say like, hey, you're in Japan and like Santa's not too far away. But then if you really want and you want to provide a super accurate piece of information, then you can ask and kind of say, hey, we know kind of you're in Japan, do you want to find out exactly where Santa Claus is? Give them some context and then they can use the API. But the fundamental thing here is that we still as a browser developer, or not a browser developer, as a developer of this piece of software, we still roughly know where the user might be by saying, okay, we're gonna use the existing information that we have. And I think that's one kind of small form of like the progressive experience, is you start from no experience at all and then use all the different pieces of information that you can get before using the more complex APIs. So I think the critical thing that I wanna try and get across in this bit is that you probably wanna know and kind of tactically think about how you're gonna use the different APIs, when to upgrade the user to the different experiences. And some of the reasons why you wanna do that is because not because the API doesn't exist, is because it's behind like a permission or a privilege that says the user has to go, okay, if you want access to geolocation or you want access to the camera, like you have to ask the user, the user says no, like what do you do at this point? And if you've built progressively, you don't have to retrospectively go, okay, cool, I'm gonna add a file element in which lets you kind of pick from the camera, you're just gonna provide that experience up front and kind of just smooth out your development model at least. So that's kind of my rough introduction, we have 50 minutes, it's pretty long. What some of the things we're gonna cover is that our progressive web app model covers multiple different stages of like how you're thinking of building your software, but like around the app shell, like how you construct your application, but also some of the different technologies as well that you can use if you want inside your app, inside your app, whether it's push, install for add to home screen or kind of making your piece of software a lot more resilient to network connectivity issues. So like these are some of the core tendons of what we think like a progressive web app might take. And I'm gonna kind of briefly cover some strategies about what you can do. The first is the app shell, right? Like what most people don't understand is that, well, when you're thinking about it is, the HTML is an imperative language, right? It's an ordered sequence of elements. This is without CSS at least anyway. It's an ordered sequence of elements that are executed from start to top and then they construct your document based off the back of that. And I think that's actually pretty cool because if you look at kind of procedural languages as well where you can have functions and a whole bunch of other stuff, that they get a lot more complex, but, you know, HTML by itself is an actual imperative language. So this is like a rough case study. This is, it's a very simple blog, right? It's not really contextually relevant to a lot of experiences that you're building, but the idea behind this, like if you've ever gone to the Google blog site from the ages and ages ago, like you had to have a whole bunch of JavaScript just to be able to run a bunch of content. It was just a nuts experience. But the idea behind this is like, there's a very simple site. It's created from normal simple HTML and Java or HTML in this case. Just render from the server and pushed out to your site. Now, one of the things that we've seen in the kind of the broader web industry is that a lot of developers are building sites where you have the app shell. Like this is kind of the app shell model. Like a lot of people have been doing this for a long time with other frameworks and just normally in like, whether it's Angular or Ember and a whole bunch of other ones, you construct the shell of your application and dynamically load via Ajax content in. Like this model works really well, right? We can build some great experiences. Like Gmail is pretty much built this way. Lots of other different applications are built this way where you load the structure of the application and pull the content in. But like Paul Lewis has done this kind of nice tweet a while ago where he kind of like ripped apart the different problems that you have when you're building these experiences, when you're trying to build a fast experience with these anyway, is that we'll get given the HTML, right, like the browser will download the HTML. We had all the content before, but now we haven't got the content which means we can't really put anything on the page until all the JavaScript is downloaded, the frameworks are booted up, the JavaScript and CSS are downloaded and kind of done all the layouts that they needed to do. So you have this massive gap between having HTML available, fetching some data and then actually having something rendered on the screen. And like I said, this is like the, like what we think of today as the app shell model and this is one of the ways that we're asking developers to build applications is using the application shell. We know the application shell works really, really well for building certain types, for building different types of experiences, but it's not necessarily the only way that you'd want to build a progressive web application. But it's an interesting model because one of the things that you can do is that you can focus on your content, get everything out as a rendered, so you can focus on your content at least with the app shell model, get your content out rendered in that first request and then like you've probably been doing in a lot of applications, is then start to incrementally take over the experience. So this is just a simple thing you know, if you click on the link inside your application, you'll, sorry, if you click on the link inside your application, you'll go normally navigate to a different URL. Now that's good, but inside like that whole kind of white page refresh model is something that which is a detraction, I get detraction from the user experience, especially in the kind of the web versus app world. So what you normally do and you're probably all familiar with this is that you intercept the click, then go, I'm going to load some content and inject that content back in. That's a perfectly reasonable way of doing it. But one of the things that we're trying to look at to the point right now is that we want you to think about the, you do the page load, so you get the content out, you're still using the app shell model where you incrementally take that over. And if, like Sally said, sorry, I'll go back one slide. If you think about this model where you kind of intercept the content or intercept the link click and load the content, you've probably been doing this already in the past, which is quite a good thing because when you go to this kind of progressive model, we still want you to go and do that, right? So if you have a service worker behind the scenes, intercepting all the requests and kind of loading the content, you have a number of different choices about how you serve that. You can still do the incremental load. So you can basically say, well, not the incremental load. So you can still get the HTML pass it as you go through, render on a server. And if you watch Jeff's talk a little bit, he's going to dive into that kind of universal kind of JavaScript render inside of things where you can render on the server and push out to the content. But we're doing that progressive render. The web has got 20 years of being able to kind of progressively render content to the browser. We shouldn't kind of just throw that away because we want to get to that nice model of app shell and then load the content in. We definitely do encourage you to think about the app shell model, render the content with it and then start to kind of tactically replace that. Like once you know that you're inside the browser, you can do a bunch of different things with the service worker. You can fetch JSON data endpoints and kind of have them cached and pulled through. Or you can just keep doing kind of full on page requests, server rendering, push it out and then kind of pass out the content and load it. There's lots of different models. And I think this kind of progressive rendering approach at least anyway, and the flexibility that you get with service workers helps. So the thing I do want to say is like app shell is a model that we definitely know works. Like it's been used for a long, long time already. We know it works well, but there are many different tactics and strategies that you would use. And I definitely encourage you to look at Jake Archibald's service worker cookbook because I stole a whole bunch of his code to get my blog working. Like my blog is definitely not an application but I want that resilience from a service worker. I want it to be available whenever the user goes back to it. But more importantly, if the user goes to any other page inside my site or refresh the page, it's available instantly. It's not an application, it's a content delivery system in this point for me. And I just chose basically a stale while revalidating method for actually kind of fetching my content. So the request comes in, I'll pull the dates back from the cache always, but always then go, at the same time, go fetch the latest content. And then subsequent requests will then refresh, when the user refreshes the page with subsequent requests, that'll load my new content because like it's already been kind of cached. That worked for me in a model, like as a model for kind of making my site resilient and work offline. And I definitely encourage you to have a look at the different models that you can have to build an experience where the service worker is there to enhance the experience rather than actually say, we have to push everything into an app shell. The other area, and I know Owen talked about this a little bit earlier on, is kind of push notifications. Now, this whole section is, we can talk about it a little bit as well. It's kind of interesting because the push notifications API is incredibly powerful. It's supported across a number of browsers, but it's not on a relatively large number of different operating systems. And like it's not on iOS basically at the moment. And that's another question that we get is like, well, I want to do push notifications, but it's not on these experiences. Like, so what do I do? Well, you know, the first natural thing you want to do is you just want to check the support, right? You can easily check the service worker. You check the virus service worker to see whether you can support push notifications. And then you can say, well, we haven't got push. We just won't do anything with it. But like that's the problem, right? Is that we're not going to do anything with it. There are a number of different tactics that you can use at the time to actually say we can do and give the user more compelling experiences. Even if they don't have push notifications, we can keep the user up to date with important information. Now, there is like a little analogy that we've got is that like there's like the transport kind of eco, like the transport structure that you'd have in kind of any major city. There's a destination that you want to get to. You start at your point A, you want to get to destination, you know, point B. There are many different ways that you can do that. You can take the tube or the metro, the overground railway system, a bus, a bike. Lots of different ways to get there, but the result is the same that, you know, you've got that destination. I think that analogy works quite well for what we like we talk about in some of these experiences at least anyway, because like there are many different ways and tactics that you can actually start to integrate these, integrate different experiences. The biggest thing about push notifications, and this is kind of like, you probably saw this from Owen's talk, you want to be relevant, timely and accurate. The three different main areas that you want to focus on. The timely bit is important, right? Because it's not, you don't want to, you want to get in contact with your user, but you don't want to get in contact with the user all the time basically. It's not your primary mechanism of getting in contact with the user. So you want to think about how you want to use notifications. Notifications normally are kind of most relevant when you have a timely based kind of action that has to happen. You send the request to the server, the user gets it, and then you want the user to action it pretty much straight away. So there are a number of different, I can't use this. There are a number of different questions that you want to ask, right? Many businesses like, like if you've already got a business or a site, there are a number of different ways that you're actually starting to think, like you're already in kind of contact with your users, right? That's right is one of my air words. They say, right, great, dead powerful. So every time you hear me saying that, it's me trying to think about what I'm going to say next sometimes. But you have a number of different ways of actually kind of contacting your user. Well, you know, you might already have their email address and you might already have, like have a regular communication, outbound communication with them. You might already have their phone number, right? So if you have their phone number, like if you have to send important and relevant information, you might want to send an SMS system and like an SMS to them. Like you have other different ways via Twitter and Facebook. I don't think those have ever really taken off in terms of private direct communication. It might change when, you know, the messenger ecosystem and messenger box kind of come out a little bit more. But the important thing that you have to make is like push notifications aren't the answer to everything. And it doesn't matter if they're not supported in every single browser. If they're supported, it's great. You can do really cool things with it in terms of like, hey, timely information, you can send it to them, get into action it. But at the same time, you can do other nice things as well. So the first one is like native notifications. Like everyone knows that native notifications drive re-engagement and uses back into their experience. And it's normally targeted to a single device at the same time, which is great because especially in a major market, most people are focusing on their phones at the time, the current moment. Now, there are a number of different things that you can do where you can have contextual actions. The important thing here for the native is like after your site is, or your application is on the user system, like having notifications is incredibly low friction and that's why we see huge amounts of re-engagement. So if they already have the native app installed, you might not want to actually send them push notifications. But more importantly, many people have outbound proactive email communication with their users. And one of the things that we see is that we don't necessarily use email in the way that we think we could use it. So like you have different way, like you know who the user is, like as an example, right? So you're sending an email to an already signed in user who has already been using your system because of some important action that has happened on their site. You know the context of what you've sent to the user so that you can use that context in subsequent web requests. We know that when a user, like email is a massive driver of web traffic, you know, especially on mobile. So when the user clicks on that email, like you can do things like send them into the important kind of area of your site. It's a really nice way of like engaging with your user where in the past you might have used push notifications to say, hey, this action is really important, go back into your account, use this information, like because we know who you are to actually then go and complete the action. Like email is still just as valuable and probably more valuable than notifications to some extent. And then things like SMS, and like I don't think social is the right one to focus on at the moment, but things like SMS as well, like you can send push notifications, like they are nearly real-time push notifications that can get through to nearly any device irrespective of whether, like of kind of complete network connectivity. Now, I think this is really important because you can embed links in there and then you can get the user to go out. So if you're targeting a whole bunch of iOS users who don't have things like push notifications, but you know who they are and you know their phone number, then, you know, things like push notifications, oh, so SMS are really good ways to keep engaging with your users. And I know people that say an SMS is dying and it kind of is starting to get replaced for a lot of message apps, but these type of experiences are great. And then finally, once you get the experience, like once you get the ability to do those, like, sorry, once you get the ability to make calls, or sorry, rephrase it, once you get the ability to send notifications because you know that the device supports the ability to do it, then you need to make a decision at that point about how you treat your users. Like if you're kind of already sending the messages via SMS, do you replace that experience? And you have to be really careful because you don't want to bombard all your users. Now, re-engagement is one bit from push notifications. The other bit is the other area of re-engagement is, and this is one of the really powerful areas about progressive web apps, is that you have the user being able to install your experience on the home screen. And when that experience is on the home screen, they expect a certain number of things to happen from their side of things. They expect it to be always be available and instant loading. Like once you're on the user's home screen, you're kind of permanently on their real estate, so you have to provide the best experience. And that's why I'm going to talk about the install phase at the moment. Like this install step is one of those areas where we've had things like add to home screen for a long time, but it's not worked as well as we thought. So like I think in 1997, or maybe it was Safari 3 at the time, iOS brought us the ability to add our experiences to the home screen. And Steve Jobs at the time said, hey, like this is the way that we think you should be building applications and experiences for our phone, that you should go off and use the web platform to be able to deliver this. We could make it work offline. We can make it installable, like the whole bunch of other things. We know history played out a little bit differently. But fundamentally, we've always had this ability on iOS at least to be able to get an experience onto the user's home screen. And on Android, it was incredibly hard, right? Like Android hated the web it seemed at the time. They're trying to get experiences onto the home screen was nearly impossible. We made it a little bit better in Chrome. Like there was only like seven steps rather than 12 steps to get something on the home screen. But like it was still a bad experience, right? And that was until we started to kind of like change the whole model and like where we are now with progressive web applications and a whole bunch of other stuff. Like that's like, everything started to change. But the really interesting thing for me anywhere in this space is that everything was controlled by meta tags. There was information inside your page that would allow the browser to say, hey, this is how we think this experience should look and operate on the user's device. So the good thing was you could get the experience onto the home screen. Like you could say, hey, I want my application to be kind of like a full screen application via one simple meta tag. And then when the user kind of pressed the button, it would go onto the home screen. You could choose whether you wanted to be a full screen experience like a native application or like a browser experience, right? But the problem was it was not standardized and it was on every single page. You had to kind of litter your whole site up with a whole bunch of meta tags just to get things working. Even worse, it was completely broken, right? Like the whole space around this is like, when you have an application or a site, like you're an application, you always launch into one specific point into the application, like the entry point into your experience. Add to home screen was bookmark this page and store it in the home screen. So if you weren't already on the home mix, like the entry point into your application, like you would go into like a leaf page, like imagine adding Google Plus, I mean, imagine adding Google Plus to anyone's home screen, like imagine you're on like one of my pages inside of Google Plus and you add that to home screen. You don't want to keep going back to my content, although I'd like it, right? Because I write great stuff. I'd like you to be able to kind of go to the entry point of Google Plus. Add to home screen with the meta tags who would never give you that. You could never get back to the home screen. It was a really hard way to manage things. And then it was even broken even further from that. Like if you did a navigation inside the window, rather than say, hey, I'm going to replace the current page with the new content that's behind this other URL that is part of my application, it would just go, I'm going to open a new window and a new tab. It'd completely break you out there of overall experience. So to kind of recognize that, the other day I actually wrote, it was like, what can I write for this talk? And I wrote a spelling mistake as well. It fixes. Oh my God, that's terrible. Basically, you have the ability to actually fix the way that iOS works. It means that you have to emulate a number of different things and introduce a new meta tag called Microsoft. It's a Microsoft meta tag, msapplications.url. But fundamentally, this polyfill essentially will say, hey, we know that you've got all these meta tags in place, but we want to fix the iOS experience. We want to make it so that it matches like opera's experience, Android's experience, Chrome's experience, Firefox's experience. I've actually gotten onto the home screen. So it does a number of things like click jack, or it does click jack in so that it says, hey, we know that you're still in the experience, like refresh the page content rather than redirecting you out. One of the interesting things is that it's really hard to manage state on iOS and this kind of should get around it. But the really great thing is until kind of iOS starts supporting things like Manifest, then this is a nice model and there are a number of other people starting to think about how you can actually make the iOS at the home screen experience a lot better. And that's if you want compatibility, right? At the moment, you might not actually want to say, you know what, iOS or whatever browser it is, doesn't support it, and that's fine if you don't want to do it. The modern way is to use the Manifest and Jake talked about the Manifest a little bit earlier. The Manifest is a way of describing what to launch, how to launch it, and how it should appear on the user system. And when you meet all the criteria, and I'm going to talk briefly about the criteria, you get this, let's pop up that says, hey, add to home screen, add to home screen, and you get this nice kind of installed full screen experience if you want it. Now, there are a number of things that we do and the whole number of different checks that we have to make sure that you don't kind of get the prompt when you don't really, it's not deserve it, but when you're not actually offering a great experience. One of the things that we want to try and do is we want to make sure that if you launch from the home screen, you get an online experience all the time. Like you never get the offline of source, which is why we enforce the kind of service worker restriction. And we need the manifest because if you're launching again into that non-home screen experience, then you're not giving the users a great kind of like app-like experience, especially when it's launched from the home screen. The big question is, can we bring iOS in line with the manifest and its own use of meta tags? And I think we can, but I will say Maximiliano Fertman, he's done a really great blog post in the past couple of days about all the different things that you have to try and do to actually say, we want to have a compatible experience. There's a number of issues that you have with icons and differences between the two platforms, but there are ways to work around it. But the interesting thing, at least anyway, is that we have all the information that we need. There's a secret meta tag, Apple Mobile Web App name, which kind of maps to the manifest attributes of name and short name. Obviously, we get all the icons and those type of things, which is really good. It's kind of nice. We can say that we want to launch in standalone mode, right? We want it to launch like a native application. If we don't have Apple Mobile Web App capable, then it launches like a normal browser tab, which is another option in the display manifest. We don't have complete full screen, but we have some good compatibility with the two parts of the platform. And we kind of have some emulation around the theme color, right? You can say, I want to get rid of the top bar by saying black translucent. That's pretty nice. There are other bits which are broken, like the splash screen, it doesn't work anymore, which is a bit unfortunate, but we're still kind of not too far off. Now, I think that's kind of interesting, but the thing that I don't want people to have to do is have to then work out exactly which meta tags that you need to install. Now, there are a number of different polyfills. This is the one that I've written. There are a number of different ones coming through as well, where if you can basically know that you've got a web app manifest on the page, you drop a small piece of JavaScript in, and then it goes and works out what the exact best tags are to use. And then it'll make sure that you offer the best kind of compatible add to home screen experience. I think it works pretty well. This is just a demo that I've written. There are another good couple of ones out there. And finally, and I know I'm over time at the moment, is the offline section. Luckily, I think Jake has covered most of the offline story that you need to kind of think about. But there was one thing, again, is that when we talk to a lot of developers out there, it's like, well, does service work on iOS? And right now, the answer is no. And like I said before, it's the wrong question to ask, right? We don't need to build experiences that absolutely rely on service worker. But the thing is people still want offline as one of their core features. So the first thing that they do and ask is, well, I can use AppCache, right? So who's built a site with AppCache? 20 people? How was the experience? Was it a good experience? No? Okay, cool. I mean, there were a number of different issues with AppCache. If you were building an experience today with a new Progressive Web App, say you went away and go, I'm going to build a Progressive Web App and I need to make it work offline, we still need to come up with the exact business case why you should kind of skip the AppCache section. But I do think you should bypass AppCache. The interesting thing, if you've already got a site that uses AppCache and Matt's going to talk about it later, you can add a service worker in and then there will be no conflict between the two because the service worker will take over. So there's a nice migration path off AppCache, but if you're thinking about building an experience, I would just say bypass AppCache completely. There's a number of different problems that it has. It's hard to do good server rendering with it and then if you update, you're kind of manifest and you've been to 100 different URLs which you've kind of all kind of had cached and then this atomic update system is going to, it basically re-requests every single URL. It's a bit of a nightmare to manage. There's a lot of different problems. So I would just bypass it completely. It's a decision that you have to make, but I think you should do it. The one thing I would say is that there are a number of different strategies that you can take. You can build for resilience in the client first. If you're offline and someone has a window open, quite frequently they don't bother to reload it because they know there's an issue. The worst thing that you can do is break the experience. So build for resilience inside the client, handle XHR network failures, cache data locally. And if you look at the Firebase platform and a bunch of other ones as well, they know that they can cache data locally to synchronize when there's some data connection back in, when there's some data connection that comes back. And finally you can start to then layer in things like service workers and extra enhancement to give you that resilience as you need. So that's my thought is I just kind of stay away from app cache at least anyway. Now there are a number of different, like one of the pieces of criticism that we've had is that there are a number of different issues in terms of information and knowledge. Sam Thoregood on my team has launched this Always Be Progressive where we're trying to start to think about, hey, we have all these different pieces of technology, how can we actually get you to think about building systems which are progressive or at least if you wanna kind of polyfill things through as well. So we have this nice little resource, we're gonna keep updating it to actually give you the guidance that you need to actually build these experiences if you fundamentally require some of these features, which is quite nice. One of the things I would say is that we'd have a nice, this is my killer slide, I've gone too far, too far with it, is we have, and we're starting to build out and flesh out our developer portal as well, so on developers.google.com slash web. Like we wanna make sure that you have all the tools that you need to build fast, secure, and performant experiences with a great user experience. Like they're the fundamental core tenants of what we wanna try and get from the web at the moment. And then if you kind of start to knit all those things together, we're hoping that like a good progressive web application experience that comes out at the back of that as well. And that's when you're kind of building in service work on this extra resilience. Now the thing that I will say is that I know and every single business that we speak to, they can't always completely redo their entire site. And I think a lot of this is about being pragmatic. You can integrate all these different components in. Like if you want push notifications, like that's a great thing to add into anyone's individual experience. You don't have to base your entire experience off the back of that and you can provide value to a large subset of your users, rather than have to think about providing the same experience to all of them. But there are a number of different strategies that you can take. And I think that's a really powerful way to think about it is like, you start with a good base, get the content out and deliver it to the user and then think about how you can kind of enhance that experience as you go along. And that was me and I know I've run out of time. So thank you very much.