 You're going to have a lot of code examples, please make sure you can read the text of that size. Everyone in the back, are you good? Yeah. Okay. Y'all have your glasses on, y'all have eyesight that is better than mine, we're good. So I'm Dan. This talk is going to be about the new mobile web. I put the word mobile in there so that I have a better chance of this talk getting accepted. But there's nothing mobile specific about it. The web is the web. It's the same web on your phone as it is on your laptop as it is on desktop. And the things I'm going to show you today is a glimpse of the future of where the web can go, the things that it's learning how to do that make it more competitive, especially on mobile, but also on desktop. So you can email me dcalahanemhozilla.com. My Twitter handle is Tallahad, which is down in the corner, as I was staying on the slides, feel free to tweet at me. And I have stickers that you can come and grab at the end of the talk, so please don't make me take those home. I had to declare them at customs, so I would like them to stay here. So I work for Mozilla and you might be familiar with Mozilla because we make a small open source project called Firefox, which is a free browser that has been really leading in terms of standardization and focusing on the web as something that should be interoperable for 13, 14 years now that the Firefox is mirroring on. What Mozilla does? Mozilla, unlike Microsoft or Apple or Google Mozilla, is a nonprofit. And so our interest in building a web browser is we're trying to have a technical state in making sure that the web stays open and stays compatible and stays interoperable. And you can't have an open public resource of the web if a single company can dictate that this is not how you do X and it only works in my browser. This is how you do Y. You go back to the 90s where you had to choose between the Netscape web or the Internet Explorer web, and we don't want that. So Mozilla is working to keep the web open, keep the web compatible. And the reason the web is worth fighting for, the thing that makes the web special is the URL. URLs are universal. URLs, they break barriers, they transcend borders. If you know a URL, you can go to a website. There's no URL store. There's no gatekeeper. If you have access to the web, you have access to the whole web, barring firewalls or proxies or whatever, but there's no implicit control over who can publish on the web. This is really important when you start looking at mobile phones and the rise of app stores. So imagine seven years ago you live in Nigeria. Nigeria is the top 20 economy in the world. And say you have an iPhone in Nigeria seven years ago. On that iPhone, you'd be able to access the whole web, but you would still have to wait three more years. It wasn't until 2011 that Nigeria got an app store, that Apple daved to release an app store in Nigeria. And so for whatever reason, this move to apps has imposed national borders on content again. And it's just, that's not okay. That's worth fighting against. But people have looked at the web and they've demanded apps. Even though the web can do so much, even though the web has this universality. And why? So if you go back and look at the original message that Steve Jobs had when he announced the iPhone, he said, if you want to develop an app for the iPhone, use HTML5. The way you put apps on the iPhone is with the web. But the web wasn't ready. And it took three or four releases of iOS before Apple said, all right, fine. We're linked. We'll let you build actual native apps for the iPhone. And they won. They won for three reasons. Apps tend to be installable. They tend to be a lot more reliable. You know, I don't have to worry about when I open up my podcast app on a flight, that's going to say, oh, I can't connect because it's an app, it's offline. And apps tend to be more engaging because they can notify you even when you're not looking at the app. You can get a message that says, hey, you have an email, you have text, you just finished your Uber ride, please rate the driver. All those come just in time without having to keep those specific contexts open. You don't have to keep like the Uber tab open to get that. And so apps offer really compelling advantages for user experience and for polish. And they won. And the web couldn't do this until this year. So starting in 2016, Mozilla and Google, along with other browser manufacturers, started really focusing on what we could do to address those three deficiencies. How can we make the web installable? How can we make the web more reliable? How can we make the web more engaging? So I'm going to walk through how each of these things works and how the web solves these problems. Let's start with installation. When the folks get in. So first problem. URLs are great, but URLs really want you to have a keyboard, right? Like it's really easy to type Gmail. It's really hard to, on your phone, tap G-M-A-I-L-dot-C-O-M. Tiny keyboard is pain. What you want on your phone is you want a big, pretty icon you can tap and just go to whatever you're looking for. So I put the Twitter app on my phone. I put, I added to home screen the Twitter website. Can anyone guess which of these is the website and which of these is the app? So the one on the left is probably the website. How do you know? Because it looks terrible compared to the one on the right. The app looks a lot nicer. There's this big quality gap. And when I click on the icon on the left, my browser opens up. And I get Twitter, but I get a version of Twitter that's, you know, the end.twitter.com from years ago. It doesn't look anything like modern Twitter. It works. But I also have the URL bar up top. I have the navigation menus down at the bottom. And so this browser interface also takes up a lot of the room that I wish I had for my app. And if I'm not connected to the internet, I get that, which is also not a super great experience. Where if I'm trying to use Twitter, the app on my phone, it has some tweets that it's already loaded and it's fine. It still works. I don't get new tweets. But if I try to use Twitter on the web, it doesn't work. So how do we fix that? I'm going to show you how to fix all that. But let's start with this problem of just the difference in how these things look when you use them. And we're going to solve that by using a technology called app manifests. App manifests are a standard. Like everything I'm going to tell you today, everything is a standard. There's varying implementation. So Chrome fully supports manifest right now. Firefox, we're working on it. All it manifests is something you can add to the head of your document. You say link rel manifest, point to a JSON document. In that document, you can say things like name, flip cart light, icons, start URL. So no matter where I bookmark this page, whenever I open it from my home screen, I'll go to that root document. I can set the orientation. So if I'm holding my phone sideways, and I click on the flip cart, the screen will flip. So it uses the orientation of the developers one. I can set the display to standalone. We'll see what that means in just a second. But look at this. So flip cart eight months ago took down their mobile website. Three months ago, they relaunched it using the techniques I'm going to talk about. And they've had a lot of success. Because look at this. This is flip cart in Chrome on Android. And you go to the mobile website, and they have a little thing that says, install this web app to your phone. And you're in the browser. You can see the URL bar up here. Normal browser experience. When you tap that button, it tells you go into the menu and choose add the home screen. So if I do that, add the home screen, do a little dialogue, hit OK. And now when I go back to the home page on my phone, I get a flip cart icon that looks just like all of the other icons on my home screen. It doesn't look different because it's part of the web. And when I click it, this is the really nice thing that happens. Because it's set display standalone, notice that there's no URL bar. There's no navigation. This looks indistinguishable from a native app on the phone. It works offline. It's super smooth. I've got it on my phone. It's amazing what they've done. And the only reason you know that this web and not native is if you open up the developer tools. So if you're a web agency, if you're building things with Q-Pool and you have clients come to you and say, well, this is a great mobile site, but I really want something in the app store. I really want something in the play store. Well, maybe you don't need that. Or I really want offline. Maybe you don't need to build an app to do that. Maybe you can do it just with the web. Any questions at this point? Does that make sense? Has anyone actually used flip cart since they relaunched? The mobile, does it work good? Is it good? Yeah? So before we go on, we're going to talk a little bit about the other two problems. So the installation gets solved by the Anapest. The other two problems are that web apps typically have not been reliable. They don't work offline. And second, that web apps have tended to not be terribly engaging. Like, they can't notify you. You have to do all the work to go and check your email in the web app. And to do this, we're going to look at a lot of code. To look at the code and understand it, there are some new syntax in JavaScript. The first are arrow functions. We'll see these a lot. It's just a shorthand where you can say arguments, arrow, return value. So these two lines are equivalent, but one's just a lot shorter. Does that make sense? Anyone have questions about that? Second are promises. Promises showed up in ES 2015. And they're a new way of handling asynchronous code. So JavaScript is naturally asynchronous. And the way we dealt with this in the past has been by having these giant nested pyramids and callbacks, which is a huge pain because every callback you have to handle errors, you have to do all sorts of other work. What promises do is they let you flatten that pyramid and have a chain of functions that get called. So in this case, I have a function getData that calls fetch. And then when the fetch is done, fetch returns a promise. Promises have two methods, then and catch. Then says when this finishes, then pass the result into this function, which returns a promise. Then when foo finishes, pass the result to that into bar. And if there's an error in any of these three functions in fetch, foo, or bar, that error gets passed into the handle function. So it lets you do all of your error handling in one place at the very end, which is super, super convenient, results in much neater code. And it lets you do things like, alright, so I'm going to try to get data and then I want to take this process data and do whatever, but this callback that all the rest of the chain has finished. You will see this a lot because promises are being based very, very deeply into all these new web platform features. So fetch is a promise-ified version of XHR. So if you're doing, like, AJAX requests, and you're used to XML HTTP requests, fetches are a replacement for that that's much more ergonomic, but it's based on promises instead of callbacks. Service workers push, permission APIs, all of those are based on promises. And there's an upcoming extension to the syntax of JavaScript, a simple way to make it even easier to write asynchronous code, but all of those are syntactic sugar on-top of promises. So they still behave the same way you still have to understand how promises work to take advantage of some of these new features. The thing to keep in mind for promises is they're basically a very simple state machine. Promises can be in one of three states. They can be pending, and a promise will only ever transition once. It can go from pending to fulfilled, pending to rejected, and that's it. It will never go backwards. It will never change from fulfilled to rejected. And what this says is, like, all right, if I go and try and make a network request, I say, like, fetch data, then do whatever. So that promise will start out pending. And then when the data's available, the promise will become fulfilled and it will call all of the .then callbacks that have been registered on. So we're going to use the living daylights out of them and service workers. So what are service workers? Service workers are the second key technology that lets us solve offline and push notifications. Service workers really simply are JavaScript programs that have superpowers. So a service worker can run a single service worker can be shared between multiple tabs. A service worker can run in the background without any tabs open. Service workers can be programmed to act as a proxy between your website and the broader internet. And this is what's going to let us solve the other two problems with the mobile web. Service workers are pretty straightforward to use. You check for support by checking if the service worker property exists inside the navigator object in your front-end. If so, then you call NavigatorServiceWorkerRegister and pass it a path to a script. This scope is the root of the domain. So this service worker can control, can interact with, can intercept requests on any page of my site. I can restrict it to another domain or another sub-path of my domain and by default if I left this off it has control over things where it is and below. So if I didn't have the scope argument this service worker would be able to intercept any calls, any network requests and not things in other folders. So you register the service worker. Because service workers are so powerful you have to do this all over SSL. Your site, the service worker, both have to be served over HTTPS. In the past this has been a big technical and financial hurdle. You have to go pay like Komodo $800 a month for their gold, platinum, whatever certificate. Not anymore. Let's encrypt. Does anyone use Let's Encrypt in the room? Some people on that part. So Let's Encrypt is a free certificate authority that Mozilla, the Electronic Frontier Foundation, Akamai, Facebook, all of these companies have come together and said it's too important for financial barriers to keep people from securing content on the Internet. So if you need an SSL certificate Let's Encrypt will issue certificates for free, automatically and with no restrictions on their use. You can use this for your business, you can use this for a wider encryption. So you'll need to go get a certificate from a provider like Let's Encrypt. So background, done. How do we get offline support on the web? That's where apps win. Apps by their nature are offline first, online second. The web by its nature is online first, offline second. So we have to find a way to bridge that gap and a way that feels natural to the web. API that lets you programmatically build and manipulate caches. Every cache has names. You have three APIs that you really need to know about. Caches.openDelete and match. So open opens a cache. It returns a promise that will resolve to that cache and you can then manipulate the cache, put things into it, pull things out of it. Second is delete, which will completely kill a cache. It resolves to a promise that there's a Boolean that says successfully or no, the deletion failed. And then match, which takes a request. So I can say caches.match slash babeicon.ico and if that icon is in my cache, then this resolves to a response containing that data. Does that make sense? Okay. So once you have a cache, five key APIs add, add all, put delete, match. Add an add all will take a request or an array of requests and let you fetch them from the network and save that response into the cache. So the only things that ever go into the cache are things you put there. You have complete programmatic control. Put is something that's a little different. Put takes a request and a response. And so you can say, instead of saying like go out to the network and get this and cache it, when you see this request, give me this response. So you can generate things programmatically and like completely client side fake out, like build these things for the cache without ever getting the network delete, remove things from the cache, match, looks things up from the cache. So match, you get a response back. So the way you might use this is you might want to preload on the first time you hit a website you might install a service worker and then inside that service worker all fires when the service worker gets added to the page. And I've got an array of content that's not going to change my main JavaScript, my icons, my home page. And so I'll go ahead and open my cache and then cache add all static content. So I pass it this array. And what this will do is we'll then send off five requests in parallel for each of these resources. And when it gets in that, the service worker acts like a proxy between your website and the Internet. The website has no idea that the service worker is intercepting its request, it's modifying its request. The website's just trying to say go get me app.js. When that happens, the service worker receives a fetch event. And instead of just responding naively and saying all right, go up to the network and get this, what we can do instead is say actually respond with and try to match in our cache the path that we were trying to look up. So it's all right, match this event request, and then if I got a response, return the response. If I didn't get a response, if that dot code was not in my cache, then go infect it from the network and return that. So what this will do is it basically lets you hit the cache first, if the thing isn't there, then you hit the network. Does that make sense to people? 20 lines of code. And all of a sudden you have things like the cookie decks, which is an index of cookie mons, which if I go into airplane mode, open up normal webpage, but if I try to refresh, it works. It all reloads. Despite the phone being completely disconnected from the network, because all that data was preloaded by the service worker. You can see how that works right here. So you've got this array of static content. This is the actual text.org. So you have all the JavaScript manifest icons. And then down at the bottom, we'll see where it's at all. All right, so you say, all right, cache at all static content. So you pass those paths in there, add all those things to the cache, and at the bottom they have that same exact event listener. Whenever this fetch that comes in, try to respond from the cache. If that fails, go to the network. Because everything the site needs is in the cache, everything works. So if I come over here, I can again turn my network off and reload the page and reloads. And everything works. I can close the tab, I can open the tab. Just like I'm online, but I'm not. And all it took was that one little line, that web page itself didn't have to change at all. It had to install the service worker. But it's otherwise just sending the normal network requests. Instead of those coming from the web, they're being responded to by the service worker. They've got normal response headers, they've got normal response bodies. Super great, because what this means is this means you can add offline capability progressively. You can set this up in your app right now. And if you're visiting that page with Firefox or Chrome, you have offline support. If you're visiting it in Safari or Internet Explorer, well, you don't have offline support, but nothing breaks. Because it just doesn't know there's a service worker there, doesn't know how to run a service worker to respond to those requests. Let's turn that back on. Does that make sense? Programmatic catch. So the cool thing is it's not just limited to offline support. You can do all sorts of amazing things with service workers because it gives you complete programmatic control. You have a request come in, you can catch it, you can modify, you can generate your own response. And we have this cookbook at service workers, like ServiceWorkE.rs, that has all these examples, one of which I find particularly interesting is a virtual server where the service worker code for this basically has this list of quotations. And when you try to hit API quotations, the worker intercepts that request and just responds with the data it has locally. Or if you try to put, you know, sort of delete our post each GPU verb, it also intercepts those. So if I go over here and I say, all right, add to bar. You see I did a post, but the service worker responded instead of this actually going out of the network. Despite this being targeted as posts to, you know, API quotations on my server. It's intercepted by the browser. You can do crazy stuff and you can mock up entire back-end APIs completely client-side using a service worker. So that's offline. And then you can do a quick report. What about engagement? What about things like push messages? Push is one of the few things that I think is undervalued on the web. As far as I can tell, the majority of my interactions with my phone are driven by push notifications. I get an email, I get an SMS, I have a download, Facebook message. I pull up my phone and I look, and it's just there. I don't have those sites open. The notification is there, I touch on the notification, it takes me to the right place. This is hugely valuable. So there's an example notification on Android. Here's an example web notification. They don't exist. This is terrible. If my main way of getting to apps and being reminded of things and getting into things deeply is through a notification. The web can't give notifications. It's not useful. Now it can. So Facebook has actually been using Chrome. And they look absolutely identical to a native notification. You can see a little Chrome icon there. But otherwise you have an image, you have text, you have a title, you have a URL. If I were to tap on any of those notifications, it would take me deeply into the right place on the Facebook website. So what could do this now? Firefox just gained this ability three weeks ago on desktop. We should be rolling out on Android in just a few more weeks, and it's pretty straightforward. So the way you push is you have to get permission from the user, because it's going to be really annoying, right? The sites, when you weren't looking at them, could show you notifications on your home screen. So again, we're using service workers. And what we're going to do with the service workers, you can say navigator, service worker, ready. Ready is a promise that resolves to be active service worker. This is kind of how you get a reference to the service worker on a page. Then once I have that reference I can call on the registrations push manager property I can call subscribe, which is like set me up to receive push messages. Now, because this is an API that could be abused, we're going to give you a prompt that says, hey, this site wants to give you notifications. Do you want to allow that or not? And you have to, as a user, explicitly grant permission and say, yes, I'm okay getting push notifications from this site. But as soon as you click allow on that page, the rest of this promise gene will run. So we'll get a subscription object back and inside that object is everything you need to know to send a push notification to that browser. And it's actually really straightforward. It's just an HTTP endpoint, like you post to it and a push notification happens. So what I'm going to do is I'm going to take that and I'm going to use the fetch function to post that subscription as JSON to a back end on my server. So someone said I want to subscribe to push notifications. I have a reference. I'm like, all right, well, if I want to give you a push notification, I have to have this data. So I'll send it to my back end, shove it in a database. I can use it in the future. So I'll get this way to interact with people. Let's actually take a look at this real quick. So what this might look like is here's a serialized push endpoint. Got this property endpoint that has this enormous URL on it. If I copy that, all it takes to actually send a push is curl. So I can say curl X post header TTL zero. So if the user is not currently online, the TTL zero says only send this push if the user is currently online. They're not dumb. Then use that URL, turn, and when the network works, what we should see is a notification. Let's try another example. Service workers. Maybe the network's really slow. They're simple. All right, so double check. A lot of notifications. Do that. Close the tab. Network. All right, so I swear this works on the network. I'll have to debug that later. Anyways, all it takes is a push. As long as the user is online and ports aren't blocked, the service worker gets a notification that says, hey, you have a push. And then it's up to the service worker. So the service worker can run even if none of the tabs are open. It's like, if Gmail was doing this, you could close your Gmail tab, reclaim all of that RAM. And then if a push came in from Gmail, Gmail's service worker would wake up and this event listener would run. And so what this gets is it gets an event. You can say, all right, well, I'm going to do some stuff, I'm going to do a self-registration show notification. I can get that title. I can get that body. I can get that icon. I can connect actions to it. So you can actually see the history of, like, the previous ones that I was testing. They show up in the normal system, system training, like, when I click, they can take me to the page that spawned the notification. They'll reopen the tab even if it's not previously opened. And they show up just like native notifications. So on OS 10 they look like that. They look normal on Linux. They look normal on Windows. And you saw on the screenshot from Android, they can look completely indistinguishable from native notifications. The support here is still kind of shaky. So Chrome can do this, but the way you interact with their server isn't in a simple host. You have to, like, register with Google before you can push to Chrome users, which is weird. But they swear they're fixing that. So that's kind of the broad overview. The web can be just as installable, reliable, or as engaging as a native app. And it can do so progressively. You can implement all of these things right now, and if the browser you're using doesn't support them, no problem. The web just keeps working like it always has worked. But once that user's browser supports things like service worker or push or app manifest, your users transparently and automatically start getting a better experience. So this is the sort of thing that you say to a client that says, oh, well, you can make a great mobile website, but what about offline? You say, well, we can use a service worker, and it'll work offline for X% of the web right now and the rest of the web in a year. And maybe it's worth just building that one code base instead of going through the regular role of having your mobile web experience and your Android experience and your iPhone experience. Because the web is able to do this now. It's just not evenly distributed yet. So I wanted to leave a lot of time for demoing questions. The most important thing, this service worker's cookbook at serviceworke.rs is absolutely phenomenal. It shows you all the things you can do in terms of using a service worker to relay messages between tabs in your site, pushing with notification payloads, and everything has annotated source. So you can go in and see, you know, all right, what does what and why. I'm going to try one more time to see if I can get that push to work normally. There's push notifications. See. Okay, so it's making it to my back end. Fine. Air connection refused. Okay, so something with the network here isn't letting me actually get out to the push server, but I suspect that other notifications would have trouble too. Anyway, so I want to go to questions and live coding and focus the stuff in response to what you want to know. These are the fundamental technologies. Don't forget to write the section in the bit.ly link there. What questions do you have about this? What about mobile Safari? Mobile Safari. Let's see. I don't have my auto-complete. There you go. So platformstatusmuzzle.org tracks a lot of stuff. So push. No signals from Safari or Opera right now, which is unfortunate. Service worker. Considering not there yet. Basically, these things have landed in the production, the release versions of Firefox and Chrome and Opera. Apple is excited about it, but Apple moves a lot more slowly for JavaScript APIs, which is unfortunate. How about the majors that are working? Sure. You have similar limits to what you have with index gaming, where you get several megabytes to use for free. Otherwise, you might have to prompt the user for more space. But generally, just shove stuff into the cache. It should work in all but like the very largest of sites. This is the sort of thing that, especially if you're using Hubbose Triple and you're doing, you're really just sending your data and then doing all the templating and running on the front end. That's a great use for this because you're just caching what you need to reconstitute the front end view. All this application will work for the real-time data, this caching mechanism. The which mechanism? This caching mechanism. Sorry. Caching mechanism. Caching mechanism? How you have used your right. Yeah, so what I've been doing is... If that was a question, could you repeat it? How this type of application will work with the real-time data? No, he... Oh, so yeah. Yes, yeah. So how will this work with real-time data? So you have complete control over the cache. You can do whatever you need. You can bring things in, cache it, and then say, all right, well, also make a network request and get the things from the cache and make sure that nothing is outdated. It doesn't necessarily, like, you have to do your own WebSockets if you want to have, like, actual events getting pushed into the browser. Push notifications aren't necessarily for anything other than, I want to show something to the user. But you can play, service workers play really nicely with WebSockets for... All right. So when you simply cache, like, this bulk batch data, and then just stream the updates, you can put those into the cache too. Does that make sense? We have been using AppCache. It's not a great technology, but we have been using AppCache for our caching, and it's been really okay. And what are your thoughts about AppCache? So the difficulty with AppCache is that... which is a previous technology that has pretty wide support for doing offline. AppCache is a solution that if you are using... offline exactly the way that AppCache wants you to do offline, it works pretty well. But it's very opinionated about how offline should work. So if you wanted to do something more esoteric, or if you have one place where what you're doing was different than what AppCache expected, everything falls apart. Like, there's a wonderful talk from the full Fremont conference in 2013 where some Gmail engineers say, you know, we had this problem. We were using AppCache, and we were seeing these huge memory growth when we left Gmail, but we couldn't hear what was going wrong, and it turns out that the Gmail engineers have misunderstood some of the nuances of how AppCache worked, and so they're just caching every single version of the entire Gmail app every time they refresh from the app. That's like, AppCache is just hard to use right. So the idea with service workers is it's a very simple API. Like, you have to explicitly say, put this in the cache, take this out of the cache, and we've seen a lot more success with that. And it's also more flexible. Right, so you have to use AppCache if you can't rely on, like, wage firebox latest Chrome. We are actively working to take AppCache out of the firebox. So, and that's, there's similar signals from other manufacturers. So if you're using AppCache now, like, now's the time to start moving to service workers, because that's, we've decided AppCache is a dead-end, kind of collectively as browser vendors. You know the problem with AppCache, some things might not work. Right. So we'll go away until service workers are more broadly supported, but service workers are the next answer. Yeah. So what are the limitations, like, if you were thinking of, like, a generic Drupal module that, say, like, loaded every URL and stuck it in the cache, or would it, I mean, is it all in memory? Is it going to, you know, put the whole entire site into it? So problems are a resource utilization, right? I mean, you're, these requests get fired in parallel, so you may completely kill your user's man, unless you have some nice throttling, like it initially installs. Just using space on disk, but you can set things. You can pull whatever you need in the cache and whatever format you need. Disadvantage is just, is it worth it? Are you, should you load everything? If you're, if you have a very big site, it may be better to load things as the user navigates around, and keep, say, the last 15 or 20 pages that they visited in the cache, and you can, you can implement this all, you know, program admin control and say, I'm going to put something else in, evict this other thing, and you can manage that as you need to. Thank you. Yeah, I don't, as a non-triple developer, I can't specifically answer your question as to, like, what would a module look like? But I suspect it would be possible and wonderful. You know how they say that do hard problems in computer science? Everything's in cache evaluation. Are there any mechanisms that address the second with service workers? Because it just seems like it shuts off all the cache, what do the service worker do? Right, it basically does. The way you get into the caching melody is, like, you have to, you have to deal with that yourself, and you have to hope that either you get it right, or that somebody else has written a nice library for it. The nice thing about the responses you get back, from the service worker, you say, like, all right, match this request and show me a response that I could use. That response is a full response object as defined by the fetch standard, so you can look at, like, headers, like, should this have expired by now, the response looks like the normal caching mechanisms that HTTP uses. So cache control headers and whatever. You just have to be mindful to do that. The other thing is that service workers get reinstalled at least every 24 hours. So if you have, like, a bummed service worker that, like, you wrote it wrong, it's totally terrible, you can put a new version up and your users will be using that new version within 24 hours, like, as part of this. You can have something that listens on initialization to say, okay, on the install event, what I want to do is I want to look at all of my caches that exist and, like, you can add a version name in your cache name and say, all right, well, copy these things out of that old cache into this new cache, drop the old cache, you know, re-instantiate things, whatever. So you can have this kind of, like, multi-tier thing. It's really roll your own, but it turns out it's not going to be that bad in practice. Just to answer my question, there was a, there already is a module for Drupal, but it smells really good each day. Anyone's interested? Yeah, so I'm not a Drupal person, like, other than I used Drupal 3 back in the day for a while. Then I went to work with Reson, and then I went to Python, so, like, I've been way out of the woods in this, but it's the sort of thing that I would love to, if anyone here has the expertise and wants to start working on that module and improving it, I can answer the questions about the service worker side and you can answer the Drupal side, but you can build something really beautiful. Yeah, do users have any control on the cache and they drop the cache? So, not directly. I mean, through the browser DevTools, the user can go in and start a debugging session inside the service worker and clear the cache. You install it as an application. You don't have the browser manual. Oh, sorry, I can't agree with you. You don't have the browser manual. So can you, like, the very first part of the sentence? This is an installable application. We're using the manifest. So you install it after that. We don't have the browser manual. Right, right, right. So how do I control the cache? So at that point, I mean, another place where you might want to repeat the question. Right. So this is, the question is, if I do what we saw in the Flipkart video, where I don't have the browser manual anymore, so how can I control this? So in the open question, you could connect the DevTools to your phone. It should be exposed in, like, the Chrome or the Firefox DevTools. You should be able to see the install apps there and access them. Otherwise, things that are cached, I believe it's a separate container from the web. So if you remove this from your phone, if you, like, click and drag to install, that cache should be deleted at that point. I mean, when you install this application, the cache should be deleted. It should. I'm not certain on that. I mean, this leads to a lot of confusion in the users also. As he was pointing it out, when new versions come up, they will not be able to get the new version. So they will say that I am not getting this option in the old version of the application they may be having. So when you deploy a new version, the cache is not getting updated, so you don't get a new JavaScript. And the user has to drop the application once again and just impact that. So you can see from that point of view also, can I take out a JavaScript, put a new JavaScript? So that question, can I avoid this becoming stale? And what you do is, like, again, the basic same rules when the service worker gets re-installed every, like, refresh and re-installed every 24 hours. And so you can, and like, when you launch the app, you can get a signal from the service worker. And you can then, from inside the service worker, make a call out to the network to see, is my information still current? And if it's not, then you can say, all right, well, drop this cache, go pull these other things down, put them into a new cache. It's something you still have to handle manually, because offline is hard. But it is possible to do. It's possible to say, all right, I need updating resources. Go get them. Yeah, one more question. The other question is that, can we access local resources from the service worker, like, on any basis? So the question is, what resources does the service worker have access to? The service worker has a similar continue to a web worker where it has no access to the DOM, runs its own thread, you can't modify elements on the page. You can do things like index DB, off-screen canvas. You can do a lot of data crunching and manipulation, but you can't directly affect the broader page. You have to get it through a messaging channel. You don't have to have the app installed in order to use the cache, right? You can, while you're developing the app, you can always work in browser management. Right, right. So the installation is really just a cosmetic improvement. It works the same way you can develop the same way by just developing a browser. You don't have to install it to get anything other than, like, I want to hide the browser UI. That's the real thing that installation gives you, is the pretty icon and the invisible browser UI. Okay. Hi. So I'm sure you covered this in parts of your talk, but can you clarify, so do you install a service worker or is it something that gets installed? Is it related to the manifest file you showed earlier? So service workers are something that you you have to directly install, I guess I did it right at the beginning. There we go. So in your front-end code, you have to actually call navigator.serviceworker.register and pass it to the path of the JavaScript file that you want your service worker to be. You can have multiple service workers. The only rules that service workers can't have overlapping scopes. So because this worker has a root scope, I couldn't have any other workers on this page. Or on this domain. But if I wanted to have a worker for this section of my site and a worker for that section of my site, it would be possible to stand up multiple workers. Hello. So if I clear the browser cache, then the service worker still works? So if you clear the browser cache, does the service worker still work? Because service worker will still work, I believe, I actually don't know. I would expect this cache to also... Oh, but that would go... Alright, so I'm trying to reason from my first principles. I don't know. That's a good question. Let's find out. So I'm just going to turn this off. And this is the part where I actually don't know where to clear the cache in Firefox, which is super awkward. So don't do that, right? Like I just launched a new profile. Can you tell me? Whatever, we can look at this later. I'm curious about this. I would expect the service worker cache not to be affected in the same way that if you could clear the cache, you would expect things like index DB to go away. But, huh? That's a really good question. No, the earlier version, the version's index DB stays, actually, in other versions. Right, index DB does stay, correct? Yeah. No, the earlier version, the current version does stay. Oh, the current version, huh? Yes, sir. I don't clear caches, which is something I should... Our application, we really based on that feature. Right. So when we went to demo set recent paper getting here, we found that it is a data source. And the older browser keeps the index DB, the latest one, yes, sir. Chrome also plays it. Huh, well, there you go. Yeah, so maybe we would also clear this. Right, which in that case, I mean, servers for which it still exists, they would just start having cache misses and you'd want to have a strategy to deal with that. That's super curious. Now, I'm going to fix this talk and figure that out for the next time. Huh, thank you. Hi, I had a question regarding the incognito tab. So how does that work there? Like, will it be able to store because incognito would be like a private window? Sometimes it varies from browser to browser. I believe Firefox will not let you serve a service worker. Chrome does have incognito. Right. And Firefox as well. Right, but I think that... Let's see. Yeah, so in our private window, a service worker is not defined. So we don't let you install a service worker in a private window. I think Chrome does and then just nukes the whole thing when you're done. So that's something that we should probably improve for the developer experience. Right. But it's something you can't necessarily rely on. But again, the nice thing about service workers is your page doesn't have any logic that ties directly to the worker, generally. So it'll just work normally without the offline support. Thank you. Sure, so where would a service worker respond to each of these post requests? Yeah. My actual question is why do you think why does it have to be responded to? Why would it? So you might want to do something like if you know what the response will be from a post, you could intercept it, do all the logic in the service worker, and then respond much more quickly before actually doing the entire round trip to the network back end. And you can kind of use that as a fast response directly. You did the post, this is the change. And in parallel, still let that request go through. And if you get back something that looks different than you expected, then you can update it. But you can make the cycle look a lot more responsive that way. If that makes sense. Yeah. Thanks. Hello. Actually, I have a question. So can you reach your hand? It's hard because everyone's microphone comes from the same... Actually, only a recommendation for the cache with this capability, something. Recommendation for cache. Browser cache, this capacity actually. And prefer limit for that or service worker to get on its own with something. Sir, can you... I'm saying browser cache, this capacity. So browser cache, like listing the capacity of it? Yeah. Of the browser. When I install a browser, it by default sets some 8 MB or something. Or maybe set 30, 35 or KB. How much data can be stored? How can... Oh yeah, so... Is there any limit? Give a 1GB, dollar, preference, you can take on the desk with something that... Right. What is how much of your capacity? So I don't know the actual limits. That's the thing that is worth... Well, I think we have 5G, 5G and 5G. I have cache on it. You can extend it. Right. But the users answer this back earlier. So I don't know what the actual limits are right now or how to extend it. One question is actually on the side of this one. Sure. Now I think what's the other type of this... NpAPI? Right. So what is the... So the question is, Firefox is dropping plugin support, the NpAPI. What's the alternative for that? The web as a whole is moving away from binary plugins. One of the main things that's replacing that is JavaScript. Right. Implement your decoder and whatever in JavaScript. You don't have the capability, the laser and the data guy plugin would have, but you can take the same speed. So we have a... I don't know if you've looked at ASMJS, which is now turning into WebAssembly, but all the browser managers are working on a... a byte code for the web that can perform within 10% of scene performance. It has, you know, kind of worker-esque permissions. You run your own thread, you can run multiple threads. There's usually a lot of things that you might otherwise need a plugin for. So we can use that to like implement, you can actually implement flag in JavaScript and render it to campus, do it performantly. And then you don't need a plugin for flashing more. There are people over in video codex that do the same thing. So plugins are going away, the replacement is use JavaScript, basically. Who reacted to local resources? How do you access local resources? It's... How do you use signatures and access local resources to do a plugin? It's an open question. It hasn't been... There's no good answer to that right now. Anyways, I think we are at time for a little over. Again, please go break the session. Please talk to me afterwards. I'm happy to hook up things and explore them. Thank you all so much.