Progressive Web Apps     

If you’d like to build a PWA, then use Quasar CLI to generate the boilerplate from the Quasar PWA Starter Kit:

# create starter boilerplate folder;
# "pwa" is the name of the starter kit
$ quasar init pwa <folder_name>

$ cd <folder_name>

# npm install deps
$ npm install

Important!
Do not use Quasar wrappers (Cordova/Electron) on top of this template.

Please note that this is a Quasar starter kit and not a wrapper, it creates a new Quasar-app folder for you. In case you want to use your previously written Quasar-app code, you will have to manually migrate your code from the src folder. Also note, after doing so you will not be able to wrap your app with Cordova or Electron anymore.

What’s Included

Please note that the lighthouse audit score of your PWA should be performed on the built version of your app, not on the dev server. This means that you should quasar build and quasar serve on the root folder of your app, then open the served url inside Google Chrome and perform the lighthouse audit.

Lighthouse audits can be done from the ‘audit’ tab in your chrome dev tools. In case there is no ‘audit’ tab you can install lighthouse as a chrome extention.

What is a Progressive Web App?

A Progressive Web App, from the developers documentation on Google, can be defined as:

Down below are some of the few key concepts you need to understand when working with the PWA starter kit:

Basic understanding of PWA concepts

What is the app manifest?

The web app manifest is a simple JSON file that gives you, the developer, the ability to control how your app appears to the user in the areas that they would expect to see apps (for example the mobile home screen), direct what the user can launch and more importantly how they can launch it.

Using the web app manifest, your web app can:

What is the app shell?

The app’s shell is the minimal HTML, CSS, and JavaScript that is required to power the user interface of a progressive web app and is one of the components that ensures reliably good performance. Its first load should be extremely quick and immediately cached. “Cached” means that the shell files are loaded once over the network and then saved to the local device. Every subsequent time that the user opens the app, the shell files are loaded from the local device’s cache, which results in blazing-fast startup times.

App shell architecture separates the core application infrastructure and UI from the data. All of the UI and infrastructure is cached locally using a service worker so that on subsequent loads, the Progressive Web App only needs to retrieve the necessary data, instead of having to load everything.

What is a service worker?

A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don’t need a web page or user interaction. Today, they already include features like push notifications and background sync. In the future, service workers will support other things like periodic sync or geofencing. The core feature discussed in this tutorial is the ability to intercept and handle network requests, including programmatically managing a cache of responses.

The reason this is such an exciting API is that it allows you to support offline experiences, giving developers complete control over the experience.

More on service workers can be read here at the developers documentation on Google.

Working with the Quasar PWA starter kit

The app manifest

You can find the app manifest in the PWA starter kit at /src/statics/manifest.json. Please personalise this file to your app.

The service worker setup

The PWA starter kit works with 2 plugins to create a basic service worker that will cache your app shell automatically. If you look at your webpack setup at build/webpack.prod.conf.js, you will see that it uses the ‘sw-precache-webpack-plugin’ and the ‘html-webpack-plugin’.

The ‘sw-precache-webpack-plugin’ is the plugin that “generates” a service worker file automatically and saves it in dist/service-worker.js. This file can be modified through the arguments passed at new SWPrecacheWebpackPlugin(). e.g. setting minify: true to false will make it so the dist/service-worker.js is not minified.

More documentation for changing your service-worker.js file’s setup can be found on the sw-precache-webpack-plugin github page.
And for an even better understanding, also look at the original sw-precache github page, as sw-precache-webpack-plugin is only a webpack-wrapper for this.

The ‘html-webpack-plugin’ only creates a short

Dev vs Production Code Cordova Wrapper
Last updated: Tue Feb 20 2018
Caught a mistake or want to contribute to the documentation? Suggest an edit on GitHub