updated on

State of PWA with Parcel, February 2019

Introduction

In the mid 2018 I have played with Parcel to build a VueJs Progressive Web Application (PWA).
Back then it was kind of quirky to do so.
Reworking on it, I can tell how it compares with Webpack and how Parcel improve its PWA experience.

Reminders

If you’re already familiar with the title, you can skip this part 🥳.

Progressive Web Application (PWA)

To be very very short a PWA is a website that use a certain set of web technologies in order to be used like a regular iOS/Android application.

To dig a little more into it:

  • it’s not restricted to mobile device
  • it’s not restricted to any framework, it just needs to use web technologies
  • it allows offline support
  • it allows notifications
  • and many other things…

It needs:

  • that you’re hosting your website in HTTPS
  • a browser that supports the Service Worker API
  • a webmanifest file: a JSON file that provides information about your web-application
  • a service worker: a JavaScript file that uses the SW API to do stuff (yeah “stuff”, coz you can do many many things)

You can write the latter in your preferred text editor, but…

…workbox

is a tool developed & maintained by Google to help you write the service worker file.

Even if you can come up with your own SW file, I personally prefer to use tools that streamline my process and prevents me for doing silly errors.

If you haven’t yet, try it. Documentation is good and the tool is easy to use.
And mostly: Workbox really helps.

Parcel 1.11.0

It’s the Blazing fast, zero configuration web application bundler.
It helps people to compile things in web technologies (HTML, CSS & JS)

It means to be a simpler alternative to webpack (that has the same purpose, and whose main critic is to be hard to configure).

You can check this post about Parcel if you want more information. (Yeah, self promotion 😎)

How was it with Parcel in the mid-2018

The main principle of Parcel is that it will parse your application entry point, follow any file path within it, and compile/optimize/hash them.
It can be almost anything (see the asset types in the doc!), so HTML, CSS, JS, images, JSON… ANYTHING!

So this is good & fine, but it can be a problems as Parcel tends to be too greedy (being too greedy is bad).

To have a PWA we need to (in order):

1._ have some application icons
_2._ have a manifest.webmanifest file
_3.
build our HTML/JS/CSS/assets
• our HTML should reference the manifest with a <link rel="manifest" href="/manifest.webmanifest">
• our future service worker should be called in our JS file

1
2
3
4
5
if (`serviceWorker` in navigator) {
window.addEventListener(`load`, () => {
navigator.serviceWorker.register(`/my-application-service-worker.js`)
})
}

4._ build our service worker with Workbox that will cache any of the assets needed for the application
_5.
…and that’s it 🎉

But at this time Parcel would have:

  • followed our manifest link and converted it to a js file 😨
  • followed our service worker’s registration and breaks because it doesn’t exist yet 😰
  • and so 😱

In order to avoid that you would have to:

  • avoid your HTML file as an entry point (so compile only the JS/CSS)
  • come with another simplified HTML file to use the Parcel dev server
  • generate the service worker with workbox-build
  • create a different production HTML that:
    • reference the manifest file
    • have a script tag that install our service worker (this way it won’t be parsed by Parcel)

manifest.webmanifest

with webpack

In the Webpack lore it exists the webpack-pwa-manifest plugin which will take care of:

  • creating icons
  • creating the manifest file
  • injecting it into the HTML
  • take care of old proprietary tags in iOS if needed

and this is AWESOOOOME.

with Parcel

It now supports NOT to parse/modify your manifest file, which was a real bummer in previous versions.

Coming up with your own manifest file is not a problem per se. It’s just a small JSON file that won’t change a lot over time.
As for the icons, I’ve found the node-image-resizer that will help you generate the different app icons sizes. And because it uses jimp under the hood, you won’t be bothered to install any external dependencies (like GraphicMagic).

So event if it’s less “plug and play” than using webpack, it’s now way better than not using your HTML file as an entry point (mostly for the dev server).
I would like to see a webpack-pwa-manifest alternatives but coming with my own will stay on my list of open source project to do that I know I won’t find the time to make but it could be helpful to build 😔

service worker

with webpack

Google develops & maintain the workbox-webpack-plugin that lets you generate a worker file.

On inject mode it has some nice additions which are:

  • injecting the workbox library for you
  • generating a separate precache manifest file (I find it cleaner to have all those path away from the “real” service worker code)

with Parcel

There is the parcel-plugin-sw-cache which works quite well.
There isn’t the workbox-webpack-plugin nice additions but it dœs the job.
Also, the configuration depends on the package.json so it may be less flexible than a JS’ webpack configuration.

But to prevent the “too greedy“ behavior of Parcel you have to use a small twist to register your service worker without Parcel noticing it:

1
2
3
// this way Parcel won't check `my-application-service-worker.js`
const swName = `/my-application-service-worker.js`
navigator.serviceWorker.register(swName)

Conclusion

Webpack propose a smoother experience due to the more mature ecosystem it has, but working with Parcel to build a PWA is a way smoother experience than it was. Good Game Parcel! 🏆

The main small inconvenience is to generate the different application icons… which isn’t that bad.

You can find the web applications here: