Test test. Can everybody hear me quite well? Perfect. Welcome to offline is the new black while remaining few people are coming in I'm gonna tell a short story because this has by far been my worst experience flying ever because for the first time my back got lost. I flew here on Wednesday evening and

I normally like I literally almost always only take hand luggage and I only had hand luggage I had a backpack and a suitcase and Somehow I managed to lose my suitcase on the way from security to the gate Because when I entered the airplane, I realized hey wait, I've got my backpack

Where the hell did my suitcase go? And so on Wednesday, I had to go by Thursday, I have to go but I know actually on Wednesday. I have to go buy some clothes Except for this and my jeans and my shoes So everything you don't see is newly bought because I didn't have anything with me Which is kind of bad

Anyhow, my name is Max. I think we can start now. There's no not that many more people coming Please tweet any questions comments and feedback you have about this talk to me at MXS DBR. I work as an open source developer think mill think mill we are a full stack JavaScript

Digital agency from Australia. I am NOT from Australia. I am from Austria, which is not the same country We use tons of node.js on the back end and then react and react native to build websites and mobile applications Which is why they hired me because I take care of Keystone JS Which is our node.js content management system, which you might have heard about and I also take care of elemental UI

Which is our react.js user interface library I've got stickers for them. So if you've ever heard or used them come find me afterwards I can give you some stickers. I've probably good enough for everybody in the room I'm also the creator of react boilerplate, which is one of the most popular reacts allocates at the moment in

2014 I Went to this nice tiny little country called Cambodia Now Cambodia is a country you think about so little that you still haven't realized that that is in Cambodia. This is Specifically I went to this tiny island called Koh Rong right off of the south coast of Cambodia

This island it literally is tiny It has two beaches a harbor a few buildings like two hostels three restaurants and that's it But it's absolutely paradise on earth. It's got beautiful ocean beautiful weather really nice people The food is great and you just spend I originally went there and I thought I'd spend maybe a weekend there

Two or three days at the very maximum and then go on and see the rest of Cambodia and I ended up Having to rush after eight days of being there because I had a plane from Bangkok back to Vienna Koh Rong absolutely is paradise on earth with one small downside Koh Rong gets about two hours of electricity per day. That's all the power Koh Rong gets

There's no lines connecting them to the mainland. So they run off of a generator Now they don't want to carry that much fuel over to the island and they probably also don't have the money to do it So what they do is they just carry a tiny bit of fuel over there and power the generator every evening

Let me rephrase that slightly Koh Rong is absolutely paradise on earth But it only gets two hours of network per day It's all the internet Koh Rong gets because obviously if there's no power that can't be an internet and since it's an island There's no mobile data either So what happens is that everybody that's there at the evening when there's like these two hours of Wi-Fi

everybody rushes to the restaurants against the Wi-Fi and the first thing they do is they Skype with their parents or friends and like chat with everybody and Catch up and then they want to read the news but catching up on 20 22 hours of news That happened all around the world. It's quite a bit of effort

So what they do is they open news articles and they go and write the click on a link They read the first sentence in K That sounds interesting screenshot the first page scroll screenshot the second page scroll screenshot the third page All right next article screenshot the first page and that goes on and on and on and in the end they end up with 150 or 200 screenshots and then when the Wi-Fi turns off again

Everybody just sits there for half an hour an hour just going like, okay first first page read read read delete screen shot Next page read read read read delete screenshot next page read read read read and it just that's just what we do there This is what I like to call the loading spinner of death. It's this endless cycle of

Bobbling up and down that just never stops Has anybody in here never seen this before? I Would have been very surprised The thing is even we people in some of the richest countries of the world have seen this This isn't some obscure problem that some people somewhere at the other end of the world have that's problems that we experience every day

Every single day when I go out of my apartment and I go into the staircase and want to go down I lose connectivity So early in the morning, I'm really tired. I'm reading the latest, you know, JavaScript fatigue rant on medium I'm like, oh, yeah, that's good. That's good Then I click on a link and I go into the stack is I'm like, oh fuck not again

Cuz every single day I make the same mistake, right? I lose every single ounce of connectivity I have it just drops. It must be some sort of furthering cage. I don't actually know but it's really annoying And so I started doing this thing where I preload articles then don't read them Walk to the staircase get into the staircase and then start reading them because I know I was just in the pressing on a link And it's just gonna be gone. The thing is

network coverage Isn't there not even here like having a hundred percent network coverage is not gonna happen for a very very long time The hoodie team who are the creators of the offline first movement They put out this great article explaining their ideas basically and they have this great quote saying

Geography is non-negotiable When you're in a tunnel or in a cave or in my staircase Right, you can't say you can't tell the mountain or the building around me to just go away because I want to look at Facebook it doesn't work. You can't argue with geography and While network coverage is excellent in our countries

it's not even nearly a hundred percent there's tons of problems with network coverage and That's not even speaking about the rest of the world in Reality we as web developers and you as a web developer you need to be there when your users need you The web in its essence is information

everything we do all day long is transfer information and Information is only really useful when it's there at the right place at the right time in the right format, right? We've got the format. It's probably something like I'm a text or images or some videos, right and We've got the place because that's on our phones or on our laptops or something, but the right time

It's useful knowing that my train left two hours ago But it's a lot more useful knowing that my train is going to leave in an hour three hours ago, right? Now this isn't the new problem This problem has existed for quite a while

And so if he gets back some very smart people came together and they said hey, we should change this We should give web developers an option to sort of work around this and they created app cache Which is short for application cache App cache was the first idea to provide developers which with a very high level Yeah with a very high level abstraction over offline behavior

So what it allowed you to do is create a manifest file Which is a list of files and you would specify in there, right? I want my index to HTML file cached I want my main JavaScript bundle cached. I want my styles cached I want my logo cached and then the browser will automatically go and cache those files, right? It all sounded really really good in theory because as a web developer everything had to do is just keep an up-to-date list of all the files

You want to cached and if that just works, you know, the browsers just take care of the rest The problem is app cache is a douchebag That's not something that's a quote by Jake Archibald who used to work at Lenny and now works at Google And it's also the title of an article on the list apart

Which you should definitely look up if you are the user have thought about using app cache Because app cache has a bunch of pitfalls that are very very weird One of the prime examples is app cache To for for your users to get a new version of the application when using app cache the manifest file has to change

That means your users will only get the new version of your application When the list of files you want to cache has changed They won't get a new version of your of your application when the files themselves has changed App cache doesn't care about that. The only thing he cares about is has the manifest file changed How much sense does that make?

Now we all know invalidating caches is a hard problem in computer science, right? it's not an easy thing to do but that's a really weird way to do it and You can work around it by adding things like version numbers or dates into your app cache manifest file in the comment But you have to be aware that it happens Otherwise you'll end up just pushing up new versions of the application and users just still reporting the same bugs

You just fixed because well, they still have the old version of the application that's why very recently a few months ago Firefox went and said Forget this. This was that this was not a good idea. It worked for very simple use cases, but it doesn't work for Many of them. We're just gonna deprecate it. It also has a bunch of security issues and stuff then Chrome said they actually

They just disabled that we should probably do that too And so they're now removing app cache on insecure regions, and they're probably gonna deprecate it really soon entirely A big factor behind this deprecation has been this new spec called service worker Which the same guy who wrote the app caches a douchebag article Jake Archibald with a bunch of other people

Wrote and released and it's not been implemented in Chrome and a bunch of other browsers The idea behind service workers is that it allows us web developers to specify how we want our application to behave When it's offline we no longer rely on an age-old specification telling us how it's gonna happen

We can do it on our own and that fundamentally makes a lot more sense Because if you think about it the app cache behavior might work for something like a news site where you can cache like You know common styles and like maybe some content and some images and that's it But a real-time game a real-time online game

Imagine if you're caching all of the assets for your real-time online game and then the user is offline Opens the game the game loads and renders and then just nothing happens and he tries to move around is like nothing happens That's the worst experience ever. That's worse than not having connectivity With service worker though. What we can do is we can go in and say we can tell the user in our interface

Hey user, you're offline. The game doesn't work when when you're offline. It's a real-time game. We're very sorry, right? It just doesn't work, but we can still give you access to the leaderboard We can still give you access to your profile We can still give you access to all these sort of static things that we've cached previously That means that even when you're in some random country halfway around the world at a real-time game meter

You can still compare your score with other people, right? Now that's all very nice and dandy. But what does this actually look like in real life? So this is the behavior we're going to build we have our browser and we have the server and The browser as always the user enters some sort of URL the browser goes to the server and says hey server

Please give me the files the server goes. Yeah, sure here they are and sends them over Right. There's a bunch of steps in between there. Don't worry about them We don't care and what the browser then does is it starts parsing those files and as it parses the JavaScript files It passes to what I call magic line navigated at service worker that register. All right, there was goes. Hey, whoa

Okay, they want me to install the service worker. It's probably a good idea Let's do that and goes and installs a service worker and the thing is from this point onwards What this service worker does is entirely up to our control this is not some random specification This is a JavaScript file that is running the background

It's a web worker If you know what that is It runs in the background of your browser and it just does things and service workers sort of special Webworkers in in a sense that they get access to API's that web workers don't So we've access to things like cache and we have access to certain events that happen Well, I'm going to show you and service worker that does the following right? We create a cache and then we put in the files from the website to the cache

We stand the behavior and then the next time the user comes around we're gonna catch the request to the website That's what service worker does We're going to check with the cache if we have to fast for that request and if we do send them back from the cache The nice thing about that is it's really easy to do

Now if I just show you code, you're just gonna not know what I mean So I made a little demo for NDC Oslo. So this is what the demo looks like This is without service workers is without anything right which is open a page and it shows a nice little gift Now we're going to service work enhance this The first thing you got to do is in our main JavaScript file actually reduce to the service worker Forget about all the compatibility checks and everything. The important part is this

Navigate to that service worker that register we call this function with a path to JavaScript file It's not just navigated service. We're going to register and the browser does some magic and it just happens again It's under our control Let's take a look at what that service worker file actually looks like, right?

The first things we have in there is a cache name because you can have multiple caches, but we just need one So I'm just hard coding it and some URLs we want to cache which again, you could dynamically generate or something It's a demo doesn't really matter This this is where it starts getting interesting. Right? We have this install event and The thing about the service worker API is really really thought through it absolutely makes sense from my perspective

They have these events and you can listen to them and respond to the events that happen in this case We have an install event which happens when you call navigator the service worker to register Please don't ask me why it's not the registry event. I don't know It's the install event right when you call navigator the service worker the register the install event is called We then do in there we open the cache

With our name and add all the URLs we want to cache to our cache So the next time the user comes around we can send them back now this is like I Know five lines of code six lines of code It's beautiful and it does a bunch of stuff in the background, but it's really usable from a web from a web developers perspective

Obviously, this is not everything we have to do because right now we've cached the files But we don't actually do anything when the user opens the page again Which isn't very useful because then we're just taking away space on a user's hard drive, right? So what we want to do is we want to listen to the fetch event This is where every single request of the user goes through Every single request the user does from from the application or website goes through this event

That sounds strangely familiar. That's like a man-in-the-middle attack Which actually it is which is why service workers can only be registered on secure origins They are really really powerful, but in the wrong hands, they can really mess up everything

So service workers only on HTTPS, which is a caveat But you know, it makes sense because you don't want to have a man-in-the-middle attack from somebody somewhere You know don't want to have that. So what we do in the fetch event We respond to the event with a match from the cache So we check if the cache has files for this specific request we got and if we do

Then then we simply return what the cache has cached to the user and the user immediately sees the page. That's it But if we don't have a response, which you know might happen because there's ajax requests and those sorts of stuff What we can then do is clone the request now. Why do we clone the request? Why don't we just reuse it? Requests and responses are read once only so we can't actually use it again. So we have to clone it and then we do this

Which is basically just fetching the exact same request the user just did again because we don't have it in a cache We only have to clone it because again, it's read once and it's read once only then we get a response from the from the remote server back, right and

If it's an error, we don't really want to cache it Like that's not a you don't want to do that because if the server is temporarily down and you use it Goes to the page and sees an error and we cached it. The next time the user goes to the page He's gonna get an error as well, even though the server might be up doesn't make any sense So we just return that to the user directly If we do have a good response What we do is we clone the response again because we just read it and you can only read it once

Sorry, no, we haven't yet Here is where we read it because we open the cache and then put the request With the response we got back from the server into the cache So the next time the exact same request comes in we can simply return it from the cache and it works and then we return that to the user and

The user gets the page so in worst case scenario If you don't have to request saved really what happens is we run through about 10 lines of JavaScript code There may be some underlying browser stuff, but it's not gonna make any loading difference if we have to request cached It's basically gonna be instantaneous. Let me show you so this is the same exact app

I'm going into airplane mode because we don't want to have any network connectivity. I opened the app and Surprisingly it loads Now just to show you that we're really offline that I'm not doing any cheating here I'm trying to open up another page and you'll see the chrome, you know dinosaur game We are really and truly offline. There's no net network connection there

You can play the dinosaur game if you want to and if you didn't know this game, it's brilliant whenever you're you're offline just click the spacebar and it works and The point is we can go back to the page and refresh it as often as we want, right? And it just works. That's just it This demo is online by the way, if you go to the URL it says down there

You can just visit it and try yourself if you have an Android phone and Chrome There's a great resource by Mozilla called the service worker cookbook and a service worker the RS And it has these sort of recipes ranging from really easy recipes like the caching one I just showed you all the way to really complicated ones like the request deferrer where they use a service worker to intercept all the requests and then

record them in a queue and If the users offline what they do is to return a fake response pretending they're online So you can optimistically update your UI and you'll have to show the user. Hey user We've tried to send it. It is in a queue. It's not sent yet

But as soon as you go back online We're going to sync with the server and that's exactly what they do in the service worker As soon as the user gets back online the flush out the queue Replaying the request in the exact same order they came in basically syncing the user state to the server This is a really nice user experience. It's a bit more complicated than example I just showed you which is why I don't want to go through it, but it's beautiful. Like it's really really good

There's one slight problem with service workers. Oh, there's two slight problems One of them is the HTTPS thing right only on secure origins. Second one is browser support, which isn't very rosy at the moment it gets a bit better when you look at it from a usage-related perspective and

One important thing I want to point out is this browser over there on the very right You see browser for Android who in here has never heard of you see browser for Android. That's about half the audience I think so You see browser for Android in Europe for some reason in America. Most web developers haven't heard of it It's freaking massive everywhere else as you can see on this charge. This is from can I use really up-to-date browser data, right?

You see browser for Android is used more than Internet Explorer All the versions combined if you have no idea what you see browser is get an Android phone Download it and test your websites on it forget about Internet Explorer test your browser on you see browser because a lot more people use it

It's ridiculous. Um Anyhow, so that sorry that was a slide aside Service workers are not yet if supported everywhere, but since app cache is deprecated. You don't really have another option The thing is we're not really done yet because the real problem is the web is sort of there with this eternal battle between web

Applications right ever since the App Store came out Native applications ever since the App Store came out Sort of been this well the web is better and then no the apps are better and then no the web is better so can can we do some more like now we have offline can we do even better and Obviously, I wouldn't be saying this if we can't right

So one more manifest file. This has absolutely nothing to do with app cache, right? This is the so-called. I think it's the real name is web app manifest, but I don't think anybody really knows It's just called manifest. Just remember that so in in iOS when you open a page in Safari on iOS since very early versions of iOS because Steve Jobs thought

That the web would win against apps which apparently didn't happen because they made the app store No idea what that was You can click at the very bottom if you have an iOS device you can try that afterwards and click add to home screen It's gonna add The website to your home screen just as if it was a native application with a favicon and sort of some you know Your title as the text below it

Now Android didn't want to have didn't want to be left behind. So since Chrome 31 on Android They you can do the same thing. You can add websites to your home screen It's going to do the exact same thing, but then Google thought well, I mean, this is nice and all But really we could provide the developers with a little bit more power What happens when you when you just add there's the websites to the home screen? So since Chrome

39 I think or 40 and They have this manifest thing which allows you to define how your application should behave when it's added to the home screen Take a look at what that looks like. So this is our HTML file right standard HTML fire really short

This is the line. I want to point out you just say link relation equals manifest and then specify an href to a JSON file and That JSON file again is entirely in our control what happens in there we can choose on our own Now as you can see it's link relation manifest so the name sort of is manifest

I have no idea why because it's really hard to Google because many cool I want to add a manifest to my website everything you get is app cache, which is not what you want You don't want app cache, right? You want it's I think it's called web app manifest. Anyhow, the JSON file looks like this We specify a name Which is just what's gonna be showing the home screen. We specify an array of icons, which might seem a bit weird

But you got to think of how many different phones there are and how many different screen resolutions and densities there are and So you can provide multiple icons for different use cases, right? You can provide a really big icon for like, I don't know iPhone 6s pluses iPhones what I'm talking about Samsung Galaxy S7s or something really big phones

But you can provide really low key small icons That might be might have less detail in their icons for really low powered sort of cheap Android phones Which is why an array I don't particularly care about it for this demo, but you could add more icons to this Start URL, we're just gonna set index of HTML

The display is probably the most interesting Property in this entire JSON file. This display property supports four different values, right? You can say full screen standalone minimal UI or browser Browsers to default behavior If you don't have a manifest file specified and users add your website to their home screen

What happens is when they click on it, it just opens the link in the browser Right, nothing special. It's kind of like a bookmark if you say minimal UI in this display property What happens is that it doesn't it no longer opens in the browser It's of this place at minimal UI as the name suggests of the browser above your application. It's like a separate application

So you can go back It's actually something if you use a manifest file Be really careful about the user experience of your of your users Because what many applications do is they add this and then choose standalone which hides the browser bar completely as you'll see very soon So it sort of looks like a native application But then they don't have a back button inside the application and so users click on the link

Right and never go back because they just can't they're just stuck now So if you add a manifest file, be sure to check out how it actually works Don't just add it and blindly think it is gonna work because you just are going to have some problems if you just choose standalone Standalone as I said is sort of or hides any browser thing. It just shows the top bar with

Like the Wi-Fi information at the time and I like that just a phone top bar and if you have any hardware keys You chose them too and full screen Obviously doesn't show them anymore. So it's literally just your website on there and Then you can set an orientation to portray the landscape if you have like some sort of game You might want to set that to landscape. What does this actually look like?

So we can now go to Chrome we open the page and Then we click on add to home screen and the thing we see here is immediately it has the proper NDC Oslo logo and it also has the proper title that we specified We then click on add and go back to our home screen The icon is going to be surprisingly on our home screen

But when we now click on it, what we're going to see is a really nice splash screen As soon as I do actually click on it and then boom there's your website and The thing is even in your operating system task switcher. It's not like another tab in your browser It's literally behaves like a native application All right

If we combine this now with the offline behavior This is what we get we go into airplane mode and the users previously visited your site and added it to the home screen and you can prompt them to do that and They can open it and interact with it and use your application exactly how they normally would a native application and there's absolutely no difference

Anymore, right? We're completely offline. This is we're in airplane mode. There's no connection here and it just works So short takeaways Don't use app cache or if you do use it very responsibly and know about the pitfalls use service workers because they are freaking awesome and combine it with a web application manifest or whatever the real name is and

Make your web application work like a native application Thank you so much for having me Oslo. I don't think I've ever gone through this talk so fast

So if you have any questions, just stream at me and I'll repeat them for the listeners. Yes over there Yes, the cache API is very specific to service workers same as the install events and it's just something you can only use in service

Workers So the question was kind of service worker work asynchronously and it's the same as every web worker Yes, you can it's just it's like a background thread sort of in a certain way So you can do really whatever you want in there asynchronously

The cache API is actually asynchronous the thing about the service workers is and why did why they aren't very widely supported Yeah, is that you use promises all their API's use promises which not many browser support yet That's why that's the main hold back for the for the browsers implement them because they need to implement promises first and fetch as well

Other questions, there's a hand over there There are file size limitations and they're different per browser, but they're the same as index DB. I think so It's like 50 megabytes on Chrome Come remember the specifics now But in that region there there are files for files as limitations and you can look them up because obviously you don't want to

Like you don't want to use this to have suddenly no space on their phone just because some random website just downloaded gigabytes of Other questions. Yes in other hands How do you invalidate the cache was the question? Well, that's entirely up to you. Now. It's no longer the browser's problem nice yours

As you know, there is two hard problems in computer science right invalidating caches naming things and off by one errors Invalidating caches isn't very easy There are a bunch of Good ideas on this on the service worker cookbook site They have the you can do all sorts of stuff You can hash your files. You can you know, you can have a file with a list of files

Just like the app cache manifest. It really depends on what how your application behaves and how you want to update it Which is in one way It's good because that means every application can do exactly what it needs On the other hand is bad because now we need to do it. But you know, everything is up and down sides Any other questions

Don't see any hands. Thanks. Have a great day