Exploring Service Workers


Kyle Simpson

Kyle Simpson

You Don't Know JS
Exploring Service Workers

Check out a free preview of the full Exploring Service Workers course

The "Introduction" Lesson is part of the full, Exploring Service Workers course featured in this preview video. Here's what you'd learn in this lesson:

Kyle Simpson introduces the course on service workers by sharing a few helpful resources and then describing the problems that can be solved with service workers.


Transcript from the "Introduction" Lesson

>> So that's what we're gonna be focusing on today is service workers and how we write them what they're for. How we write them, how we position them within a website in particular. And I say website on purpose because most of the other materials that are out there that talk about service workers seem to focus on progressive web apps.

I just wanna give a quick note about progressive web apps. That's how I actually first started experiencing them was last summer I decided I wanted to build myself a progressive web app to install on my phone. It's a little app that lets you like take notes when you're at a restaurant and then be reminded when you come back to that restaurant.

And I wanted to build that out for myself and I wanted to do it with web technology. I don't wanna go learn Java or whatever you use on iOS these days, I can't keep up with it. But I didn't want to learn any of that. I just wanted to use the good old web technologies that I knew.

And so I did dive in for the first time to service workers and try to figure out how they work. And I was doing exactly what any of you have done if you have tried, which is just randomly googling around saying somebody tell me what this is. I do wanna point out I've got in the links here.

I found about halfway through that journey that one of my favorite people on the internet Jeremy Keith had written a book called going offline. This is an absolutely fantastic book. So please go buy that book. It's one of the best resources I found for trying to sift through this stuff.

But there's still just lots and lots of bits and pieces, incomplete information. There's lots of reference on MDN. There's lots of write ups that Google has done about it. Trying to piece together all of these things is a very manual process, and literally the code that we'll be going through today, was done exactly that way.

I set out with here's what I kind of want to build and I know the pieces but I'm gonna have to fiddle with it and I spent a lot of time fiddling with it. And trying it and trying it over and over and over again. So I certainly, am not at the place where I can just write this stuff perfectly from scratch.

I don't think that's even reasonable to do. A couple of things to point out there are in here a couple of resources that you should know about, in particular, this one on workbox. That is a framework for writing service workers. So it's like a library framework thing that you load into your service worker.

It has variety of API's for declaratively setting stuff up. I think it's a great idea to have something like this because quite frankly, many of you are probably gonna get pretty intimidated pretty quick. When you see just how much code we're gonna be writting. I'm actually excited by being able to write my own code in a service worker.

So I went the opposite direction. Instead of using a framework or library, I really wanted to have all of that fine grained control. And with that control comes an understanding of things. And I really wanted to understand what was possible what I could do. And there's a lot of things that are possible that don't even get talked about and will kind of cover those various things as we go along.

But, I certainly understand that, if you are trying to get something shipped at work, you don't have a lot of time, to just, greenfield explore. And, that would be a really great starting point to get a service worker up and going, that'd be a really great starting point for him.

So back to what I was saying a moment ago about the idea of sites versus applications. Everybody seems to think about it in terms of apps. That's where I started learning and building was with apps. But I'm gonna talk to you today about using service workers with everything.

That's not a web application. Because I think one of the things that we have missed on the web, and by missed I mean, I think we didn't realize how important this was a long long time ago. If we'd realized a long long time ago how important this problem is, I think we would have had something like service workers a decade or two ago.

And I'm not even sure whether the technology platform was mature enough for that. But it would have been a problem that we had been trying to solve a lot earlier. And it feels relatively not that solved. And so when you hear people talk about service workers, they immediately think, well, I'm not building an app, so I don't need that.

And the claim that I'm going to make and I'm hoping to enable at least from a creative thinking perspective. All of you that are watching this to do is I'm gonna make the claim that literally every single website on the internet needs a service worker. Every single website, I mean, the static one pager that somebody wrote 20 years ago.

And I mean the fancy gmails of the world and I mean everything in between. I think they all need a service worker. And I think that as we are moving into this age of taking advantage of the web platform we get focused on the shiny stuff like I got CSS Grid, or I got this.

And now I have these like progressive retina images and I've got all these crazy web fonts. And I've got SVG and I've got animations we get focused and rightly so those are fun and exciting things. We get focused on the shiny stuff, but I think we forget some of the most important base plumbing fundamentals of the web.

And I think the web got it wrong web and by web, I mean broadly, the browser technology, I think we got something wrong. And service workers at least the way that I've positioned them in my mind, they go to trying to fix that. The thing that I'm talking about is that we have always had some notion of information being cached in our browsers.

And we often think of well, because I have it cached. It means I don't have to reload it the next time I go to the website. That's unfortunately not really the case. If you were to dig into the source code of a browser and look at all of the different paths that it goes through, to decide when it sees a request.

Whether or not to try to load it from cache to even look in the cache or load it from cache versus getting it from a server or what it does. You'd probably be blown away at just how complex that is. It's not a binary decision, like it's in the cache, I use it or it's not in the cache, and I don't.

And I think that's one of the problems that we have is that we've so simplistically cemented in our mind. Something so uninteresting, is caching, that we just think, the browser takes care of that for me. In our interest this morning, many of you talked about being all over the world and all these different places I travel for work.

I'm all over the place and just a few days I'll be in Lithuania. And then I'll be in other parts of Broad. And that means I spend most of my time not on my home Wi-Fi or in my nice United States of America. High-speed Wi-Fi connection sort of stuff I use T-Mobile is my mobile provider.

And that means that I get free internet everywhere I go. But it's at 2G speeds so that's the downside of it. And I can pay like $50 a month to upgrade it to 4G but I'm cheap like that I don't normally do that unless I'm going to be somewhere for a long time.

Few weeks in Australia yeah, I'm gonna pay to upgrade but if it's a few days I just suffer through the 2G experiences of the web. And so maybe more than most I get to see firsthand what it's like when we build not only slow experiences but basically broken experiences for people.

We get so myopically focused on well my boss and my sales and marketing departments tell me that all of our customers have high speed internet. And they access us at home on a desktop computer with a high end monitor and stuff like that we get so focused on that's where our customer is that we forget, the fact that customers are mobile.

This is one of the things I think that we've missed. We forget the fact that I can be your customer here in the United States of America and I can load up your website. And I can be thinking I want to buy something from you or pay for a service.

And then in the middle of that decision get on a plane and fly to Lithuania or some other bizarre, far off exotic place, whatever. And I get off the plane and I connect to my 2g speeds and I'm still your customer and I still wanna experience the web exactly like I did before.

And guess what? I'm willing to tolerate the idea. I know that it's not gonna be as perfect as it was back home. But there's a difference between I'm willing to tolerate a degraded experience and I'm willing to just essentially assume I get nothing. I literally get nothing because nothing will love.

For example, many times I'll be sitting in an airport board waiting to get on the plane. I'll see a tweet that comes by with a blog post and it looks interesting. So I click on the blog post, I start reading the first few paragraphs and then they board us on the plane.

So I go, put the phone in my pocket, I get on the plane. I'm in the middle of that blog post. I'm still reading it. I wanna see what that blog post has to say. I go get on the plane, we turn our phones into airplane mode. 30,000 feet in the air, there's no Wi Fi on this stupid plane, and I open up your blog page and I get a blank white failed to loads screen.

Why is it that I had that content before I took off and I didn't do anything because I got navigated around and went to a whole different website. It's still an open tab in my mobile browser, but I get on the plane and it's gone. And there's actually 1000 different reasons why that might have happened.

The website might have had dynamic resources in the background that tried to make a request and that might have been why it happened. It's actually probably an ad that messed it up, that did that to my site. Whatever the reason is, now I don't have your blog post and for the next three hours, I can't read the thing that I wanted to read.

I think that's what we've missed about the web is that we've made these terrible assumptions that people are gonna experience the web in a contiguous way. That when you sit down to experience something about the web, you're not gonna be interrupted. You're gonna have perfect Wi Fi perfect internet connectivity, perfect battery power.

You're never gonna have any sort of interruption to that. That's the way that we design the web. And the reality is that that's not the way the web is experienced, by the vast majority of the human population. It's a very, vanishingly small amount of us that get to have the privilege of experiencing this continuous perfect web all the time.

And it's such a first world privilege problem when we're like, my god, GitHub took four seconds to load. What are they doing right like but that's a reality for a lot more of the world than I think we understand.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now