You hail a taxi, get in the car, they take you to your destination, you might make small talk along the way, you get going and you pay. That's a bit like visiting a webpage.
You hail a taxi, they give you their card about the limo service they provide, which also does pickup and delivery of your dry cleaning. You're intrigued about the possibility of getting texts about the status of your ride and other things like that. That's a service worker. You and the driver are going to exchange info so the relationship can become more than just the single ride.
Service workers give you access to secondary browser APIs which allow you to do things like storing an offline page, caching pages for offline browsing, and the ability to send push notifications to the user, and basically do things outside the typical lifecycle of a webpage visit. This is a browser behavior, but it sort of seems like a system-level behavior, because it sort of is. The line is blurred with the increased power of the browser.
One thing that is a bit confusing is that right now service workers do a handful of neat tricks, but service workers will find new use cases in their existing functionality and in future features that are implemented to go along with the current set of features. That's why it's not just referred to as "a slightly different caching api and ability to send push notifications", it's going to become more powerful through discovery and growth, just as the browser has.
You might also be thinking of the above example and be thinking "In a way, you're describing Uber or Lyft already", and that sort of makes sense. The things that service workers can do are sort of an effort to bring the power of native APIs to the web. The benefits of the web are great, but it sometimes loses out to native for reasons it doesn't need to. Service workers close some of those gaps. You still don't get all the native APIs, but who knows what the future holds?
In practice, service workers let you load a JavaScript file that configures what it can do. It's just code like any other JavaScript file, but instead of giving you access to things like document and window and events like onclick, you gets like install, activate to listen to and then go to work with.
If you're interested in adding basic service worker functionality to a project, I'd start with following the instructions, pasting some of the boilerplate in, and working simply with creating an "offline" page. I think that's the base case, and that's how I started.
You hail a taxi, get in the car, they take you to your destination, you might make small talk along the way, you get going and you pay. That's a bit like visiting a webpage.
You hail a taxi, they give you their card about the limo service they provide, which also does pickup and delivery of your dry cleaning. You're intrigued about the possibility of getting texts about the status of your ride and other things like that. That's a service worker. You and the driver are going to exchange info so the relationship can become more than just the single ride.
Service workers give you access to secondary browser APIs which allow you to do things like storing an offline page, caching pages for offline browsing, and the ability to send push notifications to the user, and basically do things outside the typical lifecycle of a webpage visit. This is a browser behavior, but it sort of seems like a system-level behavior, because it sort of is. The line is blurred with the increased power of the browser.
One thing that is a bit confusing is that right now service workers do a handful of neat tricks, but service workers will find new use cases in their existing functionality and in future features that are implemented to go along with the current set of features. That's why it's not just referred to as "a slightly different caching api and ability to send push notifications", it's going to become more powerful through discovery and growth, just as the browser has.
You might also be thinking of the above example and be thinking "In a way, you're describing Uber or Lyft already", and that sort of makes sense. The things that service workers can do are sort of an effort to bring the power of native APIs to the web. The benefits of the web are great, but it sometimes loses out to native for reasons it doesn't need to. Service workers close some of those gaps. You still don't get all the native APIs, but who knows what the future holds?
In practice, service workers let you load a JavaScript file that configures what it can do. It's just code like any other JavaScript file, but instead of giving you access to things like
documentandwindowand events likeonclick, you gets likeinstall,activateto listen to and then go to work with.If you're interested in adding basic service worker functionality to a project, I'd start with following the instructions, pasting some of the boilerplate in, and working simply with creating an "offline" page. I think that's the base case, and that's how I started.
Great explanation! Thanks for this 🙌🏾
Fwiw I love the offline page dev.to returns.
🙃
Thanks. Best explanation I've gotten btw I think dev.to offline page is the best 😄