 Thank you for coming to the last session of the last DrupalCon Europe ever. And we're going to talk about offline, like DrupalCon next year. It's going to be offline as well. And it's about continuing the work we did with the mobile initiative that John led a while back. So why are we talking about offline right now? So you see on the graph that's a number of devices, mobile devices that are in use today and until 2019. That's going to be six billion mobile devices in the world in use in two years. So mobile is very important. And for a lot of people, mobile is the only thing they have. They don't have a desktop. So it's important. At the same time, mobile users don't really install apps anymore. They use five apps and that's it. If they install something, they just leave it on and don't delete them. So on the website side of things, we figured out a way to display websites properly in any kind of form factor for devices because of the responsive tools that we have, APIs, JavaScript, the picture tag, that kind of things. So it works well. But offline, offline capabilities that apps have, we don't have that yet in the web or we didn't have that a couple of years ago. But now we have tools that are good enough that we can use to make that happen for websites as well. So the network, it's the next step of the mobile initiative and the responsive web, basically, because we solved the form factor but we didn't solve the connection issues that we have with mobile devices. Drupal already has everything you need to make a proper responsive website with breakpoints, picture, some JavaScript APIs, poly fields, that kind of things. So it's ready for responsive. And I'm arguing that we should have the same thing for offline since it's in the continuation of the mobile initiatives. We had a mobile initiative which should have been called device initiative maybe because it's just about the form factor and we should have a mobility initiative. It's like if you're on your smartphone in a train, well, sometimes you don't have any connection. So we should plan for that with Drupal Core. If you don't agree, what are you doing here? So how do we make that happen? The Google team has led the way in this space, basically, with what they call progressive web app. It's a set of different technologies grouped together for marketing purpose, basically. And there are three components to a progressive web app. The first one is HTTPS. So security is very important because you'll see later we can do a lot of things. And if you can't control what it's doing, it can get really dangerous and invasive. So HTTPS, then the manifest.json file, it's something that already exists, but it's made better with this manifest file. And finally, ServiceWorker, which is a new technology that allows websites to be available offline. So the manifest file, it holds website metadata, like title, you know, the icon, a few things like that. And it's also enabled operating system integration. So if you're on Android, for example, and you scroll, you go to a website and you click the add to home screen button in the browser, and you get, you know, this pop up. So you want to add a bookmark to your home page. And with the manifest.json file, you can decide which icon is going to show up as the bookmark and what is the default name of the shortcut as well. And once it's added to your home screen, when you click on it, the weights launched, you can control that as well. So you have a sort of very small splash screen that is displayed, and you can control the background, the icon, and the text that is displayed on this splash screen. To use it, it's really easy. You add a link tag in the head of your document. You reference the manifest file. And this file contains all of those properties. And that's basically everything that needs, that needs to be in that, in that file. All right. I mean, I'm going quickly because we have a discussion afterwards. Service worker. That's the real interesting part of those new tools that we have. So basically, when you're on the web page and you click on the link to change the page, the request is going to be handled by this service worker, if you enable it and install it on your website. And this server worker can do a lot of things with that request to make sure that you follow up normally, or you change the request, or you change a few things to make it work better for you. Conceptually, it's like a proxy in your browser. So you're writing a proxy for all the requests on the client browser. And which is why you need some security around that. It's a separate JavaScript file. So it's a simple JavaScript file that you tell the browser to use as the service worker. So it's JavaScript, nothing new around that. There's events and the thing you use to with the DOM. We have a full service worker cache that you can manage however you want. And it's separate from the browser cache. So if you clear your browser cache, it doesn't delete what's in the service worker cache. That way, if you want to keep something until four years, you can. And then you have some more advanced features that are not really implemented outside of Chrome. So background synchronization. So if you're on the DrupalCon Vienna website, for example, you visit the schedule page, you go to lunch, you don't have an internet connection, you can still view the page because it's in the cache and the service worker. And let's say you add one to your schedule while you're offline. So with service worker, you can save this kind of interaction. And when the user gets back online, send it to the server to actually save it in a database and user profile and that kind of things. And you also have push notification. So if your save station is going to start soon, you can send a notification to the phone to say, go to this room to attend the session you booked, basically. It works for institutional website, single page app. It doesn't really matter. So any kind of website you have, you can use it on that. And because of background synchronization and the push notification, once the service worker is installed, you can interact with it even when the browser is closed. Which, you know, it's like any other app that you install on your phone. So it's a bit scary, but you already do that with other apps. So quickly a few use cases. The first one is you can make a website that is available offline. You can improve performance by always serving JavaScript or CSS from the service worker cache. So you never talk to the network to send those files. For example, you send push notification, synchronize data like the event schedule thing. And you can do weird things as well. Because you control the request, if a request is too long, you can just kill it and return an error to the browser. So if Twitter is down, you can say, after one second, I just give up on this Twitter resource and load the page. So that way we can avoid some problem that happened a few years ago when Twitter was done usually. Regularly. Now about the support of this new technology. In Chrome, Firefox, Opera, Samsung Internet, it's available. It's enabled by default. So you can use it on those browsers. And it's progressive web app. So if the browser doesn't support it, there's no error. You just don't use it. It's a usual website, basically. But Safari and Edge are currently implementing this technology. So soon on iPhone that will work, hopefully. We don't know when. So I'll just go over quickly what type of asset management you can do with ServiceWorker and cache. So this is like the normal request. ServiceWorker doesn't do anything. You just pass the request and send the response. If you want to add everything that the user visits in the cache. So you tell the ServiceWorker to fetch the data from the network. And the response is saved in the ServiceWorker cache and sent to the browser. So you always have a duplicate of whatever the user is seeing. And that way, when you have something in cache but the network is down, so you're at lunch and you don't have network, the ServiceWorker can see that the network request fails, look into the cache, and send the cached version to the browser. And the browser thinks that there's data and it displays a website. So you won't see the connection unavailable or something error from Chrome. And now if you visit something but you don't have it in a cache, you can also send like default data. For example, a simple page that says you are offline for anything that you don't have in a cache. That's possible as well. Is it clear for everyone? Yeah. So who knew about ServiceWorker beforehand? Yeah. So most of you. Who used it in a project? Oh, yes. Four or five. Not bad. Works well. Yeah. Okay. So the topic is Drupal and Soso. Hi, Sally. My name. It can be really hard. It can be really easy to get your ServiceWorker stuck loaded into the browser. There's a really good talk, kind of like ServiceWorker horror stories about a big travel website, I think, and they had lots of issues where they just got to this point where it was impossible to unload the ServiceWorker. I've run into that. I've also started a project recently and we spun it out from CreateReactApp, which has ServiceWorker built in, and it was hard because when you're in your normal development flow, it was kind of getting in the way. Yeah. And you want to move a bit quicker and say, oh, I've got to go and empty this now. And that was frustrating. And I know there was an issue open with CreateReactApp where a lot of other people were finding the same issue. They were finding kind of hindrance during development. So it was cool. But it definitely wasn't just saying, plug it in and now I can go. That's what we say. Cash is one of the hard topics of IT. Because you have to manage it, if you make a mistake, it always returns the same response, so you're stuck. So now for Drupal and Progressive Web App. There's a module that works fairly well for Drupal 7. Don't use the Drupal 8 version yet because it's rubbish. And what it does is it creates manifest.json file based on the site configuration and some icons that get from, well, it's default icons that you need to update in your CM and that kind of things. And it gives you a default service worker file that is going to cache all HTML pages. So it was the, you know, the scenario where you fetch from the network, put in a cache, and send to the browser. It does that for HTML pages. And it serves all JavaScript and CSS file from the service worker cache while updating them in the background. So there's already one request late for the assets, but it works fairly well. So that's what you get with the Drupal 7 version of the module. And hopefully we get something similar into Drupal 8 core. There's not been many contributions on that. Some people complaining about, but I don't want people to install service worker on my device because it's mine. Anyway. So that's, you know, contrary to Drupal 7. What I want to talk about today is how we can put that into Drupal 8, Drupal core, what is kind of safe to put in because of, like Sally said, there are issues with caching and no being stuck with the old version of the assets and that kind of thing. So the first thing is that it needs to be simple enough to get into core because otherwise it's going to take months to get in or years. And that's not helpful for anyone. So I don't think we should put like the push support or background synchronization or even put hooks to get that working somehow because it's going to get way too complicated. The second point I want to, you know, that I want you to keep in mind is that hopefully we don't have any configuration on that. So you just enable, you click a checkbox and it works. You remove the checkbox and it's going away, right? So like the big pipe module and that kind of things. So there are a few strategies that we can discuss. Like for example, should we put everything into cache and only use it as a fallback when you're offline? Or should we try to put performance improvement by using the service worker cache to send the assets? And if we do that, like how can we advertise that to developers so they're not confused when something doesn't work, right? And it's those kind of topics that I want to discuss with you afterwards. A few resources like the Google Chrome team has a library to make it easier to manage the assets or like the pass and say everything in, you know, under admin is not cached and everything under style, image style, whatever is always cached, that kind of thing. So it makes it easier to manage. So you don't have to write too much JavaScript and code to make that working. And I mean Google is pushing progressive web app very heavily because when you audit something in the DevTools of Chrome, you have the Lighthouse, how do you say that, like performance rules that are checked against progressive web app. So if you don't have it, you have a lower score than if you have it. All right. So do you have any first feedback on implementing a progressive web app in production? Or if you have questions or anything, please go on the mic. Hey, I'm Chris. So you and I have talked about this, but I wanted to throw it out to the room to get more heads on it potentially. The problem, I am a co-maintainer of the contrib thing, the D7 version that works well. And a problem that we have, or we've identified at least, is that as a pluggable server side component, which is what Drupal contrib modules most of the time are, as a pluggable server component, the way a service worker functions is that you register it to tell the browser that it exists and there is an unregister event to tell it to go away. But if the PWA, if the service worker contrib module goes away, the code that potentially might be telling it to go away goes away. And we don't, no one knows how to solve that. I've kind of looked around for maybe, there is an issue for maybe using a server header. I thought, you know, we could put a post install or post uninstall message that says you really, really, really need to put these three lines of JavaScript somewhere on your website now to unregister it and then leave them there for all eternity until you put another service worker in there. But if anyone has ideas about this or has tried a service worker, kind of got it stuck on a site, this is a pretty real problem and is one of the rationales for putting at least part of this in core so that core can know that the thing isn't there anymore. Doesn't go away. Serve it up. Anyway, it's a pretty tricky problem and I just wanted to throw it out there for people to chew on. Some light questions to begin. Like if you have, so you can't just uninstall it because the service worker is cash indefinitely and say I installed a module and it's there three months and a bunch of people pick it up but person A comes back daily and even if we had a transition time where we said, okay, we're uninstalling, we're leaving just some uninstall code on the website for six months and then we're, you know, sunsetting our service worker, if person Z doesn't come back until a year later, they still have that service worker and then the uninstall code has gone away. There's no way to do, like, I could really just talk, walk you through the fact that this is a problem for like an hour, but it is tough. How is that on the client side? Yeah, it's on the client side. That's the problem. Yeah. Because this is like a client caching problem. But anyway, yeah, starting with the light topic. Given that the initiative is about putting it in core, is that still an issue? Is that you'd uninstall module and it wouldn't be there? Possibly, yes. Because it... Even if we have a separate PWA module in core and if the uninstalled code is in this module, if you uninstall it, you don't have the code. So maybe, and we can't really say, let's put unregister codes on every Drupal website ever enabled by default because that's not really a great way to go about it. I mean, if that's a solution, maybe we'll do that, but I'm not sure. Well, I mean, couldn't you put an option to unregister in core? Because this could be a problem whether somebody's using the Drupal module or there was a domain, the same domain previously had a service worker in its cache. So the unregister problem... The service worker itself has a way to update itself. So there's a lifecycle around updating a service worker as well. So if it's a different one on the same scope, it's going to update itself and not... But if there was one on... If I just bought a website, bought a domain, the previous domain had the service worker, how I currently don't, I still have the unregister problem regardless of whether I had ever had a Drupal site. Yes, that's right. Yeah. So you could potentially put like a clear service worker checkbox on a site. That makes sense, yeah. Yeah, actually I didn't... Like only in core. But then it's a specific issue when you buy your website that's used to have a website. So it's... Yes, yes, you would, yeah. This is a problem that sort of native apps have as well is that once somebody's got it, then you can't take it away from them. So even if they run it again in six months time when they're offline, then they're going to use it. And are we trying to solve something that isn't really solvable? Yeah, well, if we have solutions... Yeah, I really love this initiative. I think what you were discussing... I think you're too tall. Sorry. Discrimination. So I really like this initiative and I think that there should be like this no configuration thing in core. But then if you want to do something more advanced, you should be able to just get rid of the core one and have your own. And it comes back to what you mentioned about getting rid of it. And if you never had this core module enabled, you wouldn't need to have like this unregistered JavaScript that you need to have a solution that I just... I don't know, maybe it just came up but maybe it's not a solution. I haven't thought it through properly. But what if core had like a checkbox sort of like in state, like you would keep... So when you have a service worker module enabled, it tells core there has been one. And then when you uninstall it core just says, oh, there was one and always serves the registered JavaScript. Yeah, but yeah, I know. So the thing is it would be like in... Not really in... Oh yeah, it would be very module specific, but not a module specific, like a module thing. It's a type of module kind of thing. So yeah, I don't think it's module specific at all. Like if we would have like, here's a service worker framework in core and then the PWA module. Service worker is a very... It's a fundamental... It's a specified W3C concept. It's something that we absolutely can build in the core. And then there will be implementation modules like PWA will be a implementation of that concept. I don't think that's... That's easy to... That's an easy argument to make, I think. I don't think that's a problem. No, you just need to make him a core committer. No, but I agree. That could be a good solution for the issue. Yeah. I mean, we did have the disabled overlay checkbox as well, but dependent on the overlay module. So separate question. Great initiative, awesome stuff. Have you... And I like the sort of scoping here that keeping background sync out of scope initially. However, have you done any thinking about that? I've done some experimentation with various technologies, but have you done any thinking about how that potentially could work? Like writing things offline and... I mean, it's... I mean, there are ways to do it with indexedDB, that kind of thing, but the problem is that core doesn't have like one way of doing things. So there's not one way of saving requests and sending them back again. So maybe with the API first initiative, we can make that better, but that's why for now it's going to be in Contrib because we need to figure that out. And like the Google Analytics modules could save visitor data while offline and synchronize back and that kind of stuff, but that's module specific. So the way to make that extensible and easy to use for developer, that shouldn't be in core for a while at least, but I don't have a solution on how to make that easy either. It'd be interesting to have some sort of framework, I suppose, for forms to like submit somewhere that is not to post to the back. It's like a 10-year-old issue, like saving form data. I mean, that's good, but that's... Do you only have like hard questions? No, but that's good to at least, you know, talk about it now. This may actually increase the scope of this. I have not... Sorry, David. Nice, David. Is it common practice or is it even possible to pre-fetch the entirety of a site and stuff it in a service worker? That's possible. In service worker cache. So first load everything, more or less everything. Yeah, it's possible. Like the PWA module does that. You can pre-define a list of URL. You want in cache during the installation, and the module is going to fetch those pages, get all the assets as well, because the CSS names are going to change on all of those pages, but it's possible there. But then you run into the issue of, is it a logged in user? Is it not a logged in user? Okay, that was my second question then. So it's saving a single copy. It's not saving a logged in version of a page. Well, if the headers are different and if stuff are different between the requests, you can save both and serve the right one at the right time, because the cache work with the key is a request and the value is a response. So if the request is different, the response is different. And is it also domain-specific or limited to the particular domain of the origin Patrick? Will it grab off-site? It's only your domain, because, I mean, that's... Well, you can... So say, if an iframe, will it grab the contents of an iframe as well? It will, but you can't look into the content. You can put it in a cache, but you can look into the request to modify the content of the request. But you can still put whatever returns in the cache and serve it again, even if it's not your domain. So like Google Fonts, Google Analytics Scripts, that's in the cache. Matt, I don't have any questions about servers for this, but recently, maybe in Canary, Chrome added the connection info API to the navigator object. Do you think that would be worth it for us to look into adding sort of Drupal API so that people could look at that information, the sort of cross-browser if available, and adjust the stuff they're serving in the browser based on connection info, especially for offline. So, like if a very low-speed connection. So what do you mean? I don't... I don't think I got it. So providing like a easy access to the network connection info that's available? Oh, network connection. I mean, are you like a polyfill for it? Yeah, if it's available. I know it's in Canary right now, in Core, yeah. Usually, we put stuff in Core we use, so if we don't... Well, except jQuery UI for a while. I don't think it's cost-placed to make polyfill for that kind of stuff, but in contrib, yeah, definitely. Okay. Gabe, I'll try and actually talk about something we wanted to discuss here, which was the... Whether to always serve from the network or always from cache, and maybe we can split the difference there and have the service worker implement some kind of timeout policy. So if the network cache doesn't respond in one second or two seconds, then we'll go ahead and fall back to cache. That could work, yeah. But then, I mean, we need to put that up in an issue and get people talking about it, but yeah, that's one of the possible solutions, yeah. Yeah, and I'm sure there are probably... I know there's research out there that shows drop-off times and kind of an expected page download time that we might be able to reference. I mean, yes, but then those measurements, it's usually region-specific, so it depends. For core, I don't know how we would go about setting a limit or that kind of thing, but that could work, yeah. Yeah, sorry, I was a bit late, so I just have to assume. The thing was that you have something running on client side, and you don't know how to stop it, and the module is gone. Yeah, so, and what if you, this client side thing, it just pings some thing from the server, maybe a JS file that is somewhere, and this thing would look different if the module is installed, I mean, it's not installed, and then it knows, oh, it's no longer there, okay, goodbye, something like this. Yeah, that's similar to the idea of the checkbox. They don't have to do anything in core, because if it just looks... Okay, there's a core JS file somewhere, and okay, it's there, but then there's the module JS file, and oh, it's not there, and problem solved for something. Well, no, because even if it's not there on the server, it's still in the browser cache. Yeah, but then the browser just pings the server and says, oh, it's not there, so I have to uninstall myself, goodbye. I don't know if they can uninstall themselves. Okay, I mean, it should be able to do that. Exactly, exactly, and then it has the capability to uninstall itself. If it can uninstall itself, that would be a good way, but I don't know if it can. Gabe, again, are you dead set on no configuration? Because I wanted to get in not next year, so sort of. I mean, it depends what you have in mind. Like, is it for the... to configure the caching strategy for types of requests? Yeah, or the timeout values. Right, yeah, so to me, that would be contrib, because this is supposed to be like you're not very technical, you install the module or check the checkbox, and then it works well enough to provide the website offline and not necessarily make it fast. Okay, all right. It's like website tuning or something. Did you put any thought into trying to integrate with cache tags, cache contacts at all? Well, so because the request, you know, the cache, the key of the cache, service worker cache, is the whole request. So content and headers, it already takes care of it, basically. Or what do you mean, like using the headers for what kind of things? I mean, I imagine it would be possible to keep like a list of invalidation tags and have the service worker only basically send a request to say what has been invalidated since the last time I checked. And if so, invalidate that in my own cache. Oh, wow, yeah. But then you need to maintain a list of that stuff on the server side. So, I mean, it could be done. Vim is not here, but he might have ideas on that. Yeah, that's true. Yeah, bad caching, yeah. Well, for the first step, that's a bit too much, I think, but possibly it could be done, like the CDN integration with Drupal cache headers. Yeah, similar. Hi, Alexander. I was thinking in the same direction as Gabe as well. Like if we do some configuration for the strategies, if you provide same defaults there that work for most people, then the non-technical people can still just enable it and go. But the site builder that does know that it might work a little bit different for their site still has the option to change it. So, I mean, I'm happy to have that in core if we can get it in. I mean, it's only the issue of timing because it takes a long time to do stuff in core. So, just to make sure that we have that as fast as possible for people to use and then make it better over time. Yeah, okay, but on the other side, you don't need to discuss which strategy you want to go with anymore. You only need to figure out which ones you want to implement. So, you can save some time in that discussion. Yeah, but then you see like even setting the default takes insane amount of time, like the image files, like defaulting to year and months. I don't think it's even committed yet. Like the default value for saving the folder in which the image is saved when you upload it. So, even setting default is hard to do, unfortunately. I don't know when we should, when we're supposed to stop. Still. Oh, yeah, that's right. Are there other things that you wanted to kind of present to us and maybe get our thoughts or feedbacks on that you would have some doubts about or? Well, I mean, those are the main points because since I want to keep it simple, the main problem is the uninstalling and after the strategy, it's not that hard to change as long as we agree on it. So, nothing yet. Hi. So, couldn't this go in as an experimental module and then the stuff gets worked out as it makes its way through that process? It has to because I think now the process is to first experimental and then, I don't think we will commit anything stable directly. So, but yeah, it's going to be experimental first. Right, so if you start in that process and you have sensible, defaults and then as it's kind of getting worked out and that way you have less of the pressure of people piling on and yeah. And we can add the strategy is configuration. Yeah. So you don't have to start out of the gate of having all of this figured out. We can kind of just. Oh, yeah, yeah, yeah, definitely that I agree that's the way to go. So, yeah, the media entity I think was because because there was storage, they didn't want to have it as not stable going in. Is there any sort of, I don't know if there is, I don't have enough about it, but is there any like worry that if it doesn't go in as stable, we're storing stuff, we're storing experimental stuff on the client's browser. So potentially if we get it wrong and we don't know what state it's in, can we for sure clear it out or is there any? Yeah, that's the uninstalled issue. Yeah. Okay. Yes. Yeah. Yeah, we need to have a piece of it in core directly without a module enabled and a piece in the module to do the rest of it. Could you maybe start with a contract module that says I'll cash the pages that the user's been to? I think it goes to them. We have that. You have that. That does. That's the PGO module. Yeah. And it has a list of files. Yeah. The history is safe and continuous. Yeah. Yeah. And then could you have some way of maybe saying we'll take the kind of key bits of that into a core module that doesn't have any UI or have a different contract module if you want to have it? Well, it's messy code. So I don't think it will pass anything, any gate in core. It's really bad. And it's like the user issue as well. So if you save stuff as a logged in user and as anonymous, it's very different. And with the uninstalled thing, if core was to ship a blank service worker, would that solve the problem if you uninstall a module? Oh, yeah, maybe. Yeah. So I have a default service worker always there. It's always there. That's just empty any cache that it finds. Possibly. That's one solution as well. He just raised a point that I hadn't really thought of. Do we need to be concerned about the service worker caching things that are only available as when you're authenticated? And do we care if somebody walks out? Okay. I need to check with some people to see if when you're logged in, there's a header that's different all the time or not. Because if that's the case, we won't run into problems. But then you can query the cache either way. So yeah. But there's a header as well. I don't like you. This is another hard question. Yeah, it could add. Yes, for different users. I mean, we need to figure it out. I mean, we can add a new restriction saying only add a new users. I mean, one thing to do would be to perhaps have like an expired cookie that you're checking or when you log out. Well, you don't have access to the cookies inside the service worker. You don't. No, you don't. So well, you have access to request headers, but it's not really the same as. Yeah, that's true. I think the current stance is that if you want something different than what's now provided by the core service worker, you have to make something for yourself in contrib. But we already have this JavaScript framework for things like Ajax and field attached things. And can there be any plans or thoughts to extend that to a service worker? So a contract module could hook into the existing service worker instead of replace it. No, that's the no configuration part because I know that could be possible, but it's going to be. And even it's service worker is already hard to work with. If at the same time you alter stuff in the middle, it's going to be a nightmare. So I did actually put a big kind of a meta issue in the PWA contrib module when I found this thing. And I said, hey, what do you think about splitting this up into its component parts? And there would be a service worker module, the like a manifest module. And then the PWA is a set of configuration, which just depends on these other APIs. And he was like, yeah, go ahead, write them. And you know, it just, you know, that's an API that someone has to manage then. And of course, it's going to be a lot of work. And you've got to make a bunch of architectural decisions that people are going to disagree with fundamentally because of the flexibility of the spec itself. And back porting and yeah, yeah, and back porting everything. And then on top of that, if you want it user friendly, you have to have a module that is essentially, you know, some config wrapped in an object. And that is your user friendly module is just config. So I said, hey, wouldn't it be cool if we did this way? He was like, it would certainly be cool. If you did it. Yeah, so we just stayed with the version that it is now is errors on the side of simplicity, both for the end user and the maintainer at this moment. And it is the most foolproof solution. Although there's other things that that come with that. There's difficulties that come with it. But the service worker, I was trying to explain this to someone earlier this week. You kind of have to think of it sometimes as delivering a signed binary to the user because because everything about a web page is supposed to be decoupled and fall back friendly. JSCSS fonts in particular, all these extraneous assets that come with HTML to make a web page. But the service worker puts you back in a position where if you don't have all of those things, then your thing which is claiming it's going to work properly doesn't work without all of them. And then what if you clear cache once in Drupal and you're referencing, you've got some new HTML, but you stick with the old assets that you had, which selectors have changed and so forth. Then it's very easy for CSS and HTML in particular to get out of sync in a service worker that isn't written the way the PWA is because it basically says, I'm just checking the state of everything now and then putting it all in the cache all at once. And if you put flexibility in there by making a flexible API, then people will just start shooting themselves in the foot very quickly. You should have the power, right? But it's definitely not for a drop in, like turn it on and make it work type module. Yeah. Thank you. And also maybe to light on the mood, the manifest part of this whole progressive web app, we can put that in core right now. We don't need to have any service worker attached to it because it's useful by itself and that replace the 20 meta tags for the Apple icons and that kind of stuff. So we could already have that and have the service worker later. But there's an issue open and it needs contributing basically. Anything else? We solved it. Right. I don't know about that. I haven't seen any advertising it at least. There's like a PWA that rocks website that lists a few like progressive web apps that are in production. Some of them actual website and not just demo. Maybe they use a framework. I don't know, CMS or something. I mean, I did in a session say, if you have experience with other CMS and PWA, you should come. This is a logistics question. If we want to advance this in the issue queue, is the lack of Safari support a non-starter getting this off the ground? Safari what? Safari support. Yeah, Safari support. Especially since lots of core folks use iPhones. And we'll probably find little utility in this. Well, it's a good way to experience Android, I think. No, because I mean, it's a progressive web app. So if there's no support, it doesn't break stuff. So I wouldn't think it's because there's no way to polyfill that. Great less stuff if you don't have some. Actually, yeah. It's hard to sell the value to people, right? If it's not working on their particular device. I mean, Safari is starting to implement it. So it's going to be there at some point. Just not now. Just like the picture stuff. I mean, we had a polyfill for a while and we're about to remove it, I think, maybe. So is the one of the main reasons not to do this thing trip or eight is the unregistered problem? Pretty much, yeah. I mean, so why not pair a... But the blank service worker thing is probably a good way to go about it. Yeah, because I mean, even if there's no configuration, there's the discussion of, okay, what's the default behavior? Yeah, so that's why, I mean, the two strategies, that's pretty much what we can choose from. The rest is maybe too complicated, I guess. But if a fair amount of sites haven't used it with Drupal, then is it hard to actually choose between those without real world experience? Because basically we'd be choosing without having sort of... Oh yeah, because of use cases and that kind of stuff. So that's why we should take the more... I mean, to me, the put in cache and only fallback is probably the best way to go because what we want is for the website to work offline. So that the minimum we need to do to make it work offline. And then if you want to improve it, then you write the code. But isn't that assuming that most people want this for offline rather than performance reasons? It is, yes. I mean, I guess that's probably, I mean, and that's looking at other web apps that are using it. They're sort of emphasizing the... I don't think they would emphasize the fact that it's offline. But if you have a progressive web app, you can, well on Android and Chrome, when you install this progressive web app, it generates APK5. So it's a proper app in your phone. And it only needs a service worker that maybe doesn't even put things in cache. So that's enough just to get like the app feature of the integration, which is probably more useful for people than making things faster. And they can just remove an image and make it fast anyway. Okay, thanks. Is there like a bare minimum that we might be able to tweak in core or provide in core and then allow most of this to live and contribute? So maybe going to the example that they had with the default or the null service worker. Could we make a simple issue that says, we should just be providing this without really talking about providing service worker in core to start. And then it would be easy to have a contrib version. Does that make sense? Right. Yeah, yeah, yeah. That was... Yeah, I agree with the process. The first we do something verbal, no configuration, and we talk about making it better, like with the experimental module process. And that would be... Because I mean, the default are going to be like 200, 300 comments. I mean, not even a default that does anything, something that is maybe in the system module or defined by services.yaml or something like that, that is... It's not a module. It's simply there to clear out anything that was existing beforehand and anything that was put there and then uninstalled. So the blank service worker thing. The blank. Yeah, but it doesn't have to be a default with any... Right. Yeah, yeah, yeah. Yes, yes, yeah. I mean, we could do that, yes. So I guess maybe does anyone has an idea of why we should not do this? Maybe? Actually, yeah. So that would be good anyway. I think we do. I mean, every website has images now. So it's kind of as important. No, I don't know. I'm assuming. Yeah, but the blank one doesn't do anything. Yeah. I mean, it's just blank. Yeah. It does do something. It triggers. Yeah, it triggers. It triggers a heuristic with the browser to create. Yeah. Yeah, so. Like, I mean, if it's just a blank one, then there's like the benefit of having this. Like this is kind of gone. So like the reason why you have this. Actually, yeah, that's true. Yeah. So the reason why you have this module is like you can say I want this. Yeah. Then you opt in into. So if you have a blank one, you're forced to get it. Yeah, yeah. So that's the only time you simplify something. So thank you very much. So we could remove a lot of the scope and say ship a blank one. Yeah. We could do that. Yeah. Or, you know, a next step in. The blank one would be also when the module is not enabled. That's the point. Like we always be there. Oh, yeah. Yes. Yes. Yes. That's what I agree with that. Put it in core. Yes. Yeah. Put it in core, the blank one to handle the uninstall. It's a post uninstall service. Yeah. Yeah. That would. There's still the installability of. Yes. Well, I mean, we need to check. So maybe if there's no like fetch event handler, maybe it doesn't trigger. I don't know. We need to test that. Cheating of it. No, service worker and HTTPS. Yeah. For the manifest, you need the image size, like minimum image size for it to display properly and that kind of stuff. You have to get me. Yeah. As moves to the work. Yeah. Yeah. Oh, yeah. All that stuff is independent of HTTPS. Yeah. There's like four moving parts here. Yeah. Let's solve that. And it's not immediately installable. No, we solved it actually. Yeah. Nice. We should do that more often. Well, I mean, it's simple enough. Yeah. I don't know what you're doing here. I mean, we have 30 seconds for final question and we can do it before trivia. So let's end on a good note and thank you very much for coming. That's fine. Yeah. Wow. It's so cool. Try this stuff.