WorkboxJs produces Service Workers for you. Also through Webpack.

Alessio Occhipinti
codeburst
Published in
4 min readOct 25, 2017

--

Progressive Web Apps are surely the future of the web, and maybe not only the web. This is possible because new technologies are landed on modern web browsers, like Service Workers.

We can use Service Workers to build the offline experience for our end users both, of course, on desktop and mobile, just using native browser APIs. This is (read: could be) the killing native-apps era.

You can of course write your Service Worker for your application entirely from scratch (and just do this, because you can better understand what you are actually doing), but this is a tedious work and some folks just solved the problem automating the task, using best practices.

Workbox: JavaScript Libraries for Progressive Web Apps.

I’m talking about WorkboxJs. Here is an overview from the home of their website:

Workbox is a collection of libraries and build tools that make it easy to store your website’s files locally, on your users’ devices.

Consider Workbox if you want to:
- Make your site work offline.
- Improve load performance on repeat-visits. Even if you don’t want to go fully-offline, you can use Workbox to store and serve common files locally, rather than from the network.

And this is actually exactly what Service Workers do, behind the scene, so Workbox is just a tool to produce native code for you.

You can start using Workbox today, using npm scripts to run the workbox-cli, you can use gulp to run the workbox-build module, but of course you can also run it as a Webpack plugin: workbox-webpack-plugin.

Webpack + Workbox: make the world happier.

Now let’s setup our offline-first application with Webpack and Workbox.
First grab a new folder on your system and yarn inititialize the project.
Then add as dev dependencies using yarn add --dev (or npm of course, as you wish):

  • webpack
  • workbox-webpack-plugin
  • copy-webpack-plugin (to copy static files to a new dist directory for the build)

Create a folder named src and first of all create a simple index.html inside it:

Now we can create the main entry point for Webpack. Within the src folder create an index.js where to put a dead simple logic just to show some changes on the page:

Time to create the webpack configuration. So, within the root of the project create the webpack.config.js:

As you can see we are caching everything using that glob reference within the globPatterns Workbox configuration option.
NOTE: Under the hood the workbox-webpack-plugin is talking with the workbox-build NPM module, you can learn more about the options reading the documentation.

NPM scripts

Setup two NPM scripts for build and serve our application, but before that add another dev dependency: http-server. We will use it to serve our built application after running webpack.

Add a start script within the package.json:

"start": "http-server dist"

And a build script:

"build": "rm -rf dist && webpack"

Build and run

Now we can simply run our build script to build the bundle with Webpack, copy the index.html, and generate all the needed files for our Service Workers through Workbox.

Run:

yarn build && yarn start

And now time to see our application running on http://localhost:8080.

Debug Service Workers

Fortunately, folks at Google are really cared about debugging Service Workers and with the last Chrome improvements they added the awesome “Application” tab within the Chrome Dev Tools that allows us to easily debug and delete all the data that a web page is caching. And this is awesome.

Open the dev tools and switch to the Application tab. Now on the left side bar click on “Service Workers” and you should see something like this:

Et voilà! Service Workers up and running, ready to go offline with you. 🚀
You can play with the dev tools and the “Clear storage” tab (on the side), it’s features are really useful when you need to debug your Workers really deep, because you want to have the control on what you are seeing on the screen, live code, or cached code.

To test easily that you are actually enabled your application to work offline just switch toggle that “Offline” checkbox just over your localhost address, reload the page and:

This is a very small intro to Workbox and Service Workers, but there are a lot of things you can do with them to enhance the experience of your user and be competitive with native implementations.

I have group up the code in a sample repo if you want to check out the entire code: medium-webpack-workbox.

Always feedback and comments appreciated 👍

--

--