First, we’ll turn your website into a Progressive Web App (PWA). Then we'll use a free command-line tool from Google called Bubblewrap to package that PWA into an Android app. Let’s get started.

Prerequisites

If you follow along with this tutorial, there are some prerequisites:

• Basic knowledge of web development

• Your site should be live to the public, and you’ll need to have access to its source code.

• We'll use npm to install the necessary tools, so make sure you have Node.js installed.

Note: This tutorial is based on a Vite project, but the final steps with Bubblewrap are the same for any web framework.

Table of Contents

1. What is a PWA?

2. What is Bubblewrap?

   • What is a TWA (Trusted Web Activity)?

   • How TWA Verifies Trust

3. Step 1 – Configure Your PWA in Vite

   • Create Your App Icons

   • Install the Vite PWA plugin.

   • Configure the Plugin

4. Step 2 – Create the Android App

   • Create a Build Folder

   • Install the Bubblewrap CLI

   • Initialize the Project

   • Let’s troubleshoot the init command.

5. Step 3 – Answer Bubblewrap Questions

6. Step 4 – Build the App

7. Step 5 – Setting Up TWA Validation

   • What is the .well-known folder?

   • What is delegate_permission/common.handle_all_urls?

8. Step 6 (Optional) – Customize the In-App Experience

9. Wrapping Up

What is a PWA?

PWA stands for Progressive Web Application, and its goal is to make your website look and feel just like a native app. If you’ve visited a website in your browser and seen an install icon that lets you download it to your phone or laptop, you've used a PWA.

But it’s not just about the look and feel. A PWA also has app-like features, such as working offline, sending push notifications, and more.

There are two main components of a PWA.

• The manifest file describes your app, such as its name, icons, start URL, and so on.

• A service worker is a background JavaScript file that acts as a proxy. The caching and push notifications are handled by a service file, which runs as a different thread apart from the main thread.

Without these two components, browsers won’t let users download the app locally.

The manifest file and the service worker are like a checklist for the browser. When you visit a website, the browser looks for both of these components. If they are present and correctly configured, the browser knows it's a true PWA and will show the "install" icon, allowing users to download the app locally. Without them, the browser just sees a regular website, and the option to install won't be available.

What is Bubblewrap?

Bubblewrap is a command-line tool made by Google that takes your PWA and turns it into an Android App using a Trusted Web Activity (TWA).

Bubblewrap simplifies the process of creating a TWA, turning a PWA's manifest file into an Android app package (APK or AAB).

What is a TWA (Trusted Web Activity)?

A Trusted Web Activity (TWA) is a modern Android feature that lets you display your live website full-screen inside an Android app. Basically, it runs the website on the browser, but it doesn’t show the browser address bar on the App. This helps it feel like a native app.

To unlock this full-screen feature, your app needs to be “Trusted“.

This is where the "secret handshake" comes in. Android needs to be sure that the person who built the app and the person who owns the website are the same. Without this proof of ownership, the TWA will run in a fallback mode and show the browser address bar at the top, ruining the native app feel.

How TWA Verifies Trust

This trust is verified using a system called Digital Asset Links. You place a special file on your website (we'll do this in the implementation part) that contains your app's unique digital fingerprint. When a user opens your app, the Android OS checks this file. If the fingerprints match, it grants your app "trusted" status, removes the address bar, and enables other features like deep linking.

You can check this relationship yourself using Google's official testing tool: Digital Asset Links Verifier.

Now that you understand the project and tools, let’s start building.

Step 1 – Configure Your PWA in Vite

The first step is to add the two main components for a PWA: the manifest file and service worker. This is what will allow the browser to recognize it as "installable."

This guide is based on a project built with Vite, which makes this process easy with a special plugin. If you're using a different tool, the concepts are the same, but you'll need to look up different resources about the specific steps for your environment.

Create Your App Icons

Before we touch any code, we need the icons for our app. Android requires specific sizes for the app's launcher icon (what you see on your home screen) and the splash screen (what you see when the app starts).

You'll need two main sizes: 192x192 pixels and 512x512 pixels. You can use this Favicon Generator to generate your logo in the respective sizes. You can upload your main logo, and it will generate all the necessary sizes for you.

Then just download the generated files and place the 192x192 and 512x512 files into the public folder of your project.

Install the Vite PWA plugin.

A PWA requires a manifest file and a service worker. We can create these manually, but this plugin automates that entire process. It will automatically generate a manifest.json and service-worker.js for you every time you build your project.

npm install vite-plugin-pwa -D

Configure the Plugin

In this step, we’ll use this plugin and configure our app's manifest. Edit the vite.config.ts file. This configuration will tell the plugin what to name your app, which icons to use, and so on.

In vite.config.ts:

export default defineConfig({
  plugins: [
    VitePWA({
      registerType: "autoUpdate",   
      manifest: {
        name: "your app name",
        short_name: "your app short name",
        description: "write any description",
        theme_color: "#0d1117",
        background_color: "#ffffff",
        display: "standalone",
        start_url: "/",
        icons: [
          {
            src: "/web-app-manifest-192x192.png",
            sizes: "192x192",
            type: "image/png",
          },
          {
            src: "/web-app-manifest-512x512.png",
            sizes: "512x512",
            type: "image/png",
          },
        ],
      },
    }),
  ]

Now, when you run npm run build, the plugin will automatically generate the manifest and service worker files for you. With that done, deploy the changes. Now your website is a PWA.

Step 2 – Create the Android App

Now that your website is a PWA, let’s use Bubblewrap to package it into an Android app.

Create a Build Folder

Create a dedicated folder for your Android project files. In your project's root, create a new folder. I'll call mine android.

project/
├── client/
├── server/
└── android/

Now navigate to the new folder that you created.

Install the Bubblewrap CLI

npm install -g @bubblewrap/cli

Initialize the Project

Next, run the init command. Bubblewrap will connect to your live website, read the manifest.webmanifest file that Vite created, and use that information to generate a basic Android project.

bubblewrap init --manifest=https://your-website-domain/manifest.webmanifest

Run the command, replacing your-website-domain with your actual URL:

Let’s troubleshoot the init command

As you run the init command, Bubblewrap will need two key software packages: the Java Development Kit (JDK) and the Android SDK. It will offer to install them for you.

JDK setup:

? Do you want Bubblewrap to install the JDK (recommended)?
  (Enter "No" to use your own JDK 17 installation) (Y/n)

In my case, when I let Bubblewrap install the JDK, the process downloaded the files but then failed at the "decompressing" step. If you face this same problem, don't worry! The fix is to install it manually.

• Say No to the prompt.

• Download the recommended version (usually JDK 17) from a source like Adoptium.

• Install it and set up your system's environment variables to include the JDK's bin path. If you’re not sure how to set environment variables, you can check out this site: Set Environment Variables.

• When Bubblewrap asks for the path, provide it directly, such as C:\java\jdk-17.0.16.8-hotspot.

Android SDK setup:

Once the JDK is set up successfully, the next step is to configure the Android SDK.

? Do you want Bubblewrap to install the Android SDK (recommended)?
  (Enter "No" to use your own Android SDK installation) (Y/n)

Since I didn't have the Android SDK, I let Bubblewrap handle this by selecting Yes. I didn't face any problems here.

If you face any problem in setting up on Android SDK, just set it up manually and give the path, just like the JDK setup.

Step 3 – Answer Bubblewrap Questions

After the SDK is set up, Bubblewrap will ask a bunch of questions to configure your app. This information is used to create the twa-manifest.json file, which is the blueprint for your App.

Domain: Press Enter (auto-filled from your manifest)

Application name: Your full app name

Application ID: (e.g, chat.yourapp.twa)

Display mode: standalone

Orientation: portrait

Status bar color: Press Enter (accepts default)

Splash screen color: Press Enter (accepts default)

Icon URL: Press Enter (accepts default)

Include support for Play Billing?: Type Y if your app uses Google Play in-app purchases. Otherwise, N

Request geolocation permission?: Type Y if your app needs location access. Otherwise, N

In these questions, the important part is the key store and the key.

First and Last names: Your full name

Organizational Unit: Developer or anything

Organization: Your organization name

Country (2-letter code): Your country code

Password for key store: Enter a new password

Password for key: Re-enter the same password

Note: These passwords for both the key store and key should be the same, or else it will throw an error. Refer to this issue: Bubblewrap Issue.

Step 4 – Build the App

bubblewrap build --universalApk

This command starts building your application. Here, the flag universalApk will produce the .apk and .abb. If you’re going to publish your application in the Play Store, upload the .abb file to the Play Store. For our testing, we need an APK file, so this flag universalApk will produce both files. If we didn't give this flag, it would only give us .abb.

Step 5 – Setting Up TWA Validation

Once the build is done, you’ll get the APK. Transfer it to your phone and test it. When you open the app, you’ll see the browser address bar. This is because we haven't set up the "trust" between your app and your website yet. Let's fix that now.

In your frontend project, go to the public folder, create a new folder called .well-known, and inside that, create a file called assetlinks.json.

frontend/
├── public/
    ├── .well-known/
        └── assetlinks.json

What is the .well-known folder?

A well-known folder is used to store files that define configurations for protocols, as it’s used for external sources to find the validation for your website. In our case, our app checks the well-known folder from our website and verifies the validation.

Paste the following into assetlinks.json:

[
  {
    "relation": ["delegate_permission/common.handle_all_urls"],
    "target": {
      "namespace": "android_app",
      "package_name": "chat.yourapp.twa",
      "sha256_cert_fingerprints": [
       "your_sha256_fingerprint"
      ]
    }
  }
]

What is delegate_permission/common.handle_all_urls?

This is a special flag that opens all the links from the app instead of the domain. Simply put, it acts as a deeplink. After you install the app, if you click your website link from WhatsApp or from somewhere, it will open your app instead of opening in a browser, acting as a deeplink.

The package_name field should be the packageId, which you can get from your Android build folder in twa-manifest.json.

Now, get your fingerprints. Run the following command to do so:

keytool -list -v -keystore android.keystore -alias android

The alias name should be the value that you created. Once you enter this command, it’ll ask for the key store password. Enter that, and you’ll get your SHA256 fingerprint. Copy that and paste it into the assetslinks.json file in the sha256_cert_fingerprints array. Now push these changes to production. You can verify the validation in Digital Asset Links

That’s it! Now you can install the app and test it.

Step 6 (Optional) – Customize the In-App Experience

Now, additionally, there will be some cases where we want to show different content to users on the website vs the mobile app. Can we do that? Yes!

In your Android build folder, in twa-manifest.json, there will be a field called startUrl. If not, add it and add the value "startUrl": "/?twa=true". The startUrl is the entry point. I have a query parameter of value twa=true.

Run the build again with bubblewrap build --universalApk.

Now, if you open your app, it will open the app with the entry URL as yourwebsitedomain.com/?twa=true.

In your frontend:

const twaParam = queryParams.get("twa");

const [isTwa, setIsTwa] = useState<boolean>(() => {
   return localStorage.getItem("isTwa") === "true";
});

useEffect(() => {
  if (twaParam === "true") {
    localStorage.setItem("isTwa", "true"); // set the value to local storage
    setIsTwa(true);
  }
}, [twaParam]);

 {isTwa? (
    <Link to="/contact" className="underline hover:text-primary">
       Contact
    </Link> 
  ) : (
     <Link to="/download" className="underline hover:text-primary">
       Download App
      </Link>
  )}

In the code above, we check for the twa=true query parameter in the URL. If it's present, we save that information to local storage, and then we conditionally render the content for the user.

That's it. We have created an App.

If you want to change any name, colour, or splash screen, you can change it in twa-manifest.json and run the build again.

Wrapping Up

Bubblewrap is only for Android. If you want the app to support cross-platform, there are some other platforms, like Capacitor, which I’ll write about in another article.

By the way, you can check out the App that I made using Bubblewrap here: Stranger Talk.

If there are any mistakes or you have any questions, contact me on LinkedIn or Instagram.

Thank you for reading!

PWAs bring the power of the web to your fingertips with the experience of a mobile app. Even better? If you lose internet connection while on the go, the app can still function, showing your previously loaded data and getting updates once you’re back online.

In this tutorial, you’ll learn how to implement a service worker with WorkBox in a weather app using HTML, CSS, and JavaScript. We’ll start by understanding what a PWA is, the core components behind the scenes, especially service workers, and how to use Workbox to supercharge your app with offline capabilities.

Table of Contents

• What We’ll Cover

• What is a Progressive Web App (PWA)?

• What Makes a Web App “Progressive”?

• Components of a PWA

• What is a Service Worker in PWA?

• Why Use Workbox Instead of Manual Service Workers?

• Introduction to WorkBox

• Project Setup

• Creating the Offline HTML Structure

• Styling with CSS

• How to Set Up app.js and config.js

• How to Create a Manifest File

• How to Add WorkBox to Your service-worker.js File

• How to Create your Service Worker in the service-worker.js File

• How to Set Up App Installation

• How to Install the Weather App

• Conclusion

What We’ll Cover

• Setting Up the Project: We'll build a simple weather app using HTML, CSS, and JavaScript. This approach is perfect for this tutorial because it keeps things simple and accessible while focusing on core PWA concepts without the added complexity of frameworks like React or Vue.

• Turning the App into a PWA: Next, we’ll walk through the concept of a Progressive Web App, covering the key features and best practices of PWAs.

• Implementing Service Worker via WorkBox: Finally, we’ll dive deeper into how service workers function and explore why using Workbox simplifies the process.

Here’s what the final application will look like:

Audience

This tutorial is for web developers of all levels. Whether you're new to Progressive Web Apps (PWAs) or just starting to explore service workers, this guide will walk you through the core concepts and demonstrate why using a Google-backed library like Workbox to implement service workers can be more efficient than manual implementation.

Prerequisites

Before you begin

1. Get a free API key from the OpenWeatherAPI website

2. Make sure you’re familiar with HTML, CSS, and JavaScript.

3. If you’re new to PWAs, you might want to read some introductory articles to get a quick overview.

   • Progressive web apps

   • Workbox

What is a Progressive Web App (PWA)?

A PWA is a web application that combines the best of web and mobile apps. It’s built using standard web technologies like HTML, CSS, and JavaScript, but it behaves and feels like a native mobile app on your phone or tablet.

Think of apps like Instagram Web, Twitter Lite, or Spotify Web Player. Even though you’re not using a native app from an app store:

• You can still scroll your feed, view media, and send messages.

• It works even on slow or unstable networks.

• You can “install” it on your home screen and launch it like a regular app.

• You even get push notifications just like a mobile app!

With PWAs, you get the reach of the web and the feel of an app without the heavy storage or installation process.

What Makes a Web App “Progressive”?

A PWA is not just any website. It’s built to progressively enhance the user experience, depending on their device and browser capabilities. Here are the core characteristics that define a PWA:

• Responsive: Works on all screen sizes, that is, phones, tablets, and desktops.

• Reliable: Loads instantly, even when offline or on poor networks.

• Installable: Can be added to the home screen without needing an app store.

• Engaging: Supports features like push notifications and background sync.

Components of a PWA

Before your web app can be considered a PWA, it must include the following:

A Web Application Manifest

The web app manifest is a JSON file that tells the browser about your web app, how it should appear, and behave when installed on a user's device.

Think of it like your app’s business card. It includes details like:

• App name and short name – How your app is labeled on the home screen or app list.

• Icons – Images used for app icons on different screen sizes and resolutions.

• Theme color and background color – Defines the look of your app’s UI and loading screen.

• Start URL – The page that opens when the app is launched.

• Display mode – Controls whether the app opens in a browser tab, fullscreen, or a native-like window.

• Screenshots – Optional preview images that show how your app looks on different devices in app stores or installation prompts.

A Service Worker

This is a script that runs in the background. It handles offline behaviour, caching, background sync, and push notifications needed to make your PWA function.

More details about the service worker will be discussed later in this article.

HTTPS

PWAs must be served over HTTPS. This is not optional. Here’s why:

• It protects users by ensuring secure data transfer.

• It enables important features like service workers and push notifications.

• Browsers won’t allow service workers to register on non-secure origins.

If you're testing locally, you can use localhost (which is treated as secure), But for production, your site must have an SSL certificate.

What is a Service Worker in PWA?

In PWAs, a service worker is a JavaScript file that runs in the background, separate from your main app, and acts like a network proxy. It can:

• Cache resources and serve them offline

• Intercept network requests and apply caching strategies

• Handle background syncs

• Manage push notifications

Think of it as your app’s behind-the-scenes assistant—makes it load fast, works offline, and stays updated, even when you're not looking.

Why Use Workbox Instead of Manual Service Workers?

Service workers are essential in creating a PWA, but getting started with them can be challenging. Writing service worker code from scratch can often be tedious and prone to errors. For example, you'd need to:

• Manually configure caching strategies

• Handle service worker updates

• Write and maintain a lot of repetitive boilerplate code

Workbox, a library from Google, makes things easier by letting developers focus on what matters, without worrying about the complicated parts of service workers.

However, it’s still important to understand how service workers function, since they handle some complex tasks under the hood.

Here are key things a service worker (with or without Workbox) does:

• Install event: Set up cache

• Activate event: Clean up old caches

• Fetch event: Intercept network requests and serve from cache

With Workbox, these are wrapped in easy-to-use functions.

Introduction to WorkBox

Workbox is a collection of libraries that helps developers build efficient service workers quickly, with best practices built right in. It supports strategies like:

• CacheFirst: Load from cache, fall back to network

• NetworkFirst : Try network, fall back to cache

• StaleWhileRevalidate: Serve from cache and update in the background

Understanding Workbox Modules

Workbox is more than just a tool. It is a collection of powerful modules, each designed to simplify different parts of working with service workers. These modules are flexible and can be used in three key contexts:

• Service Worker Context – Inside your service worker file, where you handle caching, routing, and other background tasks.

• Window Context – Inside your main application (the client-side JS), where you register and communicate with the service worker.

• Build Tools Integration – Tools like Webpack use Workbox to generate service worker files and precache manifests during your build process.

Let’s break down some of the most popular and essential modules Workbox offers:

1. workbox-routing

This module handles routing network requests within your service worker. Think of it like a traffic director that listens for fetch events and decides what to do with them.

Use case: Route API requests to the network while routing static asset requests to the cache.

2. workbox-strategies

This is where caching strategies like CacheFirst, NetworkFirst, and StaleWhileRevalidate are used. It provides a clean and consistent API for handling how your app responds to different requests.

Use case: Apply different caching behaviours for images, fonts, or dynamic data with minimal code.

3. workbox-precaching

This module handles precaching by storing static assets during the service worker’s install phase. It makes it easy to cache files ahead of time and ensures that updates are managed efficiently.

Use case: Preload essential assets (like HTML, CSS, and logo images) so your app loads instantly, even offline.

4. workbox-expiration

It is used as a plugin alongside caching strategies. This module adds smart cache expiration. You can automatically remove old or excessive items from the cache based on how long they've been stored or how many items exist.

Use case: Keep your cache size under control without manually tracking and deleting outdated files.

workbox-window

This module is designed for the browser (window) side of your app. It simplifies service worker registration and allows you to communicate with the service worker from your page easily.

Use case: Detect when a new service worker is available and prompt the user to refresh the app to update.

You can use WorkBox via:

• npm

• CDN (which we'll use here for simplicity)

Project Setup

Let's start by creating our project structure:

weather-pwa/
├── index.html
├── style.css
├── js/
│   ├── app.js
│   └── install.js
├── service-worker.js
├── images/
│   └── [your image files and folders here]
├── manifest.json
├── config.js  
└── offline.html

The HTML Structure

First, let's build our index.html file:

<!DOCTYPE html>
<html lang="en">
    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8" />
        <meta name="viewport" content="width=device-width, initial-scale=1.0" />
        <link rel="icon" href="/images/logo.png" type="image/png">
        <meta name="description" content="Simple Weather Progressive Web App" />
        <link rel="stylesheet" href="/styles.css" />
        <title>Weatherly</title>
    </head>


<body>
    <header class="header">
        <img loading="lazy" class="logo" src="images/logo.png" alt="Weatherly Logo">
        <h1>Weatherly</h1>
    </header>

    <main class="main">
        <div class="weather-card">
            <div class="location-container">
                <input type="text" id="location-input" placeholder="Enter city name">
                <button id="search-btn">Search</button>
                <button id="locationBtn">📍 Use My Location</button>
                <button id="installBtn" style="display: none;">Install App</button>
            </div>

            <div id="offline-message" class="offline-message">
                You are currently offline. Weather data may not be up-to-date.
            </div>


            <div class="error">
                <p id="error-message"></p>
            </div>

            <div id="weather-container" class="weather-container">
                <h3>Your last searched location weather:</h3>
                <div class="location-info">
                    <h2 id="city"></h2>
                    <p id="date"></p>
                </div>

                <div class="current-weather">
                    <img loading="lazy" id="weather-icon" src="" alt="Weather icon">
                    <div class="temperature-container">
                        <h3 id="temperature"></h3>
                        <p id="weather-description"></p>
                    </div>
                </div>

                <div class="weather-details">
                    <div class="detail">
                        <img loading="lazy" id="humidity-icon" src="/images/humidity.png" alt="Humidity icon">
                        <span class="label">Humidity</span>
                        <span id="humidity" class="value"></span>
                    </div>
                    <div class="detail">
                        <img loading="lazy" id="wind-icon" src="/images/wind.png" alt="Wind icon">
                        <span class="label">Wind</span>
                        <span id="wind" class="value"></span>
                    </div>
                </div>
            </div>

            <!-- Your location weather -->
            <div class="location-weather">
                <h3>Your location's weather:</h3>
                <div class="weather-info" id="weatherInfo">

                </div>
            </div>
        </div>
    </main>

    <footer>
        <p>Made with ❤️ by <a href="www.linkedin.com/in/damilola-oniyide">Damilola Oniyide</a>
    </footer>
    <script type="module" src="/js/app.js" defer></script>
</body>
</html>

Creating the Offline HTML Structure

The offline.html is the page that users will see when they lose network connection and try to navigate to a page that isn’t cached.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta name="theme-color" content="#2196f3">
  <title>Weatherly - Offline</title>
  <link rel="stylesheet" href="/styles.css">
  <style>
    .offline-icon {
      font-size: 5rem;
      margin-bottom: 1.5rem;
      color: #2196f3;
    }

    .offline-message {
      font-size: 1.5rem;
      margin-bottom: 1.5rem;
    }

    .offline-subtext {
      font-size: 1rem;
      margin-bottom: 2rem;
      color: #666;
    }

    .retry-button {
      padding: 0.75rem 1.5rem;
      background-color: #2196f3;
      color: white;
      border: none;
      border-radius: 12px;
      font-size: 1rem;
      cursor: pointer;
      transition: background-color 0.3s;
    }

    .retry-button:hover {
      background-color: #2980b9;
    }
  </style>
</head>
<body>
  <header>
    <h1>Weatherly</h1>
  </header>

  <main>
    <div class="app-container">
      <div class="weather-card">
        <div class="offline-container">
          <div class="offline-icon">
            <svg xmlns="http://www.w3.org/2000/svg" width="1em" height="1em" fill="currentColor" viewBox="0 0 16 16">
              <path d="M8 15A7 7 0 1 1 8 1a7 7 0 0 1 0 14zm0 1A8 8 0 1 0 8 0a8 8 0 0 0 0 16z"/>
              <path d="M7 6.5C7 7.328 6.552 8 6 8s-1-.672-1-1.5S5.448 5 6 5s1 .672 1 1.5zm-2.715 5.933a.5.5 0 0 1-.183-.683A4.498 4.498 0 0 1 8 9.5a4.5 4.5 0 0 1 3.898 2.25.5.5 0 0 1-.866.5A3.498 3.498 0 0 0 8 10.5a3.498 3.498 0 0 0-3.032 1.75.5.5 0 0 1-.683.183zM10 8c-.552 0-1-.672-1-1.5S9.448 5 10 5s1 .672 1 1.5S10.552 8 10 8z"/>
            </svg>
          </div>
          <h2 class="offline-message">You're offline</h2>
          <p class="offline-subtext">Please check your internet connection and try again.</p>
          <button class="retry-button" onclick="window.location.href='/'">Retry</button>
        </div>
      </div>
    </div>
  </main>

  <footer>
    <p>Made with ❤️ by Damilola Oniyide</p>
  </footer>
</body>
</html>

Styling with CSS

Now, let's create our style.css file for a responsive and user-friendly design:

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

body {
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
    background-color: #f5f5f5;
    color: #333;
    line-height: 1.6;
}

.header {
    background-color: #2196f3;
    color: white;
    padding: 1rem;
    display: flex;
    justify-content: center;
    align-items: center;
    box-shadow: 0 2px 5px rgba(0, 0, 0, 0.1);
}

.header h1 {
    font-size: 1.5rem;
}


.header img {
    width: 55px;
    height: 55px;
    border: #ffff 1px solid;
    margin-right: 4px;
    border-radius: 10%;
}


.main {
    padding: 1rem;
    max-width: auto;
    margin: 0 auto;
}

.weather-card {
    background-color: white;
    border-radius: 8px;
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);
    padding: 1.5rem 3rem;
    margin-top: 1rem;
}

/* Location input styles */
.location-container {
    display: flex;
    margin-bottom: 1.5rem;
    justify-content: center;
}

#location-input {
    flex: 1;
    padding: 0.75rem;
    border: 1px solid #ddd;
    border-radius: 4px 0 0 4px;
    font-size: 1rem;
    max-width: 240px;
}

#location-input:focus {
    outline: none;
    border-color: #2196f3;
}
#location-input::placeholder {
    color: #999;
}   

#search-btn, #locationBtn {
    background-color: #2196f3;
    color: white;
    border: none;
    padding: 0.75rem 1rem;
    border-radius: 0 4px 4px 0;
    cursor: pointer;
    font-size: 1rem;
    margin-right: 2.5px;
}


#installBtn {
    background-color: #2196f3;
    color: white;
    border: none;
    padding: 0.75rem 1rem;
    border-radius: 4px;
    cursor: pointer;
    font-size: 1rem;

}

#search-btn:focus, #locationBtn:focus, #installBtn:focus {
    outline: none;
    box-shadow: 0 0 5px rgba(33, 150, 243, 0.5);
}
#search-btn:hover, #locationBtn:hover, #installBtn:hover {
    background-color: #1976d2;
}

.error, .loading {
    text-align: center;
    font-weight: bold;
    font-size: 14px;
    margin-top: 10px;
    display: none;;
}

.error-message {
    color: #d32f2f;

}
/* Weather display styles */
.weather-container {
    display: none 
}

#weather-icon {
    width: 1000px; 
    height: 100px;
  }

.current-weather{
    margin-bottom: 2rem;
    display: flex;
    justify-content: center;
}

.location-weather{
    margin-top: 2rem;
    display: flex;
    justify-content: center;
    flex-direction: column;
}


#weather-icon {
    width: 80px;
    height: 80px;
    margin-right: 1rem;
}

.location-info {
    margin-bottom: 1rem;
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;
}

.location-info h2,  .current-weather h3, .weather-container h3, .location-weather h3 {
    font-size: 1.8rem;
    margin-bottom: 0.25rem;
}



.location-info p, .current-weather p {
    color: #666;
    font-size: 1.4rem;
}

.temperature-container {
    display: flex;
    flex-direction: column;
    justify-content: center;
    align-items: center;
    margin-bottom: 1rem;
}

.temperature-container h3 {
    font-size: 2.5rem;
    margin-bottom: 0.25rem;
}

.temperature-container p {
    color: #666;
    text-transform: capitalize;
}

.weather-details {
    display: flex;
    justify-content: center;
    background-color: #f9f9f9;
    border-radius: 4px;
    padding: 1rem;
}

#humidity-icon, #wind-icon{
    width: 40px;
    height: 40px;
}

.detail {
    display: flex;
    flex-direction: column;
    align-items: center;
    margin: 0 1rem;
    text-align: center;
}

.label {
    font-size: 0.9rem;
    color: #666;
    margin-bottom: 0.25rem;
}

.value {
    font-size: 1.2rem;
    font-weight: 500;
}

/* Error and offline message styles */
.error-message {
    color: #d32f2f;
    text-align: center;
    margin-top: 1rem;
    display: none;
} 

.offline-message {
    background-color: #ffab91;
    color: #7f0000;
    padding: 0.75rem;
    text-align: center;
    margin-top: 1rem;
    border-radius: 4px;
    display: none;
}


/* 5 days forecast weather */
.forecast-container {
    display: flex;
    justify-content: space-around;
    gap: 1rem;
}

.forecast-item {
    background-color: white;
    border-radius: 8px;
    box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);
    padding: 1rem 4rem;
    text-align: center;
}



footer {
    background-color: #2196f3;
    display: flex;
    align-items: center;
    justify-content: center;
    padding: .7rem 0;
}

footer p, footer a {
    color: #f9f9f9;
    font-weight: 500;
}
/* Responsive styles */
@media (max-width: 480px) {
    .header h1 {
        font-size: 1.2rem;
    }

    .location-container {
        flex-direction: column;
        align-items: center;
        gap: .6rem
    }


    .current-weather {
        flex-direction: column;
        justify-content: center;
        align-items: center;
    }

    .weather-container h3,  .location-weather h3, .forecast h3 {
        font-size: 1.5rem;
    }

    #weather-icon {
        margin-right: 0;
        margin-bottom: 1rem;
    }

    .forecast-container {
        flex-direction: column;
        align-items: center;
    }
}

How to Set Up app.js and config.js

Now, let's create our app.js file to add functionality to the weather app. Before proceeding, ensure you’ve obtained your API key from OpenWeather. For best practice, store your API key in a separate file like config.js to keep things organized and avoid hardcoding sensitive data.

Here's what your config.js should look like:

export const CONFIG = {
    WEATHER_API_KEY: "WRITE-YOUR-API-KEY-HERE",
};

Ensure you add the config.js file to .gitignore to avoid leaking sensitive information on a public platform like GitHub.

Now let’s move to app.js. This is where the main logic of your weather app will live. You can now reference your API key using Weather_API_KEY from the config.js file.

Below is the structure of your app.js file:

import { CONFIG } from './config.js';
const BASE_URL = `https://api.openweathermap.org/data/2.5/weather?&appid=${CONFIG.WEATHER_API_KEY}&units=metric&q=`;

const cityName = document.getElementById('location-input');
const searchButton = document.getElementById('search-btn');
const weatherIcon = document.getElementById('weather-icon');
const locationBtn = document.getElementById('locationBtn');
const weatherInfo = document.getElementById('weatherInfo');


function getWeatherIcon(condition) {
  switch (condition) {
    case "Clear":
      return "images/weather-icons/clear.png";
    case "Clouds":
      return "images/weather-icons/clouds.png";
    case "Drizzle":
      return "images/weather-icons/drizzle.png";
    case "Rain":
      return "images/weather-icons/drizzle.png";
    case "Mist":
      return "images/weather-icons/mist.png";
    case "Snow":
      return "images/weather-icons/snow.png";
    default:
      return "images/weather-icons/default.png";
  }
}
//Search for weather by city name
async function checkWeatherBySearch(city){
    if(city.length == 0) {
        document.getElementsByClassName('error')[0].style.display = 'block';
        document.getElementsByClassName('error')[0].innerHTML = "Please enter a city name!";
        document.getElementsByClassName('error')[0].style.color = 'red';
        document.getElementById('weather-container').style.display = 'none'; 
        return;
    }
    const response = await fetch(BASE_URL + city);
    document.getElementsByClassName('error')[0].style.display = 'block';
    document.getElementsByClassName('error')[0].innerHTML = "Wait a sec, your location's data will be displayed soon!";

    if (response.status == 404) {
        document.getElementsByClassName('error')[0].style.display = 'block';
        document.getElementsByClassName('error')[0].innerHTML = "City not found! Please enter a valid city name.";
        document.getElementsByClassName('error')[0].style.color = 'red';
        document.getElementById('weather-container').style.display = 'none';       
    } else {
      const data = await response.json();
      document.getElementById('weather-container').style.display = 'block';
      document.getElementsByClassName('error')[0].style.display = 'none';
      localStorage.setItem('lastCity', city);
      document.getElementById('city').innerHTML = data.name;
      document.getElementById('date').innerHTML = new Date(data.dt * 1000).toLocaleDateString();
      document.getElementById("temperature").innerHTML = Math.round(data.main.temp) + "°C";
      document.getElementById("humidity").innerHTML = data.main.humidity + "%";
      document.getElementById("wind").innerHTML = data.wind.speed + "m/s";
      document.getElementById('weather-description').innerHTML = data.weather[0].description;
      const weatherCondition = data.weather[0].main;
      weatherIcon.src = getWeatherIcon(weatherCondition);
    }
}

 // display next 5-day forecast by coordinates
function display5DaysForecast(forecast) {
   const fragment = document.createDocumentFragment(); 
    const forecastWrapper = document.createElement('div');
    forecastWrapper.className = 'forecast';

    const heading = document.createElement('h3');
    heading.innerHTML = "Your location's next 5 days forecast:";

    const container = document.createElement('div');
    container.className = 'forecast-container';

    const addedDates = new Set();
    const today = new Date().toDateString();

    forecast.forEach((entry) => {
      const entryDateObj = new Date(entry.dt * 1000);
      const entryDateStr = entryDateObj.toDateString();

      if (entryDateStr !== today && !addedDates.has(entryDateStr)) {
        addedDates.add(entryDateStr);
        if (addedDates.size > 6) return;


        const condition = entry.weather[0].main;
        const iconSrc = getWeatherIcon(condition);

        const forecastItem = document.createElement('div');
        forecastItem.className = 'forecast-item';

        const date = document.createElement('p');
        date.id = 'date';
        date.innerHTML = `<strong>${new Date(entry.dt * 1000).toLocaleDateString()}</strong>`;

        const icon = document.createElement('img');
        icon.loading = 'lazy';
        icon.id = 'weather-icon';
        icon.src = iconSrc;
        icon.alt = `${condition} icon`;

        const tempContainer = document.createElement('div');
        tempContainer.className = 'temperature-container';

        const temp = document.createElement('h3');
        temp.id = 'temperature';
        temp.innerHTML = `${Math.round(entry.main.temp)} °C`;

        const description = document.createElement('p');
        description.id = 'weather-description';
        description.innerHTML = `${entry.weather[0].description}`;

        tempContainer.appendChild(temp);
        tempContainer.appendChild(description);
        forecastItem.appendChild(date);
        forecastItem.appendChild(icon);
        forecastItem.appendChild(tempContainer);
        container.appendChild(forecastItem);
      }
    });

    forecastWrapper.appendChild(heading);
    forecastWrapper.appendChild(container);
    fragment.appendChild(forecastWrapper);
    weatherInfo.appendChild(fragment); 
}

// Fetch next 5-day forecast by coordinates
function get5DaysForecast(lat, lon) {
    fetch(
      `https://api.openweathermap.org/data/2.5/forecast?lat=${lat}&lon=${lon}&appid=${CONFIG.WEATHER_API_KEY}&units=metric`
    )
      .then(res => res.json())
      .then(data => {
        requestIdleCallback(() => {
          setTimeout(() => display5DaysForecast(data.list), 0);
        });        
      })
      .catch(() => {
        weatherInfo.innerHTML = 'Error fetching forecast data.';
    });
}

 // Display current weather data
function displayUserWeather(data) {
    const weatherCondition = data.weather[0].main;
    const iconSrc = getWeatherIcon(weatherCondition);

    weatherInfo.innerHTML = `
      <h2 id="city">${data.name}, ${data.sys.country}</h2>

      <div class="current-weather">
        <img loading="lazy" id="weather-icon" src="${iconSrc}" alt="Weather icon">
        <div class="temperature-container">
          <h3 id="temperature"> ${Math.round(data.main.temp)} °C</h3>
          <p id="weather-description">${data.weather[0].description}</p>
        </div>
      </div>

      <div class="weather-details">
        <div class="detail">
          <img loading="lazy" id="humidity-icon" src="/images/humidity.png" alt="Humidity icon">
          <span class="label">Humidity</span>
          <span id="humidity" class="value"> ${data.main.humidity}%</span>
        </div>
        <div class="detail">
          <img loading="lazy" id="wind-icon" src="/images/wind.png" alt="Wind icon">
          <span class="label">Wind</span>
          <span id="wind" class="value"> ${data.wind.speed} m/s</span>
        </div>
      </div>
    `;
  }

// Fetch weather by coordinates
function getWeatherByCoords(lat, lon) {
    fetch(
      `https://api.openweathermap.org/data/2.5/weather?lat=${lat}&lon=${lon}&appid=${CONFIG.WEATHER_API_KEY}&units=metric`
    )
      .then(res => res.json())
      .then(data => {
        displayUserWeather(data);
        get5DaysForecast(lat, lon);
      })
      .catch(() => {
        weatherInfo.innerHTML = 'Please turn on your device&apos;s location to get weather data.';;
      });
  }

// Event listeners for search button and input field
cityName.addEventListener('keypress', (e) => {
    if (e.key === 'Enter') checkWeatherBySearch(cityName.value);
});

  // Search button click event
searchButton.addEventListener('click', ()=>{
    checkWeatherBySearch(cityName.value);
});

// Geolocation button
locationBtn.addEventListener('click', () => {
    if (navigator.geolocation) {
      navigator.geolocation.getCurrentPosition(
        pos => {
          const { latitude, longitude } = pos.coords;
          getWeatherByCoords(latitude, longitude);
        },
        () => {
          weatherInfo.innerHTML = 'Unable to retrieve location.';
        }
      );
    } else {
      weatherInfo.innerHTML = 'Geolocation not supported.';
    }
});


// Load last searched city
window.onload = () => {
    const lastCity = localStorage.getItem('lastCity');
    if (lastCity) {
        checkWeatherBySearch(lastCity);
    }

    if (navigator.geolocation) {
        navigator.geolocation.getCurrentPosition(
          pos => {
            const { latitude, longitude } = pos.coords;
            getWeatherByCoords(latitude, longitude);
          },
          () => {
            weatherInfo.innerHTML = 'Unable to retrieve location.';
          }
        );
      } else {
        weatherInfo.innerHTML = 'Geolocation not supported.';
      }
};

Now that we have our weather app. Let’s go further to make it a progressive web app.

How to Create a Manifest File

We need to create a manifest.json file, a critical part of making your app a PWA. We’ll also use pwa-asset-generator, a CLI tool that helps you to generate all the necessary icons and splash screens from a single image (like your logo). This tool also updates your manifest.json and optionally injects relevant <link> tags into index.html.

Below is the manifest.json file containing key properties that define how the Progressive Web App behaves and appears when installed.

{
  "name": "Weatherly",                      // The full name of your app that may be shown to users.
  "short_name": "Weatherly",               // A shorter name used when space is limited, like on the home screen.
  "description": "A simple weather Progressive Web App", // A short description of what your app does.
  "start_url": "/index.html",              // The page that opens when the app is launched from the home screen.
  "display": "standalone",                 // Makes the app look like a native app without browser UI (like address bar).
  "background_color": "#ffffff",           // The background color used when the app is loading.
  "theme_color": "#2196f3",                // The main color of the app’s UI, like the status bar.
  "orientation": "portrait",                // Locks the screen orientation to portrait mode.
   "screenshots": [                         //helps show users a preview of your app before installing it — especially in places like the "Add to Home screen" prompt on Android or in app stores that support PWAs.
        {
          "src": "images/screenshots/desktop-screenshot.png",
          "sizes": "1337x645",
          "type": "image/png",
          "form_factor": "wide"
        },
        {
          "src": "images/screenshots/mobile-screenshot.png",
          "sizes": "720x1417",
          "type": "image/png",
          "form_factor": "narrow"
        }
      ]
}

How to Generate Icons and Splash Screens

Inside your images folder, create a new folder called assets. This will store all the generated icons and splash screens. When your app is launched from the home screen, these splash screens will help improve the user experience on iOS devices.

Run the following command to generate PWA assets, update the manifest.json, and inject <link> tags into index.html

npx pwa-asset-generator logo.png ./images/assets -m manifest.json -i index.html

Injected Link Tags in index.html

Once the command runs successfully, a series of <link> and <meta> Tags will be automatically added to your index.html <head>. These tags ensure support for splash screens and icons across various Apple devices:

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <!-- Other meta/link tags -->

  <link rel="apple-touch-icon" href="images/assets/apple-icon-180.png">
  <meta name="mobile-web-app-capable" content="yes">

  <link rel="apple-touch-startup-image" href="images/assets/apple-splash-2048-2732.jpg" media="(device-width: 1024px) and (device-height: 1366px) and (orientation: portrait)">
  <link rel="apple-touch-startup-image" href="images/assets/apple-splash-2732-2048.jpg" media="(device-width: 1024px) and (device-height: 1366px) and (orientation: landscape)">
  <!-- ...more splash screen tags for various devices... -->
</head>

Here’s how the manifest.json file should look like now:

{
    "name": "Weatherly",
    "short_name": "Weatherly",
    "description": "A simple weather Progressive Web App",
    "start_url": "/index.html",
    "display": "standalone",
    "background_color": "#ffffff",
    "theme_color": "#2196f3",
    "orientation": "portrait",
    "icons": [
        [
            {
              "src": "images/assets/manifest-icon-192.maskable.png",
              "sizes": "192x192",
              "type": "image/png",
              "purpose": "any"
            },
            {
              "src": "images/assets/manifest-icon-192.maskable.png",
              "sizes": "192x192",
              "type": "image/png",
              "purpose": "maskable"
            },
            {
              "src": "images/assets/manifest-icon-512.maskable.png",
              "sizes": "512x512",
              "type": "image/png",
              "purpose": "any"
            },
            {
              "src": "images/assets/manifest-icon-512.maskable.png",
              "sizes": "512x512",
              "type": "image/png",
              "purpose": "maskable"
            }
          ]
        ],
    "screenshots": [
        {
          "src": "images/screenshots/desktop-screenshot.png",
          "sizes": "1337x645",
          "type": "image/png",
          "form_factor": "wide"
        },
        {
          "src": "images/screenshots/mobile-screenshot.png",
          "sizes": "720x1417",
          "type": "image/png",
          "form_factor": "narrow"
        }
      ]
    }

You can then link your manifest file to your HTML file:

<link rel="manifest" href="manifest.json" />

How to Add WorkBox to Your service-worker.js File

In this tutorial, WorkBox will be added to index.html via CDN. You can copy the import code below or visit WorkBox to get the link. You can then add it to the index.html file by placing the URL inside a <script> tag. You can copy the import code below or visit the WorkBox website for the latest link.

importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.5.4/workbox-sw.js');

How to Create your Service Worker in the service-worker.js File

Here, we’ll implement the necessary functionalities needed to make the weather app a PWA

Step 1: Activate the New Service Worker Immediately

Add workbox.core.skipWaiting() to make the newly installed service worker activate right away instead of waiting for the old one to be removed in the service-worker.js file.

workbox.core.skipWaiting();

Step 2: Take Control of Open Tabs

Add workbox.core.clientsClaim() to ensure that the activated service worker takes control of all currently open pages, so the latest version of your app works immediately across all tabs after it becomes active.

workbox.core.clientsClaim();

Step 3: Check if Workbox is Loaded

Before using Workbox, make sure it has loaded properly.

if (workbox) {
  console.log('Workbox loaded successfully');
} else {
  console.log('Workbox failed to load');
}

This confirms that the workbox object is available and ready to use. If not, the fallback message in the else block will be shown.

We then proceed to create the functions inside the if block

Step 4: Pre-cache Core Files

Pre-cache essential files enable your app to work offline. This caches your app shell (HTML, CSS, JS), so it loads even without a network connection.

workbox.precaching.precacheAndRoute([
    { url: '/index.html', revision: '3' },
    { url: '/style.css', revision: '11' },
    { url: '/app.js', revision: '7' },
    { url: '/images/logo.png', revision: '3' },
    { url: '/manifest.json', revision: '5' },
    { url: '/offline.html', revision: '1' },
  ]);

The revision helps with updating cached files when changes are made.

Step 5: Cache API Responses Dynamically

Set up a route to cache data from your weather API using the NetworkFirst caching strategy. This tells Workbox to try fetching fresh data from the network first. If the network fails, it serves the cached version instead.

 // Cache API requests 
  workbox.routing.registerRoute(
    ({ url }) => url.origin === 'https://api.openweathermap.org',
    new workbox.strategies.NetworkFirst({
      cacheName: 'weather-api-cache',
      plugins: [
        new workbox.expiration.ExpirationPlugin({
          maxAgeSeconds: 24 * 60 * 60,
          maxEntries: 10,
        }),
      ],
    })
  );

Step 6: Dynamic Image Caching

This function enables dynamic caching for images using the StaleWhileRevalidate strategy. When a user requests an image, Workbox first serves it from the cache (if available) for faster load times, while simultaneously fetching an updated version from the network to refresh the cache. This ensures users get a quick response without missing out on updated content. It’s a smart way to handle images by balancing speed and freshness.

// Cache images
  workbox.routing.registerRoute(
    ({ request }) => request.destination === 'image',
    new workbox.strategies.StaleWhileRevalidate({
      cacheName: 'image-cache',
    })
  );

Step 7: Serve Cached Resources

The commonly used static files (like HTML, CSS, JS, fonts, and so on) are served quickly from the cache. It uses the CacheFirst strategy, meaning that the service worker will look in the cache first and only fetch from the network if the file isn’t already stored. The cache is named "static-cache" and it’s set to automatically remove items older than seven days using the expiration plugin. This helps keep the cache fresh and avoids taking up too much space.

  // Serve Cached Resources 
  workbox.routing.registerRoute(
    ({url}) => url.origin === self.location.origin,  
    new workbox.strategies.CacheFirst({
      cacheName: 'static-cache',  
      plugins: [
        new workbox.expiration.ExpirationPlugin({
          maxAgeSeconds: 7 * 24 * 60 * 60,  // Cache static resources for 7 days
        }),
      ],
    })
  );

Step 8: Cache HTML Pages with Offline Support

The index.html page will be handled using the NetworkFirst strategy. This means that the service worker tries to fetch the latest version from the network first. If the user is offline or the network fails, it falls back to the cached version. The cache is named "pages-cache" and the offline fallback page (offline.html) is returned when the requested page isn’t available. This ensures that users can still navigate the app even without an internet connection.

// Serve HTML pages with Network First and offline fallback
workbox.routing.registerRoute(
  ({ request }) => request.mode === 'navigate',
  async ({ event }) => {
    try {
      const response = await workbox.strategies.networkFirst({
        cacheName: 'pages-cache',
        plugins: [
          new workbox.expiration.ExpirationPlugin({
            maxEntries: 50,
          }),
        ],
      }).handle({ event });
      return response || await caches.match('/offline.html');
    } catch (error) {
      return await caches.match('/offline.html');
    }
  }
);

Step 9: Handle When Workbox Doesn’t Load

You should always provide a fallback in case something goes wrong. The if block will have an else block to catch issues during development and debugging.

else {
     console.log('Workbox failed to load');
}

Once the service worker finishes handling the different conditions in the if-else block, we add a general cleanup step to remove any outdated or unused caches.

Step 10: Clean Up Outdated Caches

During the service worker's activation phase, old or unused caches are removed. It compares all existing cache names with a list of current ones (precache, weather-api-cache, image-cache, pages-cache, and static-resources). If a cache doesn’t match the current list, it gets deleted. This helps keep the app lightweight and ensures that outdated data doesn't persist.

// Clean up old/unused caches during activation
self.addEventListener('activate', event => {
  const currentCaches = [
    workbox.core.cacheNames.precache,
    'weather-api-cache',
    'image-cache',
    'pages-cache',
    'static-cache'
  ];

  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (!currentCaches.includes(cacheName)) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

This is what your service-worker.js file should look like:

importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.5.4/workbox-sw.js');

// Force waiting service worker to become active
workbox.core.skipWaiting();
workbox.core.clientsClaim();

if (workbox) {
  console.log('Workbox loaded successfully');

  // Precache critical files with revisions (update revisions when files change)
  workbox.precaching.precacheAndRoute([
    { url: '/index.html', revision: '3' },
    { url: '/style.css', revision: '11' },
    { url: '/app.js', revision: '7' },
    { url: '/images/logo.png', revision: '3' },
    { url: '/manifest.json', revision: '5' },
    { url: '/offline.html', revision: '1' },
  ]);

  // Cache API requests 
  workbox.routing.registerRoute(
    ({ url }) => url.origin === 'https://api.openweathermap.org',
    new workbox.strategies.NetworkFirst({
      cacheName: 'weather-api-cache',
      plugins: [
        new workbox.expiration.ExpirationPlugin({
          maxAgeSeconds: 24 * 60 * 60,
          maxEntries: 10,
        }),
      ],
    })
  );

  // Cache images
  workbox.routing.registerRoute(
    ({ request }) => request.destination === 'image',
    new workbox.strategies.StaleWhileRevalidate({
      cacheName: 'image-cache',
    })
  );

    // Serve Cached Resources 
  workbox.routing.registerRoute(
    ({url}) => url.origin === self.location.origin,  
    new workbox.strategies.CacheFirst({
      cacheName: 'static-cache',  
      plugins: [
        new workbox.expiration.ExpirationPlugin({
          maxAgeSeconds: 7 * 24 * 60 * 60,  // Cache static resources for 7 days
        }),
      ],
    })
  );

  // Serve HTML pages with Network First and offline fallback
workbox.routing.registerRoute(
  ({ request }) => request.mode === 'navigate',
  async ({ event }) => {
    try {
      const response = await workbox.strategies.networkFirst({
        cacheName: 'pages-cache',
        plugins: [
          new workbox.expiration.ExpirationPlugin({
            maxEntries: 50,
          }),
        ],
      }).handle({ event });
      return response || await caches.match('/offline.html');
    } catch (error) {
      return await caches.match('/offline.html');
    }
  }
);
} else {
  console.log('Workbox failed to load');
}

// Clean up old/unused caches during activation
self.addEventListener('activate', event => {
  const currentCaches = [
    workbox.core.cacheNames.precache,
    'weather-api-cache',
    'image-cache',
    'pages-cache',
    'static-cache'
  ];

  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (!currentCaches.includes(cacheName)) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

How to Set Up App Installation

The code to install the app will be written in install.js following the steps below:

Step 1: Register the Service Worker

Register the service worker to activate and run it in your app.

if('serviceWorker' in navigator){
    window.addEventListener('load', () => {
      navigator.serviceWorker.register('/service-worker.js').then(reg => {
        reg.onupdatefound = () => {
          const newWorker = reg.installing;
          newWorker.onstatechange = () => {
            if (newWorker.state === 'installed' && navigator.serviceWorker.controller) {
              window.location.reload();
            }
          };
        };
      });
    })
 }

Step 2: Enable Custom Install Prompt

Next, we will allow users to install the weather PWA with a custom button. Inside the install.jsfile, add the beforeinstallprompt event which intercepts the default prompt and shows your install button instead. When clicked, it triggers the install prompt.

  let deferredPrompt;

document.addEventListener('DOMContentLoaded', () => {
  const installBtn = document.getElementById('installBtn');

  window.addEventListener('beforeinstallprompt', (e) => {
    e.preventDefault();
    deferredPrompt = e;

    // Show the button
    installBtn.style.display = 'block';

    installBtn.addEventListener('click', () => {
      // Directly triggered by user click
      installBtn.style.display = 'none';

      // Show the install prompt
      deferredPrompt.prompt();

      deferredPrompt.userChoice.then((choiceResult) => {
        if (choiceResult.outcome === 'accepted') {
          console.log('User accepted the install prompt');
        } else {
          console.log('User dismissed the install prompt');
        }
        deferredPrompt = null;
      });
    });
  });

The appinstalled event confirms successful installation.

window.addEventListener('appinstalled', () => {
    console.log('PWA was installed');
  });
});

Step 3: Add script tag to import install.js in index.html

Add the <script> tag for install.js inside the index.html file to include the installation logic.

 <script type="module" src="/js/install.js"></script>

How to Install the Weather App

You can choose to install the Weatherly app on your phone or desktop. Below is a demonstration on how to install it on your mobile phone:

Open the Weatherly app in your browser. You should see an “Install App” button, as shown in the image below. Click on the button to continue.

After clicking, a preview of the app will appear along with an “Install” option, as shown below. Click the Install button.

Once the installation is complete, the Weatherly app will appear on your home screen, just like a native app. And that’s it! Your weather app is now a Progressive Web App (PWA).

Conclusion

Progressive Web Apps combine the best of web and native app experiences, and service workers are the backbone of that functionality. With tools like Workbox, you don’t have to worry about manually handling caching, offline support, or background sync. Its simple APIs and built-in strategies make it easier to build fast, reliable, and installable web apps. Whether it’s a small weather app like Weatherly or a more complex project, Workbox helps you deliver a seamless user experience.

You can check out the full project and assets on GitHub

In this tutorial, you’ll learn how to build a PWA using Next.js. We’ll start by creating a functional movie search website with these tools. Once we have the basics set up, we’ll transform this app into a PWA, adding offline support and faster load times. By the end, you’ll have a powerful PWA that offers a smooth user experience across all platforms—all from a single codebase.

What We’ll Cover

• Setting Up the Project: We'll begin by creating the movie search app using Next.js, which is an ideal choice in 2024 for building fast, reliable React apps that work well on all devices.

• Turning the App into a PWA: Next, we’ll walk through the steps to convert the app into a Progressive Web App, covering the key features and best practices of PWAs.

• Adding Offline Support: Finally, we’ll ensure your app stays functional even when there’s no internet connection by implementing offline capabilities.

Here’s what the final application will look like:

Audience

This tutorial is for React developers of all levels, whether you’re just starting out or already experienced. If you want to enhance your web apps with PWA features, this guide will take you through the necessary steps.

Prerequisites

Before you begin, make sure you’re familiar with React.js and Next.js. If you’re new to PWAs, you might want to read some introductory articles to get a quick overview.

• What are Progressive Web Apps? PWA Guide for Beginners

• Learn Progressive Web Apps

What is a Progressive Web App (PWA)?

A Progressive Web App (PWA) is a type of web application built using standard web technologies like HTML, CSS, and JavaScript. PWAs work on the web, desktop, and mobile devices, combining the best features of web and native apps to deliver a fast, reliable, and engaging experience.

What makes PWAs special is their ability to work offline, send push notifications, and be installed on a user’s device without an app store. In short, a PWA makes your web app feel like a native app while keeping the flexibility and wide reach of the web.

Why Turn Your Web App into a PWA?

Converting your web app into a PWA brings several benefits:

• Cross-Platform Availability: A PWA works on any device with a browser, so you only need to develop and maintain one codebase for web, mobile, and desktop apps. This saves time and ensures a consistent experience across all platforms.

• Offline Capabilities: PWAs can work offline or in areas with poor connectivity by caching essential resources, keeping your app functional even without internet access.

• Improved Performance: PWAs are built to load quickly and run smoothly, even on slow networks, thanks to techniques like service workers and caching.

• Increased User Engagement: Users can add PWAs directly to their home screen without needing an app store. This easy access, along with features like push notifications, helps keep users engaged and coming back.

Disadvantages of PWAs

While PWAs offer many benefits, there are a few downsides:

• Limited Access to Device Features: PWAs don’t have full access to certain device features like Bluetooth or advanced camera controls. For apps that need deep hardware integration, this can be a limitation.

• Less Visibility: Since PWAs don’t go through app stores, they miss out on the visibility that app stores offer. Some users might also prefer downloading apps from app stores rather than directly from the browser.

• Limited iOS Support: Some features of PWAs, like push notifications, don’t work as well on iPhones and iPads compared to Android devices, which can limit engagement with iOS users.

Getting Started: Setting Up the Next.js Project

Now that we’ve talked about the benefits of PWAs, let’s get into the actual implementation. We’ll start by setting up the necessary files in our project.

Why Choose Next.js in 2024?

Next.js is a top choice for building React apps in 2024. It offers features like server-side rendering and static site generation, making it easier to create fast and reliable web apps. These features ensure your app performs well on all devices and even works offline.

Project Installation

Follow these steps to set up your Next.js project:

1. Clone the Repository: Open your terminal and run:

    git clone https://github.com/iamspruce/MovieMaster.git
   

2. Navigate to Your Project Directory:

    cd your-repo
   

3. Install Dependencies: Install the required packages with:

    npm install
   

4. Configure Environment Variables: Create a .env.local file in the root directory and add your OMDB API key:

    NEXT_PUBLIC_OMDB_API_KEY=your-api-key
   

You can obtain your API key from the OMDB API website.

Why is the OMDB API Key Needed?
The OMDB API key allows your PWA to fetch movie data, like titles, posters, and descriptions, directly from the OMDB database. This is essential for a movie-related app like MovieMaster, as it provides up-to-date information for users without you having to store all the data yourself.

In a PWA, using an API like OMDB ensures that the app can deliver fresh content to users, even when it's installed on their devices. Combined with the PWA's caching and offline features, users can still view movie details that were previously fetched, even if they lose internet connectivity.

Note: Make sure Node.js and npm are installed on your system. If they are not, you can download them from nodejs.org.

Project Structure Overview

Here’s a brief overview of the project layout:

• /public: Contains static files such as images and favicons.

• /src/app: Houses the main application files, including global styles (globals.css), the main page (page.tsx), layout configurations (layout.tsx), and client-side logic (RootLayoutClient.tsx).

• /src/components: Includes reusable components. Shadcn UI components are located in the /ui directory, and other specific components like MovieCard.tsx are here.

• /src/lib: Contains utility functions and data-fetching code, such as fetchMovies.ts and useMediaQuery.ts.

For styling, we use:

• TailwindCSS: Applied through globals.css for a utility-first approach to design.

• Shadcn UI: A library providing accessible, ready-to-use UI components.

Understanding Layouts

The project uses two key layouts:

1. layout.tsx: Manages server-side rendering and sets the application’s metadata. It uses the RootLayoutClient component to handle client-side functionality. Here’s how it looks:

    import React from "react";
    import type { Metadata } from "next";
    import { cn } from "@/lib/utils";
    import { Inter as FontSans } from "next/font/google";
   
    import RootLayoutClient from "./RootLayoutClient";
   
    const fontSans = FontSans({
      subsets: ["latin"],
      variable: "--font-sans",
    });
   
    export const metadata: Metadata = {
      title: "MovieMaster",
      description: "MovieMaster PWA helps you find the latest movies with an easy search by genre, year, and more. It works smoothly on any device, even offline, giving you a great movie browsing experience.",
      manifest: "/web.manifest",
    };
   
    export default function RootLayout({ children }: { children: React.ReactNode }) {
      return (
        <html lang="en" suppressHydrationWarning>
          <body className={cn("min-h-screen bg-background font-sans antialiased", fontSans.variable)}>
            <RootLayoutClient>{children}</RootLayoutClient>
          </body>
        </html>
      );
    }
   

2. RootLayoutClient.tsx: Handles client-side logic, essential for rendering interactive elements and managing UI states."

    "use client";
   
    import React from "react";
    import { Toaster } from "@/components/ui/sonner";
    import "./globals.css";
   
    export default function RootLayoutClient({ children }: { children: React.ReactNode }) {
      return (
        <div className="text-white flex flex-col">
          <div className="container mx-auto px-4 max-w-[1024px]">
            {children}
            <Toaster />
          </div>
        </div>
      );
    }
   

Running and Previewing the Project

To start working with your project:

Start the Development Server: In your terminal, execute:

npm run dev

This will start the development server, and you can view the application by navigating to http://localhost:3000 in your browser.

How to Turn Your Web App into a PWA

To transform your web app into a PWA, there are certain criteria that your app must meet. Let's walk through these requirements and implement the necessary changes step by step.

Criteria for a PWA

1. Served Over HTTPS: Your app must be served over a secure origin (HTTPS) or localhost for development. If you’re developing locally, this criterion is already met.

2. Web Manifest File: A web manifest file provides metadata about your app, such as its name, icons, and start URL. This file is crucial for making your app installable on a user's device.

3. Service Worker with a fetch Event: Your app must register a service worker with at least a fetch event. Registering a service worker with at least a fetch event is essential for your app to be recognized as a PWA and be installable. Beyond that, service workers enhance your app's performance and reliability, allowing it to cache resources and handle network requests even when offline.

How to Add a Web Manifest File to Your Next.js App

To add a web manifest file in your Next.js app, place it in the public/ directory and reference it in your layout file. Ensure that all the images you include in your manifest file are also in the public/ directory.

Here’s an example of a web.manifest file:

{
  "name": "Movie Master",
  "short_name": "Moviemaster",
  "theme_color": "#8936FF",
  "background_color": "#333333",
  "start_url": "/",
  "id": "MovieMaster",
  "display": "standalone",
  "description": "MovieMaster PWA helps you find the latest movies with an easy search by genre, year, and more. It works smoothly on any device, even offline, giving you a great movie browsing experience.",
  "icons": [
    {
      "purpose": "maskable",
      "sizes": "512x512",
      "src": "icon512_maskable.png",
      "type": "image/png"
    },
    {
      "purpose": "any",
      "sizes": "512x512",
      "src": "icon512_rounded.png",
      "type": "image/png"
    }
  ],
  "screenshots": [
    {
      "src": "screenshot1.png",
      "type": "image/png",
      "sizes": "1080x1920",
      "form_factor": "narrow"
    }
  ]
}

Required Fields

• name: The full name of your app.

• short_name: A shorter version of the app’s name, displayed when there isn’t enough space for the full name.

• icons: Icons representing your app at various sizes.

• start_url: The URL that opens when the app is launched.

• display: Defines the display mode (for example, standalone for a full-screen experience).

Recommended Fields

• theme_color: Sets the theme color of the browser’s UI, such as the address bar. This color enhances the native feel of your PWA.

This example shows how the theme color (#8936FF) is applied to the browser's UI, giving your PWA a native feel.

• background_color: Defines the background color for the splash screen when your app is launched.

• screenshots: Provide screenshots of your app to improve the installation experience, especially on Android devices.

This example illustrates how screenshots are displayed during the installation process, enhancing the user experience, especially on Android devices.

• id: Unique identifier for the app

How to Reference the Web Manifest File

Next, let’s add the manifest file to your pages. In Next.js, you can include it in the metadata of your Layout.tsx:

export const metadata: Metadata = {
  title: "MovieMaster",
  description: "Find the latest movies with ease.",
  manifest: "/web.manifest", // Link to the manifest file
};

How to Register a Service Worker

A service worker is a script that your browser runs in the background, allowing you to control how your app handles network requests, caching, and other tasks.

Registering a service worker with at least a fetch event is essential for your app to be recognized as a PWA and be installable.

Create a service-worker.js file in the public/ directory with the following code:

self.addEventListener('install', (event) => {
  console.log('Service Worker installing.');
});

self.addEventListener('activate', (event) => {
  console.log('Service Worker activating.');
});

self.addEventListener('fetch', (event) => {
  console.log('Fetching:', event.request.url);
  event.respondWith(fetch(event.request));
});

Then, register the service worker in your RootLayoutClient.tsx file:

"use client";

import React from "react";

export default function RootLayoutClient({ children }) {
  React.useEffect(() => {
    if ("serviceWorker" in navigator) {
      navigator.serviceWorker
        .register("/service-worker.js")
        .then((registration) => {
          console.log("Service Worker registered with scope:", registration.scope);
        })
        .catch((error) => {
          console.error("Service Worker registration failed:", error);
        });
    }
  }, []);

  return (
    <div className="text-white flex flex-col">
      <div className="container mx-auto px-4 max-w-[1024px]">
        {children}
      </div>
    </div>
  );
}

Once your app meets all the criteria, users can easily install it on their devices. For example, when using the Edge browser, an install option will appear in the browser’s menu, allowing users to add your app directly to their desktop or home screen.

Here's what the installation process looks like:

How to Add Offline Support

At this stage, even though our app is technically a PWA, it still behaves like a regular web application. Whenever a user requests a resource, the app makes a network request, and if the network fails, the user is greeted with an error page. This isn’t ideal, especially when the power of a PWA lies in its ability to function offline or in poor network conditions.

With a PWA, you can intercept every request made by your app using a service worker. This gives you the flexibility to decide how to serve content—from the network or from a cache. This control allows you to ensure that users can still access the app, even without an internet connection.

How to Deliver Resources from the Network

Let’s start by looking at how our app currently behaves, which is similar to any standard web application:

self.addEventListener("fetch", (event) => {
  event.respondWith(fetch(event.request));
});

This code simply fetches resources directly from the network. If the network is unavailable, the request will fail, leading to an error. This is the default behavior for a standard web app.

How to Implement Offline Support

To provide an offline experience, we need to cache our app’s resources when the user is online and then serve these cached resources when the user is offline. For this, we’ll use the Cache Storage API, which allows us to store resources locally on the user's device.

What to Cache?

The decision on what to cache depends on the needs of your application. For a movie search app like ours, we’ll want to cache the essential resources required to render a basic version of the application:

• The main HTML page

• CSS stylesheets needed to render the site

• Images used in the user interface

• JavaScript files required for functionality

• API request responses

Note: While you can cache almost anything, be mindful of storage limitations, as all cached items are stored on the user’s device. Use storage wisely to avoid taking up too much space.

When to Cache?

Once we know what to cache, the next thing to consider is when to cache. Should you cache everything during the service worker installation, or should you cache resources as they are requested?

The answer depends on the app's needs, but a good practice is to cache the core files required to render a basic version of the app during the service worker installation.

Here’s how you can do that:

const CACHE_NAME = "MOVIE_MASTER_V1";

async function cacheCoreAssets() {
  const cache = await caches.open(CACHE_NAME);
  return cache.addAll([
    "/",
    "/imdb-logo.svg",
    "/rotten-tomatoes-logo.svg",
  ]);
}

self.addEventListener("install", (event) => {
  event.waitUntil(cacheCoreAssets());
  self.skipWaiting();
});

In this code, self.skipWaiting() ensures that the new service worker activates immediately after installation, bypassing the waiting phase.

It’s also important to delete old caches when a new service worker is activated:

async function clearOldCaches() {
  const cacheNames = await caches.keys();
  return Promise.all(
    cacheNames
      .filter((name) => name !== CACHE_NAME)
      .map((name) => caches.delete(name))
  );
}

self.addEventListener("activate", (event) => {
  event.waitUntil(clearOldCaches());
  self.clients.claim();
});

The self.clients.claim() method ensures that the new service worker takes control of all pages as soon as it activates.

Dynamic Caching

Dynamic caching is particularly useful for React apps like ours, where static files are automatically generated. With dynamic caching, you don’t need to know all the files in advance. Instead, it handles the caching process for you as files are requested.

async function dynamicCaching(request) {
  const cache = await caches.open(CACHE_NAME);

  try {
    const response = await fetch(request);
    const responseClone = response.clone();
    await cache.put(request, responseClone);
    return response;
  } catch (error) {
    console.error("Dynamic caching failed:", error);
    return caches.match(request);
  }
}

With dynamic caching, files requested by the app are cached as they are fetched, ensuring that they are available for future offline use.

Caching API Requests

When it comes to caching API responses, instead of caching the entire response, it’s often better to cache the specific data returned by the API. For this, we can use IndexedDB, a local database built into the browser.

IndexedDB is more powerful than the Cache Storage API, especially for storing and retrieving structured data like JSON. This makes it an excellent choice for apps that require storing complex data or handling large amounts of information efficiently.

How to Set Up IndexedDB

First, create a function to open the database and create an object store:

const DB_NAME = "MovieMaster";
const DB_VERSION = 1;
const DB_STORE_NAME = "myStore";

function openDb() {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open(DB_NAME, DB_VERSION);
    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
    request.onupgradeneeded = (event) => {
      const db = event.target.result;
      db.createObjectStore(DB_STORE_NAME, { keyPath: "url" });
    };
  });
}

Next, create functions to add data to and retrieve data from the database:

async function addData(url, jsonData) {
  const db = await openDb();
  const transaction = db.transaction(DB_STORE_NAME, "readwrite");
  const store = transaction.objectStore(DB_STORE_NAME);

  const data = {
    url,
    response: JSON.stringify(jsonData),
  };

  const request = store.put(data);
  await new Promise((resolve, reject) => {
    request.onsuccess = () => resolve();
    request.onerror = () => reject(request.error);
  });
}

async function getData(url) {
  try {
    const db = await openDb();
    const transaction = db.transaction(DB_STORE_NAME, "readonly");
    const store = transaction.objectStore(DB_STORE_NAME);

    const request = store.get(url);

    const result = await new Promise((resolve, reject) => {
      request.onsuccess = () => resolve(request.result);
      request.onerror = () => reject(request.error);
    });

    if (result && result.response) {
      return JSON.parse(result.response);
    }

    return null;
  } catch (error) {
    console.error("Error retrieving from IndexedDB:", error);
    return null;
  }
}

How to Serve Cached Resources

Once we have cached our assets and stored API data in IndexedDB, the next step is to serve this data to users when they are offline. There are several strategies to achieve this:

Cache First Strategy

In the cache-first strategy, we check if a resource is available in the cache. If it is, we serve it from the cache; if not, we fetch it from the network. This is particularly useful for serving static assets like HTML, CSS, and JavaScript files:

async function cacheFirstStrategy(request) {
  try {
    const cache = await caches.open(CACHE_NAME);
    const cachedResponse = await cache.match(request);

    if (cachedResponse) {
      return cachedResponse;
    }

    const networkResponse = await fetch(request);
    const responseClone = networkResponse.clone();
    await cache.put(request, responseClone);
    return networkResponse;
  } catch (error) {
    console.error("Cache first strategy failed:", error);
    return caches.match("/offline");
  }
}

self.addEventListener("fetch", (event) => {
  const { request } = event;
  if (event.request.mode === "navigate") {
    event.respondWith(cacheFirstStrategy(request));
  } else {
    event.respondWith(dynamicCaching(request));
  }
});

In this setup, the cache-first strategy is applied when navigating to new pages, while dynamic caching handles other requests.

Network First Strategy

The network-first strategy is the opposite: it attempts to fetch resources from the network first, and if the network is unavailable, it falls back to the cache. This strategy is particularly useful for API requests where you want the most up-to-date data:

async function networkFirstStrategy(request) {
  try {
    const networkResponse = await fetch(request);

    if (networkResponse.ok) {
      const responseClone = networkResponse.clone();
      const responseData = await responseClone.json();
      await addData(request.url, responseData);
      return networkResponse;
    }

    throw new Error("Network response was not ok");
  } catch (error) {
    console.error("Network first strategy failed:", error);
    const cachedResponse = await getData(request.url);

    if (cachedResponse) {
      console.log("Using cached response:", cachedResponse);
      return new Response(JSON.stringify(cachedResponse), {
        status: 200,
        headers: { "Content-Type": "application/json" },
      });
    }

    return new Response("[]", { status: 200 });
  }
}

self.addEventListener("fetch", (event) => {
  const { request } = event;
  const url = new URL(request.url);

  if (url.origin === "https://www.omdbapi.com") {
    event.respondWith(networkFirstStrategy(request));
  } else if (event.request.mode === "navigate") {
    event.respondWith(cacheFirstStrategy(request));
  } else {
    event.respondWith(dynamicCaching(request));
  }
});

In our app, we use the network-first strategy for API calls, ensuring that the user gets the latest data when online, while falling back to cached data in IndexedDB when offline.

Full Service Worker Code

Here’s the complete service-worker.js file that incorporates everything we’ve discussed:

const CACHE_NAME = "MOVIE_MASTER_V1";
const DB_NAME = "MovieMaster";
const DB_VERSION = 1;
const DB_STORE_NAME = "myStore";

async function cacheCoreAssets() {
  const cache = await caches.open(CACHE_NAME);
  return cache.addAll([
    "/",
    "/imdb-logo.svg",
    "/rotten-tomatoes-logo.svg",
    "/offline",
  ]);
}

self.addEventListener("install", (event) => {
  event.waitUntil(cacheCoreAssets());
  self.skipWaiting();
});

async function clearOldCaches() {
  const cacheNames = await caches.keys();
  return Promise.all(
    cacheNames
      .filter((name) => name !== CACHE_NAME)
      .map((name) => caches.delete(name))
  );
}

self.addEventListener("activate", (event) => {
  event.waitUntil(clearOldCaches());
  self.clients.claim();
});

async function dynamicCaching(request) {
  const cache = await caches.open(CACHE_NAME);

  try {
    const response = await fetch(request);
    const responseClone = response.clone();
    await cache.put(request, responseClone);
    return response;
  } catch (error) {
    console.error("Dynamic caching failed:", error);
    return caches.match(request);
  }
}

function openDb() {
  return new Promise((resolve, reject) => {
    const request = indexedDB.open(DB_NAME, DB_VERSION);
    request.onsuccess = () => resolve(request.result);
    request.onerror = () => reject(request.error);
    request.onupgradeneeded = (event) => {
      const db = event.target.result;
      db.createObjectStore(DB_STORE_NAME, { keyPath: "url" });
    };
  });
}

async function addData(url, jsonData) {
  const db = await openDb();
  const transaction = db.transaction(DB_STORE_NAME, "readwrite");
  const store = transaction.objectStore(DB_STORE_NAME);

  const data = {
    url,
    response: JSON.stringify(jsonData),
  };

  const request = store.put(data);
  await new Promise((resolve, reject) => {
    request.onsuccess = () => resolve();
    request.onerror = () => reject(request.error);
  });
}

async function getData(url) {
  try {
    const db = await openDb();
    const transaction = db.transaction(DB_STORE_NAME, "readonly");
    const store = transaction.objectStore(DB_STORE_NAME);

    const request = store.get(url);

    const result = await new Promise((resolve, reject) => {
      request.onsuccess = () => resolve(request.result);
      request.onerror = () => reject(request.error);
    });

    if (result && result.response) {
      return JSON.parse(result.response);
    }

    return null;
  } catch (error) {
    console.error("Error retrieving from IndexedDB:", error);
    return null;
  }
}

async function cacheFirstStrategy(request) {
  try {
    const cache = await caches.open(CACHE_NAME);
    const cachedResponse = await cache.match(request);

    if (cachedResponse) {
      return cachedResponse;
    }

    const networkResponse = await fetch(request);
    const responseClone = networkResponse.clone();
    await cache.put(request, responseClone);
    return networkResponse;
  } catch (error) {
    console.error("Cache first strategy failed:", error);
    return caches.match("/offline");
  }
}

async function networkFirstStrategy(request) {
  try {
    const networkResponse = await fetch(request);

    if (networkResponse.ok) {
      const responseClone = networkResponse.clone();
      const responseData = await responseClone.json();
      await addData(request.url, responseData);
      return networkResponse;
    }

    throw new Error("Network response was not ok");
  } catch (error) {
    console.error("Network first strategy failed:", error);
    const cachedResponse = await getData(request.url);

    if (cachedResponse) {
      console.log("Using cached response:", cachedResponse);
      return new Response(JSON.stringify(cachedResponse), {
        status: 200,
        headers: { "Content-Type": "application/json" },
      });
    }

    return new Response("[]", { status: 200 });
  }
}

self.addEventListener("fetch", (event) => {
  const { request } = event;
  const url = new URL(request.url);

  if (url.origin === "https://www.omdbapi.com") {
    event.respondWith(networkFirstStrategy(request));
  } else if (event.request.mode === "navigate") {
    event.respondWith(cacheFirstStrategy(request));
  } else {
    event.respondWith(dynamicCaching(request));
  }
});

With this setup, your PWA is now fully equipped to handle both static and dynamic content, provide an offline experience, and cache API data intelligently.

Further Reading

There are many more strategies and nuances to building a robust offline experience with service workers. If you want to dive deeper into this topic, consider reading more about:

• Different caching strategies: Cache-First, Network-First, Stale-While-Revalidate, and so on.

• Advanced service worker features like background sync and push notifications.

• Best practices for managing cache and storage limits

By understanding and implementing these concepts, you can ensure that your app remains functional and user-friendly, even in challenging network conditions.

Providing a Fallback Page

Even with caching strategies in place, there may be times when users try to access a resource that isn’t available offline and in the network. To handle these situations gracefully, we can create a fallback page. This page will be shown whenever a user tries to access content that can't be retrieved from either the cache or the network.

If you cloned the example project for this tutorial, you should already have a fallback page located in the app directory. This page is designed to handle offline scenarios gracefully and includes a simple Tic-Tac-Toe game for users to play while waiting for the connection to be restored. Here’s what the fallback page looks like:

"use client";
import TicTacToe from "@/components/TicTacToe";
import { useState, useEffect } from "react";
import { useRouter } from "next/navigation";
import Link from "next/link";

const Fallback: React.FC = () => {
  const [isOnline, setIsOnline] = useState(false);
  const router = useRouter();

  useEffect(() => {
    const handleOnline = () => {
      setIsOnline(true);
      // Redirect to homepage if online
      router.push("/");
    };

    const handleOffline = () => {
      setIsOnline(false);
    };

    window.addEventListener("online", handleOnline);
    window.addEventListener("offline", handleOffline);

    return () => {
      window.removeEventListener("online", handleOnline);
      window.removeEventListener("offline", handleOffline);
    };
  }, [router]);

  const handleRefresh = () => {
    if (navigator.onLine) {
      router.push("/");
    } else {
      setIsOnline(false);
    }
  };

  return (
    <div className="flex mx-auto h-screen max-w-[500px] w-full flex-col items-center justify-center h-screen bg-foreground text-black p-6 mt-12 text-white">
      <h1 className="text-3xl font-bold mb-6">
        {isOnline ? "You are online!" : "You are offline"}
      </h1>
      <p className="text-lg text-center mb-6">
        {isOnline
          ? "You are back online."
          : "Please check your internet connection and try again."}
      </p>
      <div className="">
        <TicTacToe />
      </div>
      {isOnline ? (
        <Link
          href={"/"}
          className="mt-6 px-4 py-2 bg-blue-500 text-white rounded shadow hover:bg-blue-600"
        >
          Return to Homepage
        </Link>
      ) : (
        <button
          onClick={handleRefresh}
          className="mt-6 px-4 py-2 bg-blue-500 text-white rounded shadow hover:bg-blue-600"
        >
          Refresh
        </button>
      )}
    </div>
  );
};

export default Fallback;

Note: You can customize this fallback page to suit your application’s needs, whether that’s displaying helpful offline content, providing a message, or offering a small interactive feature like the Tic-Tac-Toe game included here.

Caching the Fallback Page

Next, ensure that the fallback page is cached when the service worker is installed:

const CACHE_NAME = "MOVIE_MASTER_V1";

async function cacheCoreAssets() {
  const cache = await caches.open(CACHE_NAME);
  return await cache.addAll([
    "/",
    "/fallback",
    // other assets
  ]);
}

Serving the Fallback Page

Finally, modify the cacheFirstStrategy to serve the offline.html page when a request fails:

async function cacheFirstStrategy(request) {
  try {
    const cache = await caches.open(CACHE_NAME);
    const cachedResponse = await cache.match(request);

    if (cachedResponse) {
      return cachedResponse;
    }

    const networkResponse = await fetch(request);
    const responseClone = networkResponse.clone();
    await cache.put(request, responseClone);
    return networkResponse;
  } catch (error) {
    console.error("Cache first strategy failed:", error);
    return caches.match("/offline.html");
  }
}

This approach ensures that users always see a meaningful message instead of an error when they’re offline or when a resource is unavailable.

Conclusion

With our Next.js app set up, we’ve successfully transformed it into a fully functional Progressive Web App (PWA), making it better and more user-friendly.

This guide showed how to build a strong PWA using Next.js by adding features like offline support, caching, and service workers. These improvements boost performance and provide a smooth experience on all devices, combining the best of web and native apps.

With these tips, you’ll be ready to create engaging, reliable, and high-performance PWAs that stand out in web development.

They bring together the best parts of using a website (easy to access, no need to install anything) with the great features of mobile apps (fast, can work offline), offering a high-quality user experience.

The core of a PWA's usefulness lies in the offline-first approach, where applications are designed to function seamlessly without a constant internet connection. This means you can still use these apps even when your internet is slow or not available, and makes PWAs very user-friendly and accessible, even where an internet connection is not always reliable.

Graphic showing a native app vs a web application vs a PWA

5 Reasons to Use a PWA Instead of a Native app

Progressive Web Apps (PWAs) are reshaping the landscape of digital interaction. They offer a hybrid experience that combines the best features of web and mobile apps.

Let's delve deeper into why PWAs are often a superior choice compared to native apps:

1. Speed and Ease of Installation

PWAs eliminate the lengthy download and installation process typical of native apps. You can access a PWA as swiftly as you'd load a web page, making it as straightforward as bookmarking your favorite site – no waiting for downloads or navigating through app stores.

Consider Twitter Lite, a PWA version of the popular social media platform, which offers the full Twitter experience without the need to wait for a separate app download.

2. Minimal Storage Requirements

One of the most significant advantages of PWAs is their minimal storage requirements. Since they primarily store data online, much like cloud services, they occupy significantly less space on a user’s device.

This feature is particularly beneficial for users with limited device storage or expensive data plans. For example, Pinterest’s PWA takes up less space than its native counterpart but still provides a rich, engaging user experience.

3. Reliable Offline Performance

A PWA's ability to function offline is like having a good book downloaded to your e-reader, ready to enjoy even when you're out of range of a good signal.

PWAs can function effectively even in areas with poor or no internet connectivity, using cached data from previous online activities. This ensures that users have uninterrupted access to essential features.

A notable example is the Starbucks PWA, which allows customers to browse the menu and customize orders, regardless of their internet connection for a consistent user experience.

4. Cost-Effective Development and Cross-Device Compatibility

Developing a PWA can be more cost-effective than building native apps for various platforms. This unified approach not only saves significant development time and resources but also simplifies maintenance and updates.

Businesses like Uber have leveraged PWAs to provide a seamless user experience across all devices without the need for multiple native apps.

5. Automatic Updates and Push Notifications

PWAs update themselves seamlessly, much like a web page loading the latest content each time it’s visited. Users always have access to the most current version of the app without going through the process of manual updates. This feature ensures that users are not hindered by outdated versions, a common issue with native apps.

For instance, Google Maps’ PWA automatically incorporates the latest features and improvements without user intervention. In addition to staying current, PWAs can engage users with push notifications, just like native apps, keeping them informed and involved without the need for a visit to the app store.

Infographic of a Progressive Web App (PWA) showcasing its features: adaptability across devices, security, offline functionality, fast performance, updates, and push notifications.

PWA Core Concepts

To fully grasp the potential and functionality of Progressive Web Apps, it's essential to understand their foundational components. These core concepts not only define the structure and behavior of PWAs but also distinguish them from traditional web applications.

Service Workers: The Backbone of PWAs

Service workers are scripts that run in the background, separate from your web page. They act as a proxy between the web application and the network.

Think of service workers as behind-the-scenes helpers for your web app. Their main job is to manage how your app talks to the internet.

They can save important parts of your app on the user's device, which means your app can work even when there's no internet. They're also in charge of quietly updating app content and can send notifications, just like a native app on your phone.

The App Manifest: Your PWA's Identity

The web app manifest is a JSON file which is essential because it tells the user's device how your app should look and behave.

It's like your app's ID card – it includes the app's name, the icons it uses, the first page it should open, and how it should display (like in full screen). This file makes your web app feel more like a regular app, allowing users to 'install' it on their home screen.

Caching: The Key to Offline Functionality

Effective caching is vital for a robust offline experience. Caching is like your app's memory. It stores important parts of your app so they can be quickly loaded later, even if there's no internet. It's crucial for making your app work offline.

There are different ways to handle caching, such as cache-first (where the app checks the cache before the internet), network-first (the opposite), and stale-while-revalidate (a mix of both). The choice depends on what your app does and what kind of information it handles, affecting how your app stores and retrieves its data.

Icons representing key components of a PWA: Service worker, Manifest and HTTPS

Overview of Building a PWA

Building a Progressive Web App (PWA) might sound complex, but it's quite manageable when you break it down into steps. In this article, I'll give you an overview of the process – and in my next tutorial, I'll go into the process in more detail.

1. Start with a Basic Webpage:

Create a simple website using HTML for structure, CSS for style, and JavaScript for functionality.

<!DOCTYPE html>
<html>
<head>
    <title>Ophy's To-Do List PWA</title>
</head>
<body>
    <h1>Ophy's To-Do List</h1>
    <input type="text" id="todo-input" placeholder="Add a new task...">
    <button onclick="addTask()">Add</button>
    <ul id="todo-list">
        <!-- Tasks will go here -->
    </ul>

    <script src="app.js"></script>
</body>
</html>

body {
    font-family: 'Arial', sans-serif;
}

#todo-list {
    list-style-type: none;
}

#todo-list li {
    padding: 5px;
    margin: 5px;
    background-color: #f2f2f2;
    border-radius: 3px;
}

function addTask() {
    var input = document.getElementById('todo-input');
    var newTask = input.value;
    if (newTask) {
        var listItem = document.createElement('li');
        listItem.textContent = newTask;
        document.getElementById('todo-list').appendChild(listItem);
        input.value = ''; // Clear the input
    }
}

2. Create a Manifest File:

In the manifest file, write down your app's name, the icons it uses, and the first page it should open. This makes your website act more like an app you can install.

{
    "name": "Ophy's To-Do List",
    "short_name": "OphyToDo",
    "icons": [
        {
            "src": "favicon.ico",
            "sizes": "64x64 32x32 24x24 16x16",
            "type": "image/x-icon"
        }
    ],
    "start_url": "/",
    "display": "standalone",
    "theme_color": "#000000",
    "background_color": "#ffffff"
}

3. Set Up a Service Worker:

In your main JavaScript file, add a service worker. This is a special script that works separately from your website.

The service worker's job is to handle how your app stores and retrieves data, especially for offline use.

self.addEventListener('install', function(event) {
    // Perform install steps
    var CACHE_NAME = 'ophy-todo-cache-v1';
    var urlsToCache = [
        '/',
        '/styles.css',
        '/app.js'
    ];

    event.waitUntil(
        caches.open(CACHE_NAME)
            .then(function(cache) {
                console.log('Opened cache');
                return cache.addAll(urlsToCache);
            })
    );
});

Following these steps will help you build a simple PWA that users can install and use, even when they're offline.

Real World Use Cases for PWAs

These real-world examples demonstrate the practical benefits and impact of offline-first strategies:

1. Starbucks: Starbucks has a PWA that lets customers look at the menu and order drinks and food even when they're offline. This not only makes the experience better for customers but also helps increase sales and customer interaction with the brand, as they can order anytime, anywhere.
2. Khan academy: Khan Academy, a well-known educational site, has a PWA allowing students to download and access lessons and courses without an internet connection. This feature is particularly helpful for those in areas with unreliable internet, ensuring uninterrupted learning. Just like the Starbucks PWA, Khan Academy's use of this technology improves the user experience, making education more accessible and flexible.
3. Trivago: Trivago, a popular hotel search engine, developed a PWA to enhance user experience, especially for travelers with unstable internet connections. The PWA allows users to browse hotel deals and information offline, making trip planning more flexible and accessible. This has led to increased user engagement and higher conversion rates, as travelers can continue interacting with the app even in areas with poor connectivity.
4. Forbes: Forbes, a leading global media company, launched a PWA to improve the mobile experience for its readers. The PWA significantly reduced loading times and allowed offline reading of articles. This innovation not only enhanced user engagement but also resulted in a noticeable increase in readership and time spent on the site. The Forbes PWA demonstrates how media outlets can leverage offline-first strategies to reach and retain a wider audience, regardless of their internet connectivity.

Conclusion

PWAs are changing the game in web development, bringing features we usually see in native apps to the web.

They offer a blend of the accessibility of web applications with the engaging user experience of native apps. They represent a forward-thinking solution for businesses and developers looking to maximize reach and functionality while minimizing costs and complexity.

PWAs aren't just a passing trend – they're the next big thing in how we make and use web apps. By focusing on working offline, PWAs provide a more reliable and user-friendly experience.

Whether you're just curious or ready to start building, the following resources remain great places to begin exploring the possibilities of offline-first web applications.

• Google's PWA Checklist
• MDN Web Docs on Service Workers
• Web.dev for PWA tutorials

Let's say you need to order food – you can do so instantly via the company's app. Maybe you need government services – the same thing applies. You can even get medical emergency dial services via an app.

There's an app for everything – from banking to studying and from trading to shopping. Every business has an app, and even our governments have simplified their services into app form.

Hold on, building and maintaining an app is cumbersome, and it's quite expensive for small businesses, so how do they manage?

Well it's simple: with the help of advancements in technology there is an option that helps small businesses out. This option combines the features of an app with the technology used in web development to build affordable services for businesses – I'm talking about Progressive Web Apps.

Let's dive in and get a better understanding of what PWAs are all about.

What is a Progressive Web App?

Progressive Web Applications (PWAs) are apps built with web technologies that we probably all know and love, like HTML, CSS, and JavaScript. But they have the feel and functionality of an actual native app. Wait a minute! Native Apps, what do we mean by this?

A Native App is a software application built in a specific programming language for a specific device platform, either IOS or Android.
PWAs are built with the capabilities like push notifications and the ability to work offline. They are also built on and enhanced with modern APIs which makes it easy to deliver improved capabilities along with reliability and the ability to install them on any device.

PWAs takes advantage of the huge web ecosystem this is inclusive of the plugins, and community and the relative ease of deploying and keeping a website contrary to a native application which is pretty difficult to develop. This means you can build a PWA quickly and easily.

With its popularity many companies have shifted into the product, I tend to believe that this is because of its ability to run on an android and iOS without much difference. Some good examples of top companies who have their products as PWAs include: Twitter, Pintrest, Uber, Tiktok, Spotify, Jumia (a leading e-commerce site in Africa) etc...

A common feature about this products is that they are all installable on your home screen, able to work offline from where you last left and offer a comparable experience and features to their native apps.

Just like when building a native mobile app there are some expectations that should be met to make a good product for consumer use, the same thing applies to PWAs. Let's discuss what makes a good PWA.

Characteristics of PWAs

Below is what should be considered when developing a PWA:

Responsiveness

Different companies produce gadgets with different screen sizes, and as a developer it's your responsibility to ensure all the different users enjoy the product regardless the device they are using. So it's a good idea to make sure your app can be used on any screen size and it's content is available at any view-port size.

Installable

Research has shown that users tend to engage more with installed apps compared to visiting the official sites. Having a PWA as your product gives the users the look, feel and engagement of a normal app.

Independent Connectivity

By keeping a user engaged to your app even while they are offline, provides a more consistent experience than dropping them back to a default offline page.

A good example to illustrate this will be that of a music app, your users should be able to access offline playback and listen to saved music even without internet connection. Another good example is twitter app, a user is able to go back a read through tweets which they might have missed.

Discoverability

Since most PWAs are converted websites, it is fair to make them discoverable on the search engines, this will help generate extra traffic to your app. This also acts as an advantage over native apps which can't be discovered over the search engines.

Appearance

The appearance of the app should feel and look like that of a normal app, so be sure to include things like an app icon, this will help make it easily recognizable also things like splash screen will add the touch and feel of an app.

Cross Platform

PWAs are developed as web app first, which means that they need to work on all browsers/systems and not just a selected few. Users should be able to use them in any browser before they decide to install them.

So folks! there you have it, the general info about PWAs. Along the way you might have noticed occasionally a comparison between PWAs and Native App and this might have confused you a bit, Well let's clear the airwaves by checking the comparison between the two to get a clear understanding.

Differences Between PWAs and Native Apps

Development Cost

PWAs are cheaper to develop compared to Native AppsWhen you're developing a native app, you'll have to learn a certain programming language and then build a version of the app for each type of device, Android and iOS. On the other hand you can choose to hire a experienced professional to do the work for you which will even turn out to be more costly.

Down the road, you will also need resources to maintain and update the app, which means lots of money and time is required.

In the case of a PWA, you can have a single codebase for the different platforms. It's also time-saving since you will not need to develop it from scratch you can configure your current web site to fit.

And if you choose to hire developer it will only be one compared to native where you can hire up-to two depending on where you need your app.

Discoverability

Native apps cannot be indexed by the search engines, they can just be found through the App/Play store's website. You can make your app more discoverable on the App/Play store by using App Store Optimization(ASO), but that's another story.

Unlike native apps, PWAs work like websites so they can be indexed by search engines. This helps them rank better in search results.

Safety

Nowadays in order to run a website, it should be encrypted with a SSL certificate, this adds an extra layer of security. Now, as we already know PWAs are site converted into app which means they are more secure because they run on HTTPS. These are security protocols that allow safe exchange of data between client and server so that is doesn't get tampered with.

To secure your native apps, you need to implement various security measures, like multi-factor authentication and so on.

Installation and Download

Native apps need to be downloaded and installed from an app store. This requires some commitment from the user to do it from start to finish. Users have to pass and check multiple permissions before installing an app.

On the other hand, PWAs don't require any of those steps. From the browser you can bookmark it and add the app to your home screen with just a few taps.

Benefits of PWAs

A lot of organizations both private and public are switching to PWAs not only because they are cheap to develop but also because they offer greater engagement.
Now let's look at a quick summary of the benefits of a PWA:

• They are responsive and work with many different screen sizes.
• They can run on multiple platforms and any device with a modern web browser.
• They function just like normal Native Apps.
• The updates are independent, you don't need to visit the play store for an update.
• They're built with common web technologies.
• They're fast and lightweight.
• They work offline unlike other sites.
• They are discoverable via search engine.
• They are easily installable.
• Low maintenance cost.

Requirements to Get Started with PWA Development

It does not take much to get started building a PWA. You just need a few things and you are good to go.

Tools
The best known technology stack to develop PWAs is AngularJS. Speaking of Angular, here is a resourceful guide on how you can convert your already existing Angular app into PWA. Others stacks include ReactJS and Polymer.

HTTPS
You will need a server with a HTTPS connection. This makes sure your user's data is secure. It adds an extra layer of security to you site.

Application Shell
It provides a good first impression when your app loads. In simpler words this is what the user sees when they interact with your app for the first time.

Service workers
This is one of the key technologies behind PWAs. They help support your app work offline, and they perform advanced caching and run background tasks. Service workers can complete tasks even when your PWA is not running.Some other functions associated with Service Worker include:

• Sending push notification
• Badging icons
• Running background fetch tasks etc...

Manifest file
This is a JSON file that is created with a Web App Manifest Generator. This file contains the information that tells how your PWA should appear and function. It allows you to determine the name, description, icon, colors and other features of your PWA. Here's an example of a manifest file:

{
"short_name": "DevBlogger",  
"name": "DevBlogger",  
"description": "All dev stories under one roof",
"theme_color": "#eb5252",  
"background_color": "#000000",  
"display": "fullscreen",  
"Scope": "/",  "orientation": "portrait",  
"icons": [    
    {
        "src": "images/android/android-launchericon-48-48.png",      
        "type": "image/png",      
        "sizes": "48x48"
    },
    {      
        "src": "images/android/android-launchericon-96-96.png",
        "type": "image/png",      
        "sizes": "96x96"    
    },    
    {      
        "src": "images/android/android-launchericon-192-192.png",
        "type": "image/png",      
        "sizes": "192x192"    
    }  
   ],  
       "start_url": "index.html?utm_source=homescreen"
  }

• Audit your App
  This is possible using the Google Lighthouse tool. Google Lighthouse is a open-source software that anyone can use on any webpage. Google is a big champion of PWAs and pushes them as the future of the web. You can use Lighthouse to help you see how fast, accessible, and SEO readiness your PWA is.

How to Build a PWA

By following the steps below, you can easily create a fully functional PWA that offers an mazing user experience across all devices.

Step 1 - Plan your app

Before diving into development, you should consider the goals of your PWA, what features you want to include, priorities and user experience. You can create first design concepts and wireframes for the app to visualize the structure and layout.
In most scenarios, this is often referred to as a ‘discovery phase’. You get the opportunity to ideate and gather user and stakeholder feedback as well as considering the functionalities of your to be product.

Step 2 - Designing the User Interface

After getting everything right from planning, you can now proceed to designing the UI of your app. During this stage consider things like responsiveness, compatibility with different platforms etc.. Be sure to capture all details that are crucial to the user including their interaction and engagement during usage.

Step 3 - Developing the Front-End

Using the web technologies that is HTML, CSS, JavaScript and frameworks like Angular. React or Vue.js develop a visually appealing interface for the users. And always remember they key principle in development using this stack implement a mobile first approach while ensuring responsiveness for larger screens too.

Step 4 - Implementing Service Workers

As mentioned previously, service workers are a key component of PWAs. They are JavaScript files that run in the background, enabling offline functionality, push notifications, and caching. To make sure your PWA works to its fullest potential, you’ll need to register and implement a service worker. The way on how you can do this massively depends on which framework you are using.

Step 5 - Adding Push Notifications

Leverage the Push API and service workers to implement push notifications. Obtain the necessary user consent and use a push notification service to send notifications to users.

Step 6 - Optimizing Performance

Optimization is a very important step in development in general. This is how you provide a seamless experience to your users. by ensuring you reduce loading times. by leveraging techniques such as code splitting and caching we should be able to achieve a fast and efficient operation for our PWA.

Step 7 - Testing and Debugging

Test your PWA on different devices, browsers and network condition to be sure that it meets the objective. Also be sure to gather user feedback and make necessary improvements when necessary.

Resources to Get Started with PWA Development

If you want to learn and move with the trend, finding resources to help you might be a bit tedious, to help you get started here are some of the best resources listed for you:
Online Tutorials and Guides

• Google Developers - Progressive Web Apps
• MDN Web Docs - Progressive Web Apps
• freeCodeCamp - Frontend Technologies
• Learn PWA

Documentation and Reference Materials

• Service Workers API Documentation
• Progressive Web Apps (PWAs)

PWA Development Tools

• Workbox - Offline Caching and Service Worker Library
• PWA Builder - PWA Generation Platform

Conclusion

Keeping in mind that PWAs are new to the industry and haven't yet been fully utilized, they can be a great addition to add to your toolkit.

With the latest technologies and the right tools getting started with PWAs can ultimately increase sales and monetary gain for your product either as an individual or organization. With it's many features including they are fast, able to work offline, and also they perform like normal native apps. This offers your users a great experience and keeps them satisfied.

If you have read this far I really appreciate it.

Enjoy Coding ❤.

It's natural to get excited about launching something new, but it's also important to remember the basics of website security. As a developer, you know it’s important to protect your web app from malicious users, attackers, hackers, and other cyber threats.

You've put in a lot of hard work building the perfect user experience and now it's time to keep it secure.

In this tutorial, we'll walk through some simple yet powerful strategies that help you protect your PWA. Let’s get started!

What is a PWA?

PWA Illustration by undraw.co

Are you interested in bringing a native mobile app experience to your users without the headache of app development? Progressive Web App is the way.

PWAs are a type of web application that uses the latest web tech to deliver a user experience similar to that of a native mobile app.

They are built to take advantage of native mobile device features and work for apps regardless of whether the user has poor or no internet connection.

Additionally, PWAs are reliable, fast, and engaging — plus, they’re easier to develop and maintain than traditional apps.

The best part about PWAs is that they offer the same experience on all major browsers like Chrome, Firefox, Edge and Safari — so you don’t have to be concerned about compatibility issues.

Also, since PWAs don’t require installation from an app store, users don’t have to wait for their device manufacturer to approve or update them.

All these factors make PWAs ideal for businesses looking for cost-effective mobile solutions.

How to Secure a PWA

Authentication and Authorization in PWAs

authentication illustration by undraw.co

If you're building a Progressive Web App (PWA), you need to ensure that it is properly secured. In order to do this, you'll need to understand the basics of authentication and authorization.

Authentication is the process by which users prove their identity and verify that they have the proper authorization to access the app.

Authorization, on the other hand, ensures that those users have access only to areas and content that they are allowed to see, while enforcing restrictions on what they can do.

In order to implement effective authentication and authorization within your PWA, there are some best practices you should follow.

1. Firstly, use secure passwords that are difficult for hackers or bots to guess or crack, as well as two-factor authentication (2FA) for added security.
2. Secondly, use roles-based access control (RBAC) for authorization. This establishes user permissions based on roles which can be quickly adjusted when needed.
3. Lastly, use HTTPS with SSL/TLS encryption for all web traffic from your PWA. This will ensure that all data sent between clients and servers is encrypted, protecting user information from malicious actors.

It is important to keep in mind that authentication and authorization can also be vulnerable to attack by malicious users if not implemented correctly. So it is essential to stay aware of common attack vectors like SQL injection threats and cross-site scripting (XSS) attacks.

By implementing proper security measures such as input validation and penetration testing, you can protect your PWA from these threats.

How to Use HTTPS and SSL/TLS to Secure Your PWAs

HTTPs and SSL/TLS are two of the most important tools when it comes to securing PWAs.

Let's see what exactly they are:

What is HTTPS?

HTTPS stands for Hyper Text Transfer Protocol Secure. It's a protocol used for secure communication between a web server and a web browser, and is vital for protecting data from being intercepted by third parties.

To put it simply, HTTPS helps ensure that the data you send and receive from your PWA is always secure.

What is SSL/TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are cryptographic protocols that provide authentication, encryption and data integrity.

These protocols allow secure connections between web browsers, applications, and servers over the internet via an encrypted handshake process.

As such, they play an important role in ensuring that your web app's data remains safe and secure.

Best Practices for Implementing HTTPS and SSL/TLS in PWAs

To protect your PWA effectively, you should make sure that you're following some best practices for implementing HTTPS and SSL/TLS in PWAs:

1. Use HTTPS Everywhere: Make sure that all of your pages are served over HTTPS, rather than insecure HTTP connections. This will help ensure your users' data is protected while they're on your website or application.
2. Install an SSL Certificate: This will enable HTTPs connections on your site and provide authentication between the server hosting your PWA and the users visiting it.
3. Regularly Test Connections: Ensure that all of your connections are still secure by testing them regularly for any vulnerabilities or risks to security
4. Implement Certificate Pinning: Certificate pinning is an important security measure that involves binding a host domain to a specific SSL certificate. This prevents man-in-the-middle attacks and will help protect your PWA from malicious actors.
5. Keep Your Security Protocols Up to Date: Regularly update your web server's security protocols to ensure that you're always running the most secure version.
6. Configure Appropriate Firewall Rules: Configure your firewall rules to allow only secure connections and block any suspicious traffic. This will help protect your PWA from malicious attacks.

Once you've implemented these best practices, you can feel pretty confident that your PWA is as secure as possible.

But, security isn't just about preventing malicious attacks. It's about ensuring that your users' data is always kept safe and secure.

By taking the above steps, you can ensure that your PWA is always compliant with the latest security standards and guidelines. This will help protect your users' data from unauthorized access and potential security threats.

How to Protect against Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF)

Cross-site scripting and cross-site request forgery are both security threats that can cause serious damage to PWAs.

XSS works by injecting malicious code into the browser via a vulnerable web application.

This code can be used to exfiltrate data from the PWA, like passwords or credit card numbers, or to execute any other malicious code.

CSRF, on the other hand, is a form of attack that manipulates a user's browser into sending forged requests without them knowing.

This can be used to execute actions within an application, such as transferring money or deleting data.

Fortunately, there are steps you can take to protect your PWA against XSS and CSRF attacks:

• Sanitize all user input: Sanitizing user input is one of the best ways to protect against XSS and CSRF attacks. Make sure that you always validate and filter out any potentially harmful content before it’s added to your database.
• Use CAPTCHA protection: Adding CAPTCHA protection to web forms will help ensure that any requests from users are coming from real people rather than malicious bots or scripts.
• Use secure cookies: Secure cookies allow you to store data about your users in an encrypted format and limit access only to authorized users. This can help make sure that data isn’t exposed in case of a compromise.

By taking these steps, you can help protect your PWA against XSS and CSRF attacks.

How to Develop a Content Security Policy (CSP)

Content Security Policy (CSP) is an important web security mechanism designed to prevent malicious attacks.

To put it simply, a CSP is a set of rules that specify what sources are allowed when loading resources such as scripts, images, and stylesheets. By defining the sources of these content types, CSP helps protect your applications from cross-site scripting (XSS) and data injection attacks.

By implementing a CSP on your PWA, you can add an extra layer of protection against malicious attacks.

Some best practices for implementing CSP include:

• Defining allowed origins: This makes sure that only authorized sources can access content on your application.
• Whitelisting inline styles: When possible, use the nonce attribute to whitelist specific inline scripts and styles so that the code is only executed if the nonce matches what is specified in the policy.
• Disallowing unsafe methods: Include a directive that blocks dangerous methods such as eval() in order to protect against code injection attacks.
• Setting up reporting/logging: Configure reporting/logging so you can track incoming requests and flag any suspicious activity.

By following these best practices and setting up CSP properly, you can effectively protect your PWAs from malicious attacks while ensuring they remain secure and performant.

Conclusion

In short, if you want to keep your web app secure, it’s important to follow best practice security protocols such as robust authentication and encryption, regular security patch updates, and secure APIs. It's also essential to have a secure development process in place to ensure that only the most secure code is being deployed.

Finally, user education is key when it comes to web apps. Providing users with a secure platform is only half the battle, as ultimately it’s up to the user to stay vigilant about their online security.

Read more on PWAs:

• What is a PWA? Progressive Web Apps for Beginners
• How to build a PWA from scratch with HTML, CSS, and JavaScript

In this article, I'll show you how to build a text translator application using React. It will support 17 languages, and you can do cross translation too.

Here's what we'll create:

This is how our application will look after we're done building it. It has two text area inputs – one will contain our Source Text, and other will contain our Result Text. We also have a select field where the user can choose their desired languages.

So, let's get right into it.

How to Build the UI

In order to create the interface effortlessly, we will use a UI Library called Semantic UI.

So, navigate to Semantic UI's Website at https://react.semantic-ui.com/.

Then, select Get Started from the sidebar menu:

Install it using one of the below commands. You can use yarn add or npm install.

$  yarn add semantic-ui-react semantic-ui-css
## Or
$  npm install semantic-ui-react semantic-ui-css

After it finishes installing, we need to import the package into our index.js file like this:

import 'semantic-ui-css/semantic.min.css'

Now, we can use Semantic UI.

How to Create the App's Components

Let's create a component called Translate. This will contain all the elements that we need.

First, we need an application title heading. So, inside the Translate component, create a heading like this:

import React from 'react';

export default function Translate() {
    return (
        <div>
            <div className="app-header">
                <h2 className="header">Texty Translator</h2>
            </div>
        </div>
    )
}

Now let's add a little styling to it with CSS:

@import url('https://fonts.googleapis.com/css2?family=Azeret+Mono&display=swap');

.app-header{
  text-align: center;
  padding: 20px;
}

.header{
  font-family: 'Azeret Mono', monospace;
  font-size: 30px;
}

Here, we are using a font called Azeret Mono from Google Fonts, and we've aligned the header and given it some padding.

This is how our header will look at this point:

We also need four other elements. First is our input text area, second is the select dropdown to select the language, the third is the output text area where our translated text will be reflected, and the last one is a button which will translate our text.

We can import the Form, TextArea, Button, and Icon elements directly from Semantic UI like this:

import {
    Form,
    TextArea,
    Button,
    Icon
} from 'semantic-ui-react';

Next, we'll create another div after app-header called app-body with the following code:

import React from 'react';
import {
    Form,
    TextArea,
    Button,
    Icon
} from 'semantic-ui-react';

export default function Translate() {
    return (
        <div>
            <div className="app-header">
                <h2 className="header">Texty Translator</h2>
            </div>

            <div className='app-body'>
                <div>
                    <Form>
                        <Form.Field
                            control={TextArea}
                            placeholder='Type Text to Translate..'
                        />

                        <select className="language-select">
                            <option>Please Select Language..</option>
                        </select>

                        <Form.Field
                            control={TextArea}
                            placeholder='Your Result Translation..'
                        />

                        <Button
                            color="orange"
                            size="large"
                        >
                            <Icon name='translate' />
                            Translate</Button>
                    </Form>
                </div>
            </div>
        </div>
    )
}

And we'll add some styling to it with the following CSS:

@import url('https://fonts.googleapis.com/css2?family=Azeret+Mono&display=swap');

.app-header{
  text-align: center;
  padding: 20px;
}

.header{
  font-family: 'Azeret Mono', monospace;
  font-size: 30px;
}

.app-body{
  padding: 20px;
  text-align: center;
}

.language-select{
  height: 40px !important;
  margin-bottom: 15px;
  outline: none !important;
}

This is how our application will look now. You can see that we have the text areas, select options, and a button to translate.

How to Set Up the APIs

To enable translation, we'll use the LibreTranslate API. So, go to their website to choose your API.

As you can see in the image above, it has four API's.

To start, we need to detect our input language using the /detect POST API.

How to Install Axios

But first, let's install Axios, as we'll need to use it to make API requests.

To install Axios, simply type the below command:

yarn add axios

##OR

npm i axios

We can either use yarn add axios or npm i axios, depending on your package manager you installed.

Now, let's import it in our Translate Component.

import axios from 'axios';

We also need the useState and useEffect hooks.

import React, { useState, useEffect } from 'react';

Then, create one state called inputText.

const [inputText, setInputText] = useState('');

And in the input text area field, bind it to an onChange event handler.

<Form.Field
 control={TextArea}
 placeholder='Type Text to Translate..'
 onChange={(e) => setInputText(e.target.value)}
/>

If we enter any text, it will be stored it the inputText state.

How to Call the Language Detect API

Now, let's call the detect language API to detect our input language.

Create a function called getLanguageSource() like this:

const getLanguageSource = () => {
        axios.post(`https://libretranslate.de/detect`, {
            q: inputText
        })
        .then((response) => {
            console.log(response.data[0].language)
        })
    }

Here, we are calling the detect API, and we are passing our input as the body.

We are using axios.post to send the input text as body, and we're using q as the header parameter.

Also, we'll want to call this function on the click of the Translate button, so bind this function to the Translate button like this:

<Button
                            color="orange"
                            size="large"
                            onClick={getLanguageSource}
                        >
                            <Icon name='translate' />
                            Translate</Button>

Type something in the first input box, then press the Translate button. You will see the detected language object key in the console, which we need.

Now, we need to store this language key in a state. So, create a state called detectLanguageKey.

Then, set the state from the response like this:

const getLanguageSource = () => {
        axios.post(`https://libretranslate.de/detect`, {
            q: inputText
        })
            .then((response) => {
                setdetectedLanguageKey(response.data[0].language)
            })
    }

We are setting the zeroth index from the response data, because that's where our data starts.

Here is the whole code up to this point:

import React, { useState, useEffect } from 'react';
import {
    Form,
    TextArea,
    Button,
    Icon
} from 'semantic-ui-react';
import axios from 'axios';

export default function Translate() {
    const [inputText, setInputText] = useState('');
    const [detectLanguageKey, setdetectedLanguageKey] = useState('')
    const getLanguageSource = () => {
        axios.post(`https://libretranslate.de/detect`, {
            q: inputText
        })
            .then((response) => {
                setdetectedLanguageKey(response.data[0].language)
            })
    }

    return (
        <div>
            <div className="app-header">
                <h2 className="header">Texty Translator</h2>
            </div>

            <div className='app-body'>
                <div>
                    <Form>
                        <Form.Field
                            control={TextArea}
                            placeholder='Type Text to Translate..'
                            onChange={(e) => setInputText(e.target.value)}
                        />

                        <select className="language-select">
                            <option>Please Select Language..</option>
                        </select>

                        <Form.Field
                            control={TextArea}
                            placeholder='Your Result Translation..'
                        />

                        <Button
                            color="orange"
                            size="large"
                            onClick={getLanguageSource}
                        >
                            <Icon name='translate' />
                            Translate</Button>
                    </Form>
                </div>
            </div>
        </div>
    )
}

How to Call the Supported Languages API for the Select Dropdown

Now, the second API gets the supported languages. We will use the list in our select dropdown.

Create a useEffect hook to call our supported languages API. useEffect is a function that will run every time our component renders or loads.

useEffect(() => {
        axios.get(`https://libretranslate.de/languages`)
            .then((response) => {
                console.log(response.data)
            })
    }, [])

Here we are calling the API for supported languages using the axios.get method. Then we are consoling the response in the console.

Open up the console to check the languages list. You should see something like this:

Let's set this data into a state. So, create a state called languagesList. It will be an empty array.

const [languagesList, setLanguagesList] = useState([])

useEffect(() => {
        axios.get(`https://libretranslate.de/languages`)
            .then((response) => {
                setLanguagesList(response.data)
            })
    }, [])

Then, in the useEffect Hook, we need to set the languages list using setLanguagesList.

We need to show this languages list in the select option. So, let's map the select dropdown using the languagesList state like this:

<select className="language-select">
                            <option>Please Select Language..</option>
                            {languagesList.map((language) => {
                                return (
                                    <option value={language.code}>
                                        {language.name}
                                    </option>
                                )
                            })}
                        </select>

Now, we can select our language from the select dropdown.

How to Get the Selected Language Code

Now, if we select a language – let's say Spanish – we need to get the language code, as we need that language code in our final Translate API.

Create a function called languageKey() like this:

const languageKey = () => {

}

And on the select option, bind this function using onChange:

<select className="language-select" onChange={languageKey}>
                            <option>Please Select Language..</option>
                            {languagesList.map((language) => {
                                return (
                                    <option value={language.code}>
                                        {language.name}
                                    </option>
                                )
                            })}
                        </select>

Also, we need to store the language code in a state, so let's create it.

Create a state called selectedLanguageKey, which will contain our selected language key from the select input.

const [selectedLanguageKey, setLanguageKey] = useState('')

This languageKey function will accept a parameter called selectedLanguage. And we will store this data in the selectedLanguageKey state, which we are getting from the select option.

const languageKey = (selectedLanguage) => {
        setLanguageKey(selectedLanguage.target.value)
}

Now, if you look at the LibreTranslate documentation, we need three data inputs:

1. The text to translate.
2. The source language code.
3. The target language code.

We don't need the API key because this service is free.

We have all three inputs that we need to send in the body contained in these states below:

const [inputText, setInputText] = useState('');
const [detectLanguageKey, setdetectedLanguageKey] = useState('');
const [selectedLanguageKey, setLanguageKey] = useState('')

Now, let's call our final API, which is /translate.

How to Call the Translate API to Translate our Text

Create one final state called resultText. This state will contain our output translated text.

const [resultText, setResultText] = useState('');

Create a function that will call the translate API:

const translateText = () => {
       getLanguageSource();

        let data = {
            q : inputText,
            source: detectLanguageKey,
            target: selectedLanguageKey
        }
        axios.post(`https://libretranslate.de/translate`, data)
        .then((response) => {
            setResultText(response.data.translatedText)
        })
    }

As you can see, we are setting inputText in the resultText state, and we are calling the getLanguageSource function inside translateText function. So, whenever this function runs, getLanguageSource will trigger them automatically to get the language source.

In other words, onClick of this function via the Translate button, it will set the language source via getLanguageSource(), then it will call the translate API.

So, on the Translate Button, bind this function:

<Button
                            color="orange"
                            size="large"
                            onClick={translateText}
                        >
                            <Icon name='translate' />
                            Translate</Button>

Next let's create an object called data. Inside it we will send all the data we got previously, like inputText, detectLanguageKey, and the selectedLanguage key as q, source, and the target respectively.

let data = {
            q : inputText,
            source: detectLanguageKey,
            target: selectedLanguageKey
        }

Then, we call the translate API using axios.post and send the data object as a body parameter.

let data = {
            q : inputText,
            source: detectLanguageKey,
            target: selectedLanguageKey
        }
        axios.post(`https://libretranslate.de/translate`, data)

Lastly, we set the incoming response data into the resultText state.

.then((response) => {
            setResultText(response.data.translatedText)
        })

So, now type something in the input box, select the language, and click Translate. You will get your translated text.

Here is the whole code up to this point, for your reference:

import React, { useState, useEffect } from 'react';
import {
    Form,
    TextArea,
    Button,
    Icon
} from 'semantic-ui-react';
import axios from 'axios';

export default function Translate() {
    const [inputText, setInputText] = useState('');
    const [detectLanguageKey, setdetectedLanguageKey] = useState('');
    const [selectedLanguageKey, setLanguageKey] = useState('')
    const [languagesList, setLanguagesList] = useState([])
    const [resultText, setResultText] = useState('');
    const getLanguageSource = () => {
        axios.post(`https://libretranslate.de/detect`, {
            q: inputText
        })
            .then((response) => {
                setdetectedLanguageKey(response.data[0].language)
            })
    }
    useEffect(() => {
        axios.get(`https://libretranslate.de/languages`)
            .then((response) => {
                setLanguagesList(response.data)
            })
    }, [])

    const languageKey = (selectedLanguage) => {
        setLanguageKey(selectedLanguage.target.value)
    }

    const translateText = () => {
        getLanguageSource();

        let data = {
            q : inputText,
            source: detectLanguageKey,
            target: selectedLanguageKey
        }
        axios.post(`https://libretranslate.de/translate`, data)
        .then((response) => {
            setResultText(response.data.translatedText)
        })
    }

    return (
        <div>
            <div className="app-header">
                <h2 className="header">Texty Translator</h2>
            </div>

            <div className='app-body'>
                <div>
                    <Form>
                        <Form.Field
                            control={TextArea}
                            placeholder='Type Text to Translate..'
                            onChange={(e) => setInputText(e.target.value)}
                        />

                        <select className="language-select" onChange={languageKey}>
                            <option>Please Select Language..</option>
                            {languagesList.map((language) => {
                                return (
                                    <option value={language.code}>
                                        {language.name}
                                    </option>
                                )
                            })}
                        </select>

                        <Form.Field
                            control={TextArea}
                            placeholder='Your Result Translation..'
                            value={resultText}
                        />

                        <Button
                            color="orange"
                            size="large"
                            onClick={translateText}
                        >
                            <Icon name='translate' />
                            Translate</Button>
                    </Form>
                </div>
            </div>
        </div>
    )
}

Now, the last step. In the useEffect Hook, call the getLanguageSource() function, and set inputText in the dependency array. This means that whenever our inputText text changes, or this state gets updated, the useEffect function will run, and it will call getLanguageSource() every time it runs.

useEffect(() => {
       axios.get(`https://libretranslate.de/languages`)
       .then((response) => {
        setLanguagesList(response.data)
       })

       getLanguageSource()
    }, [inputText])

Now, let's check our output:

Type some text as input, and select the language. Press Translate, and you will see your translated data in the output.

Conclusion

Now you know how to build a Text Translator using React. You can create your own UI if you want.

So go ahead, build and experiment with it a bit. There are tons of things you can do.

You can check out my video on Let's Build a Text Translator Application using React, which is on my YouTube channel.

Feel free to download the code here: https://github.com/nishant-666/Sanjeet-s-Translator. Just please don't mind the name.

Happy Learning.

Progressive web apps are a way to bring that native app feeling to a traditional web app. With PWAs we can enhance our website with mobile app features which increase usability and offer a great user experience.

In this article, we are going to build a PWA from scratch with HTML, CSS, and JavaScript. Here are the topics we'll cover:

• What is a Progressive Web App ?
• Markup
• Styling
• Show data with JavaScript
• Web App Manifest
• What is a Service Worker?
• Cache the assets
• Fetch the assets
• Register the Service Worker
• Final thoughts
• Next steps

So, let's get started with an important question: What the heck is a PWA?

What is a Progressive Web App ?

A Progressive Web App is a web app that delivers an app-like experience to users by using modern web capabilities. In the end, it's just your regular website that runs in a browser with some enhancements. It gives you the ability:

• To install it on a mobile home screen
• To access it when offline
• To access the camera
• To get push notifications
• To do background synchronization

And so much more.

However, to be able to transform our traditional web app to a PWA, we have to adjust it a little bit by adding a web app manifest file and a service worker.

Don't worry about these new terms – we'll cover them below.

First, we have to build our traditional web app. So let's start with the markup.

Markup

The HTML file is relatively simple. We wrap everything in the main tag.

• In index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta http-equiv="X-UA-Compatible" content="ie=edge" />
    <link rel="stylesheet" href="css/style.css" />
    <title>Dev'Coffee PWA</title>
  </head>
  <body>
    <main>
      <nav>
        <h1>Dev'Coffee</h1>
        <ul>
          <li>Home</li>
          <li>About</li>
          <li>Blog</li>
        </ul>
      </nav>
      <div class="container"></div>
    </main>
    <script src="js/app.js"></script>
  </body>
</html>

And create a navigation bar with the nav tag. Then, the div with the class .container will hold our cards that we add later with JavaScript.

Now that we've gotten that out of the way, let's style it with CSS.

Styling

Here, as usual, we start by importing the fonts we need. Then we'll do some resets to prevent the default behavior.

• In css/style.css

@import url("https://fonts.googleapis.com/css?family=Nunito:400,700&display=swap");
* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}
body {
  background: #fdfdfd;
  font-family: "Nunito", sans-serif;
  font-size: 1rem;
}
main {
  max-width: 900px;
  margin: auto;
  padding: 0.5rem;
  text-align: center;
}
nav {
  display: flex;
  justify-content: space-between;
  align-items: center;
}
ul {
  list-style: none;
  display: flex;
}

li {
  margin-right: 1rem;
}
h1 {
  color: #e74c3c;
  margin-bottom: 0.5rem;
}

Then, we limit the main element's maximum width to 900px to make it look good on a large screen.

For the navbar, I want the logo to be at the left and the links at the right. So for the nav tag, after making it a flex container, we use justify-content: space-between; to align them.

• In css/style.css

.container {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr));
  grid-gap: 1rem;
  justify-content: center;
  align-items: center;
  margin: auto;
  padding: 1rem 0;
}
.card {
  display: flex;
  align-items: center;
  flex-direction: column;
  width: 15rem auto;
  height: 15rem;
  background: #fff;
  box-shadow: 0 10px 20px rgba(0, 0, 0, 0.19), 0 6px 6px rgba(0, 0, 0, 0.23);
  border-radius: 10px;
  margin: auto;
  overflow: hidden;
}
.card--avatar {
  width: 100%;
  height: 10rem;
  object-fit: cover;
}
.card--title {
  color: #222;
  font-weight: 700;
  text-transform: capitalize;
  font-size: 1.1rem;
  margin-top: 0.5rem;
}
.card--link {
  text-decoration: none;
  background: #db4938;
  color: #fff;
  padding: 0.3rem 1rem;
  border-radius: 20px;
}

We'll have several cards, so for the container element it will be displayed as a grid. And, with grid-template-columns: repeat(auto-fit, minmax(15rem, 1fr)), we can now make our cards responsive so that they use at least 15rem width if there is enough space (and 1fr if not).

And to make them look nice we double the shadow effect on the .card class and use object-fit: cover on .card--avatar to prevent the image from stretching.

Now it looks much better – but we still don't have data to show.

Let's fix it in the next section

Show data with JavaScript

Notice that I used large images that take some time to load. This will show you in the best way the power of service workers.

As I said earlier, the .container class will hold our cards. Therefore, we need to select it.

• In js/app.js

const container = document.querySelector(".container")
const coffees = [
  { name: "Perspiciatis", image: "images/coffee1.jpg" },
  { name: "Voluptatem", image: "images/coffee2.jpg" },
  { name: "Explicabo", image: "images/coffee3.jpg" },
  { name: "Rchitecto", image: "images/coffee4.jpg" },
  { name: " Beatae", image: "images/coffee5.jpg" },
  { name: " Vitae", image: "images/coffee6.jpg" },
  { name: "Inventore", image: "images/coffee7.jpg" },
  { name: "Veritatis", image: "images/coffee8.jpg" },
  { name: "Accusantium", image: "images/coffee9.jpg" },
]

Then, we create an array of cards with names and images.

• In js/app.js

const showCoffees = () => {
  let output = ""
  coffees.forEach(
    ({ name, image }) =>
      (output += `
              <div class="card">
                <img class="card--avatar" src=${image} />
                <h1 class="card--title">${name}</h1>
                <a class="card--link" href="#">Taste</a>
              </div>
              `)
  )
  container.innerHTML = output
}

document.addEventListener("DOMContentLoaded", showCoffees)

With this code above, we can now loop through the array and show them on the HTML file. And to make everything work, we wait until the DOM (Document Object Model) content finishes loading to run the showCoffees method.

We've done a lot, but for now, we just have a traditional web app. So, let's change that in the next section by introducing some PWA features.

Web App Manifest

The web app manifest is a simple JSON file that informs the browser about your web app. It tells how it should behave when installed on the user's mobile device or desktop. And to show the Add to Home Screen prompt, the web app manifest is required.

Now that we know what a web manifest is, let's create a new file named manifest.json (you have to name it like that) in the root directory. Then add this code block below.

• In manifest.json

{
  "name": "Dev'Coffee",
  "short_name": "DevCoffee",
  "start_url": "index.html",
  "display": "standalone",
  "background_color": "#fdfdfd",
  "theme_color": "#db4938",
  "orientation": "portrait-primary",
  "icons": [
    {
      "src": "/images/icons/icon-72x72.png",
      "type": "image/png", "sizes": "72x72"
    },
    {
      "src": "/images/icons/icon-96x96.png",
      "type": "image/png", "sizes": "96x96"
    },
    {
      "src": "/images/icons/icon-128x128.png",
      "type": "image/png","sizes": "128x128"
    },
    {
      "src": "/images/icons/icon-144x144.png",
      "type": "image/png", "sizes": "144x144"
    },
    {
      "src": "/images/icons/icon-152x152.png",
      "type": "image/png", "sizes": "152x152"
    },
    {
      "src": "/images/icons/icon-192x192.png",
      "type": "image/png", "sizes": "192x192"
    },
    {
      "src": "/images/icons/icon-384x384.png",
      "type": "image/png", "sizes": "384x384"
    },
    {
      "src": "/images/icons/icon-512x512.png",
      "type": "image/png", "sizes": "512x512"
    }
  ]
}

In the end, it's just a JSON file with some mandatory and optional properties.

name: When the browser launches the splash screen, it will be the name displayed on the screen.

short_name: It will be the name displayed underneath your app shortcut on the home screen.

start_url: It will be the page shown to the user when your app is open.

display: It tells the browser how to display the app. There are several modes like minimal-ui, fullscreen, browser etc. Here, we use the standalone mode to hide everything related to the browser.

background_color: When the browser launches the splash screen, it will be the background of the screen.

theme_color: It will be the background color of the status bar when we open the app.

orientation: It tells the browser the orientation to have when displaying the app.

icons: When the browser launches the splash screen, it will be the icon displayed on the screen. Here, I used all sizes to fit any device's preferred icon. But you can just use one or two. It's up to you.

Now that we have a web app manifest, let's add it to the HTML file.

• In index.html (head tag)

<link rel="manifest" href="manifest.json" />
<!-- ios support -->
<link rel="apple-touch-icon" href="images/icons/icon-72x72.png" />
<link rel="apple-touch-icon" href="images/icons/icon-96x96.png" />
<link rel="apple-touch-icon" href="images/icons/icon-128x128.png" />
<link rel="apple-touch-icon" href="images/icons/icon-144x144.png" />
<link rel="apple-touch-icon" href="images/icons/icon-152x152.png" />
<link rel="apple-touch-icon" href="images/icons/icon-192x192.png" />
<link rel="apple-touch-icon" href="images/icons/icon-384x384.png" />
<link rel="apple-touch-icon" href="images/icons/icon-512x512.png" />
<meta name="apple-mobile-web-app-status-bar" content="#db4938" />
<meta name="theme-color" content="#db4938" />

As you can see, we linked our manifest.json file to the head tag. And add some other links which handle the iOS support to show the icons and colorize the status bar with our theme color.

With that, we can now dive into the final part and introduce the service worker.

What is a Service Worker?

Notice that PWAs run only on https because the service worker can access the request and handle it. Therefore security is required.

A service worker is a script that your browser runs in the background in a separate thread. That means it runs in a different place and is completely separate from your web page. That's the reason why it can't manipulate your DOM element.

However, it's super powerful. The service worker can intercept and handle network requests, manage the cache to enable offline support or send push notifications to your users.

S0 let's create our very first service worker in the root folder and name it serviceWorker.js (the name is up to you). But you have to put it in the root so that you don't limit its scope to one folder.

Cache the assets

• In serviceWorker.js

const staticDevCoffee = "dev-coffee-site-v1"
const assets = [
  "/",
  "/index.html",
  "/css/style.css",
  "/js/app.js",
  "/images/coffee1.jpg",
  "/images/coffee2.jpg",
  "/images/coffee3.jpg",
  "/images/coffee4.jpg",
  "/images/coffee5.jpg",
  "/images/coffee6.jpg",
  "/images/coffee7.jpg",
  "/images/coffee8.jpg",
  "/images/coffee9.jpg",
]

self.addEventListener("install", installEvent => {
  installEvent.waitUntil(
    caches.open(staticDevCoffee).then(cache => {
      cache.addAll(assets)
    })
  )
})

This code looks intimidating first but it just JavaScript (so don't worry).

We declare the name of our cache staticDevCoffee and the assets to store in the cache. And to perform that action, we need to attach a listener to self.

self is the service worker itself. It enables us to listen to life cycle events and do something in return.

The service worker has several life cycles, and one of them is the install event. It runs when a service worker is installed. It's triggered as soon as the worker executes, and it's only called once per service worker.

When the install event is fired, we run the callback which gives us access to the event object.

Caching something on the browser can take some time to finish because it's asynchronous.

So to handle it, we need to use waitUntil() which, as you might guess, waits for the action to finish.

Once the cache API is ready, we can run the open() method and create our cache by passing its name as an argument to caches.open(staticDevCoffee).

Then it returns a promise, which helps us store our assets in the cache with cache.addAll(assets).

Hopefully, you're still with me.

Now, we've successfully cached our assets in the browser. And the next time we load the page, the service worker will handle the request and fetch the cache if we are offline.

So, let's fetch our cache.

Fetch the assets

• In serviceWorker.js

self.addEventListener("fetch", fetchEvent => {
  fetchEvent.respondWith(
    caches.match(fetchEvent.request).then(res => {
      return res || fetch(fetchEvent.request)
    })
  )
})

Here, we use the fetch event to, well, get back our data. The callback gives us access to fetchEvent. Then we attach respondWith() to prevent the browser's default response. Instead it returns a promise because the fetch action can take time to finish.

And once the cache ready, we apply the caches.match(fetchEvent.request). It will check if something in the cache matches fetchEvent.request. By the way, fetchEvent.request is just our array of assets.

Then, it returns a promise. And finally, we can return the result if it exists or the initial fetch if not.

Now, our assets can be cached and fetched by the service worker which increases the load time of our images quite a bit.

And most important, it makes our app available in offline mode.

But a service worker alone can't do the job. We need to register it in our project.

Register the Service Worker

• In js/app.js

if ("serviceWorker" in navigator) {
  window.addEventListener("load", function() {
    navigator.serviceWorker
      .register("/serviceWorker.js")
      .then(res => console.log("service worker registered"))
      .catch(err => console.log("service worker not registered", err))
  })
}

Here, we start by checking if the serviceWorker is supported by the current browser (as it's still not supported by all browsers).

Then, we listen to the page load event to register our service worker by passing the name of our file serviceWorker.js to navigator.serviceWorker.register() as a parameter to register our worker.

With this update, we have now transformed our regular web app to a PWA.

Final thoughts

Throughout this article, we have seen how amazing PWAs can be. By adding a web app manifest file and a service worker, it really improves the user experience of our traditional web app. This is because PWAs are fast, secure, reliable, and – most importantly – they support offline mode.

Many frameworks out there now come with a service worker file already set-up for us. But knowing how to implement it with Vanilla JavaScript can help you understand PWAs.

And you can go even further with service workers by caching assets dynamically or limiting the size of your cache and so on.

Thanks for reading this article.

You can check it out live here and the source code is here.

Read more of my articles on my blog

Next steps

Web Manifest Documentation

Service Worker Documentation

Web Manifest Generator

Browser Support

Here the web app install banner is focused on web app, with the feature of add to homescreen.

Browser Support for Add To Homescreen

Add to Homescreen functionality is currently supported by:

• Chrome
• iOS Safari

You can see the latest status of browser support of this feature here.

On Android

On Android, the “add to homescreen” banner comes up automatically if you meet certain requirements. This is what it should look like on Android:

Add to homescreen promptWhen app launched

Requirements

include a manifest.json file with the following properties:

• short name
• name
• 192x192 size of png icon
• start_url
• include a service worker that is both registered and activated
• the website served over HTTPS (you can still try this with localhost without HTTPS)
• the website meets engagement heuristics defined by Chrome

manifest.json

{
  "name": "FreeCodeCamp",
  "short_name": "FreeCodeCamp",
  "theme_color": "#00FF00",
  "background_color": "#00FF00",
  "display": "standalone",
  "Scope": "/",
  "start_url": "/",
  "icons": [
    {
      "src": "assets/images/icons/icon-72x72.png",
      "sizes": "72x72",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-96x96.png",
      "sizes": "96x96",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-128x128.png",
      "sizes": "128x128",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-144x144.png",
      "sizes": "144x144",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-152x152.png",
      "sizes": "152x152",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-384x384.png",
      "sizes": "384x384",
      "type": "image/png"
    },
    {
      "src": "assets/images/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ],
  "splash_pages": null
}

• name is the name of the web app. (It will be shown in the launch screen)
• short name is the short name of the web app. (It will be shown below the icon of phone menu)
• theme_color is the color of the top of the browser.
• background_color is the background color of the launch screen.
• display is the way the web app should display once launched on the phone.
• start_url define the starting url of the website.
• icons is an array that store all the images location, sizes and type.

On other devices

Although this method does not work on iOS and Windows, there is a fallback method.

iOS

On iOS, the “add to homescreen” button must be added manually. Add the following meta tags to the head section of your HTML to support iOS web app icon.

<meta name="apple-mobile-web-app-capable" content="yes">
<meta name="apple-mobile-web-app-status-bar-style" content="green">
<meta name="apple-mobile-web-app-title" content="FreeCodeCamp">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-72x72.png" sizes="72x72">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-96x96.png" sizes="96x96">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-128x128.png" sizes="128x128">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-144x144.png" sizes="144x144">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-152x152.png" sizes="152x152">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-192x192.png" sizes="192x192">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-384x384.png" sizes="384x384">
<link rel="apple-touch-icon" href="/assets/images/icons/icon-512x512.png" sizes="512x512">

Windows

On windows phone, add the following meta tags to the head section of your HTML:

<meta name="msapplication-TileImage" content="/assets/images/icons/icon-144x144.png">
<meta name="msapplication-TileColor" content="green">

So many people own smartphones these days. This opens up endless opportunities for a business - opportunities which, however, are immediately challenged by the immense number of competitors in the mobile software market.

Mobile apps are surely more convenient than web or desktop platforms. Yet, they are not the most comfortable option that the industry offers.

To hit the highest level of user satisfaction and to outrun competitors, inventive people opt in favor of progressive web apps (PWAs) or accelerated mobile pages (AMPs).

What are these things, and how should you choose the best option? Let’s consider each one-by-one by going through these simple questions:

1. What is a PWA?
2. What is an AMP?
3. How are they similar?
4. How are they different?
5. Why PWAs are better than web pages
6. Why PWAs are better than native mobile
7. Why AMPs are better than web pages
8. Why AMPs are NOT better than native mobile

1. What Is a PWA?

A progressive web application, or PWA, unites the advantages of both web and mobile apps into a single software product. As Google declares, PWAs are “user experiences that have the reach of the web and are reliable, fast, and engaging”. It is a technology that lets you use a website as if it was a native app.

Twitter is one of the major companies using PWAs. To install the app, you open the web version on your phone and add it to your home screen. When you open Twitter from the home screen icon, you will be opening it as a progressive web app.

Fundamentals

PWAs are a highly responsive and easily shareable solution, which can work offline. They store HTML and CSS files in the browser cache and archive them with service workers. This makes it possible to use the web page offline. Service workers are one of the three essential components of a PWA, along with the manifest file and a secure protocol HTTPS.

Service workers are JavaScript code components which play the role of a proxy between the network and the browser.

When you open a web page for the first time, service workers store the necessary data in the browser cache. When you open it for the second time, service workers retrieve this data from the cache even before the app checked network availability.

Not only do they provide the ability to work offline but also they greatly boost the response time. Service workers also manage push notifications.

The manifest file is a JSON file containing all the information about your app. For instance, it contains data about the home screen icon of your PWA, its short name, color palette, or theme.

If you are using the Chrome browser on an Android phone, the manifest file will trigger the automatic installation of the PWA onto your phone.

The secure HTTPS protocol is an absolute must if you develop a progressive web app. While service workers make the very concept of a PWA possible, they are vulnerable to network errors or breaches. Service workers can intercept network requests and modify responses. To ensure data security and network security, the secure protocol needs to be used.

Success stories

Twitter is not the only company that has benefited from PWAs. Check out these case studies published by Google to see how this technology helped popular businesses succeed. Among these companies are Pinterest, Alibaba, The Weather Channel, Lancome, and The Home Depot.

2. What Is an AMP?

AMP stands for accelerated mobile page. It's a mobile-friendly web page, which is designed to be loaded instantly. It is a fast and smoothly loading solution which is developed with the user experience in mind. Introduced as an open-source project, the AMP technology was integrated by Google in February 2016.

In 2016, The Guardian announced that their platform was now available as an AMP. To help readers see how it worked, they displayed the same article both as a web version and an AMP version.

There were some differences, but they were insignificant. But what you'd notice right away was how much faster the AMP article loaded compared to the regular web article.

*By comparing this illustration with the one I included earlier, you could notice an interesting point. A PWA needs to be installed. In turn, you do not need to install AMP. It is accessed via a different like.

Fundamentals

The idea of AMPs is to reduce the amount of unnecessary content and functionality so that the app displays essential content immediately. The data can be reduced up to ten times. The three essential components of AMPs are AMP HTML, AMP Components, and the AMP Cache.

AMP HTML is a simplified version of regular HTML. AMP HTML does not allow some tags and elements of HTML (for example, forms). To understand better what AMP HTML should look like, check out the required mark-up.

AMP Components are the scripts that enable you to do without JavaScript. The idea of AMP is to get rid of all JavaScript scripts as make pages load more slowly.

But this does not mean that your page should do without animations, modified layouts, analytics data, autocomplete suggestions, or ads. There is an extensive library of components that enable you to implement these and a lot of other features.

The AMP Cache is a proxy-based content delivery network which fetches and caches page content. AMP Cache enables you as an app owner to easily introduce page updates. It optimizes and, if needed, modifies the AMP.

Success stories

The same as with PWAs, companies are often very proud of the business advantages that AMPs offer. Here is a collection of success stories and case studies of companies that used AMPs and benefited from them. Musement, RCS MediaGroup, CNBC, The Washington Post are all companies that have implemented or plan to implement AMPs.

3. How Are PWAs and AMPs similar?

Both PWAs and AMPs are methods of displaying web pages on mobile devices. Both of them are created to enhance the user experience.

AMPs and PWAs both help reduce page load time. While AMPs may be slightly more effective in terms of loading speed than PWAs, the difference between AMP and PWA loading times is barely noticeable.

Both technologies are actively supported by Google. There is a PWA page on Google Developers and an AMP page on Google Developers as well.

There are not a lot of other similarities, but this primary similarity is essential.

Now let’s see what the differences are.

4. How Are PWAs and AMPs Different?

Appearance

By using a PWA you do not feel like you are using a web page. PWAs look and feel like a mobile app.

By using AMPs, you are well aware that you are using a web page because it looks the same.

Development

In the case of PWAs, the application code is written either from scratch or with some parts of the existing code.

In the case of AMPs, the existing code of a web page is stripped of unnecessary CSS and JS so that the web page loads faster.

User experience

PWAs offer a much better user experience. They have push-notifications, a home screen icon, and no browser tabs. Also, they are much easier to download and lighter in size than a regular mobile app. PWAs load faster than a regular web version because they are embedded with App Shell. And PWAs can be used when the network connection is down.

AMPs offer a slightly improved user experience since the page loads faster than a regular page. Still, this is the only UX advantage that they offer. Unlike PWAs, AMPs cannot work offline.

Performance

From an SEO standpoint, AMP wins the competition. Google favors these pages and lists them in the carousel of top stories, which can increase your click-through rate.

PWAs, in turn, do not have a direct advantage for SEO. However, better user experience translates into higher retention rates, which helps you win with SEO.

Support

PWAs are not supported equally on all devices, so you may find slight inconveniences when they're displayed on iOS. Also, they do not support all the hardware functionalities, such as Bluetooth, NFC, GPS, or accelerometers.

AMPs are supported by all major browsers on all devices.

Apps they're best suited for

PWAs work perfectly for apps that require user interactions. E-commerce websites, social media, or online learning platforms where the app needs to be responsive and constantly updated can make use of this technology. This is why Twitter uses a PWA, for example.

AMPs are more suitable for platforms with a wall of content, such as online magazines or newspapers. AMPs load content instantly, but the interaction opportunities are limited. This is why The Guardian decided to employ AMPs.

5. Why PWAs Are Better Than Web Pages

If you access a web page on mobile, you will have to deal with browser tabs, slow loading times, and annoying pop-ups. If your device has a relatively small screen or a slow network connection, surfing the web on it becomes unbearable.

This problem is solved by progressive web apps. In a few clicks, you install the app on your phone and get down to using it. No need to type a link, no browser tabs, and no pop-up screens. The app works fast, and it does work if the network connection is down.

Alright, the benefits of this solution are evident, but it seems like native mobile apps could work perfectly instead. No, they would not. Let’s see why PWAs are better than native mobile apps.

6. Why PWAs Are Better Than Native Mobile Apps

To use a native mobile application, you have to find it in the App Store or Google Play catalogs. Then, you have to wait for some time to download it. You might not have enough free space on your device, so you'll need to find some room.

In turn, PWAs are installed and ready to use in seconds. The file size is small (although it's bound to increase while you are using the app and it is caching). Still, the size of the cached data depends on the amount of free storage you have on your device.

As you can see, PWAs seem better than a web or native mobile app. But you should understand that this solution is not universal. Check out my recent article on PWA vs Native to learn when a native app is a better choice than a PWA.

7. Why AMPs Are Better Than Web Pages

As mentioned above, web apps are slow and inconvenient, especially when accessed on mobile devices with small screen size or underpowered hardware.

By getting rid of all the web components that are unnecessary for a good user experience, accelerated mobile pages solve this problem. AMPs perform 4 times faster and use 10 times less data than regular web pages.

8. Why AMPs Are NOT Better Than Native Mobile

Unfortunately, AMPs cannot be a complete substitute for native mobile apps. They cannot be installed on the home screen, they still include browser tabs, and their functionality is limited to some basic stuff.

But for an online newspaper or for an informational website, such as WebMD, it is better to use AMPs rather than a native mobile app. These do not require any additional functionality for displaying page content.

To Wrap Up

Both AMPs and PWAs are powerful technologies. To sum up the results of our initial question - PWAs vs AMPs:

• AMPs will be easier, faster, and cheaper for you to develop
• PWA will offer more benefits.

Just remember - neither of them is a universal solution, and neither is a panacea. Even using AMPs and PWAs together may not meet all your demands. Sometimes you may need to choose more conventional types of software.

If you are still not sure what to choose, our specialists share four questions to understand if you need PWA. In short: We believe that progressive web apps are the future. Accelerated mobile pages are just too simple and limited in functionality to compete.

Do you have an idea for a project?

My company KeenEthics is experienced in both AMP and progressive web app development. If you are ready to change the game and start your project, feel free to get in touch.

P.S.

The original article posted on KeenEthics blog can be found here: PWA vs AMP: What Is the Difference and How Do You Choose?

My inbox has been filled with questions regarding PWAs after my last two articles.

My “Practical Tips on Progressive Web App Development” shared the actual advantages of the PWA technology, and my “Progressive Web Apps vs Native” further strengthened many people's belief that a progressive web app is exactly what they need.

I am exceptionally happy that I managed to convince them that PWAs are the future of web apps. I support the PWA technology as a path that the software development industry should take in the future. But progressive web apps are not a panacea, not a one-size-fits-all solution.

Since I have already explained what PWA means and why you need a PWA, today, I am going to finish the job and show why you may NOT need a PWA.

Making the choice between using and not using PWA is easier than you assume. Just answer four simple questions and you will see the right path yourself.

1. Do you have any ready-made developments?

The speed and simplicity of the progressive web app development have been mentioned among the major benefits of PWAs. However, this advantage can be negated by the fact that you already have some ready-made developments for a mobile app.

Converting a ready-made mobile app to a progressive web app cannot be done with a few simple clicks. Instead, a progressive web app has to be developed from scratch. If you had already gone through the lengthy and complicated process of native app development, why would you throw it out and start everything from the beginning?

Surely, your mobile app can be outdated or inefficient. In this case, you have to choose whether to revive it with the help of a mobile app development company or to build an entirely new application using the PWA technology.

For instance, Pinterest – one of the brightest examples of companies that implemented PWA – decided to choose both options. They have developed a progressive web app but did not forget about the traditional mobile application either.

Key idea: The PWA approach is a great solution if you have no ready-made developments. If you already have a native or cross-platform mobile version of your app, it will be easier and more productive to finish those rather than build a new application from scratch.

2. Do you plan to focus on mobile devices only?

The idea of PWA features is to improve the experience of a user accessing a web page from a mobile device. Until the PWA technology was introduced, the businesses willing to target both web and mobile had two options:

• to adapt a web page to mobile devices
• to develop a mobile app from scratch

The first option is clumsy and inconvenient from the perspective of a user. The second option is resource-consuming from the perspective of a business.

The advancement of PWAs brought the Golden Mean: convenience for the user and efficiency for the business. If you do not plan to enter the web or desktop niche but choose to focus solely on mobile apps, there is no need to build a PWA.

Surely, when developing progressive web apps, you win because you're developing one application for both Android and iOS. However, this is exactly what you can achieve with cross-platform development with Ionic, Cordova, or React Native.

Meanwhile, Pinterest has developed a progressive web app to augment their already existent web platform and mobile app.

Key idea: PWAs work best for the businesses targeting both web and mobile platforms. If you choose to focus on only one of those, there is no reason to choose progressive web app development.

3. Are you reluctant to let your users access the app via a web browser?

Another essential difference between mobile apps and progressive web apps rests in the fact that the former are downloaded from the store, while the latter – via a shared link or directly from a website as it is illustrated below.

Tastes differ. If you think that working with App Store or Google Play is easier than fighting the SEO competition on Google or inspiring users to share your links, you should feel free to choose mobile app development.

If you think that it is more difficult to be featured in top search results in Stores comparing to Google search results, go with PWA. Besides, if your website already has a sufficiently large target audience of devoted users, progressive web apps would work best for you.

Key idea: If you want your users to access the application via the App Store or Google Play rather than through a browser, or if app store optimization (ASO) sounds simpler than search engine optimization (SEO), you should go with a mobile app.

4. Do you need advanced mobile device features?

While PWAs can work with geolocation, a lot of advanced mobile device features remain beyond their reach. Progressive web apps do not work with proximity sensors, advanced camera controls, audio or video recording, fingerprint scanning, NFC, or even Bluetooth.

Ask your development team for the PWA checklist of features that they will not be able to implement. If you cannot do without at least one of these features, you should opt in favor of mobile development.

For instance, the progressive web app of Pinterest does not feature the function of taking photos, which is present in their mobile app.

Key idea: Incompatibility with native device features can hinder you from developing a PWA. While this issue may be solved in the future, for now, you should go with mobile apps instead.

To Wrap Up

Before asking for a PWA, you need to decide whether you really need the PWA approach. Start by answering four simple questions:

1. Do you have any ready-made developments, such as a native mobile app?
2. Do you want to focus on mobile devices only? No desktop or web platforms?
3. Are you reluctant to let your users access the app via a web browser?
4. Do you need advanced mobile device features? Are you going to use fingerprint scanning, NFC, or Bluetooth?

If you answer "yes" to the majority of these questions about progressive web apps, then, probably, you do not need a progressive web app. A mobile app will fully cover all your needs.

Do you have an idea for a PWA?

My company KeenEthics is an experienced progressive web app development company. In case you need the following services, feel free to get in touch.

You can read more of my articles on the KeenEthics blog: Four Questions to Understand If You Need PWA.

P.S.

Also, I would like to say "thank you" to Tetiana Matviiok for helping me edit this article.

The original article posted on KeenEthics blog can be found here: Progressive Web Apps vs Native: Which to Choose and When?.

In this article, I’ll take you on a tour of what a PWA is, what components it is built from, and show you how you can make one on your own.

The Basics

A progressive web application is a website turned into an application. What this means is, that instead of having to code either in Java or Objective-C (or more recent mobile coding languages), you can write the code for the application, like you would for a website. You have your html files, your stylesheets, and your scripts.

Why would you build a PWA instead of a native application? For starters, imagine that once you release a PWA, you can change it constantly without having to republish your application. Since all the code is hosted on a server and not part of the APK/IPA, any change you make happens in real time.

If you have ever used an application that relies on a network connection, you are familiar with the frustration of not being able to do anything. With PWAs, you have the ability to offer an offline experience to your users in case of network issues.

And to add the cherry on top, there is an ability to prompt the user to add your PWA to their home screen. Something that native applications do not possess.

Components

There is a standard regarding a PWA, and you must adhere to it if you want to publish one. Each PWA is built from the following components:

• A web app manifest
• A service worker
• Install experience
• HTTPS
• Creating an APK
• Lighthouse audit

The Manifest

This is purely a configuration file (.JSON), enabling you to change various settings of your PWA and how it will appear to the user. Below is an example of one:

You must set either a name/short name key. When setting both, short name will be used on the home screen and the launcher. The name value will be used in the Add to Home Screen experience (or, application install prompt).

Display can have four different values:

• fullscreen - this allows your application to take up the whole screen when it is opened
• standalone - your application looks like a native application, hiding browser elements
• minimal-ui - provides some browsing controls (only supported for Chrome mobile)
• browser - like the name says your application’s look will be identical to a browsing experience

You can also set the orientation of your application and the scope of the pages considered to be within your application.

Don’t forget to add the manifest to your main html file by putting the following meta tag inside of your head tag:

_Photo by [Unsplash](https://unsplash.com/@solimonster?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">sol on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

The Service Worker

A service worker is a component running in the background of your website on the browser. It has a wide set of functionalities including, push notifications, caching assets and providing them for an offline experience and the ability to defer actions until the user has a stable connection to the internet. A service worker can be a whole Medium article on its own, so I won’t delve into the inner details of how it works. But, I will supply a vanilla example of one for you to use in your PWA.

It is customary to save the code related to the service worker in a file called sw.js.

✋ The location of the service worker is important since it can only access files that are in the same directory or subdirectory as itself.

A service worker has a lifecycle that can be summed up to the following phases:

• Registration
• Installation/Activation
• Responding to various events

Install Experience

One of the unique features of a PWA is its install experience. What this translates to is prompting the user to install your application. To allow us to present this ability to the user, we will need to listen in on an event called beforeinstallprompt. Below is a code sample demonstrating the flow from presenting the user with the option to add the application to activating logic based on their choice.

_Photo by [Unsplash](https://unsplash.com/@jamessutton_photography?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">James Sutton on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

HTTPS

Not too long ago, websites could still use the all too common http protocol. Due to recent changes in security and in Chrome, all websites that do not operate under the https protocol will be marked as not secured. Even if your website does not handle user data or sensitive communication, it is still good practice to switch over to https.

And like I mentioned earlier, if you want to be able to release a PWA, it has to use the https protocol. If you don’t want to get into the hassle of acquiring a domain, finding a proper host for it and then enabling SSL, you can go for the easy option of Github. If you have an account, you can open a repository and set up a GitHub Page. This process is fairly simple and straightforward and the bonus is getting the HTTPS built in as part of Github.

Creating An APK

In order for our PWA to be available inside the Google Play Store, we need to create an APK. You can use the popular tool, PWA2APK, which will do the hard work for you. But if you prefer to learn how to do it yourself, keep reading.

Google has introduced a new way to integrate your PWA into the Play store using what is called a Trusted Web Activity, or TWA. With just a few simple steps you will learn how to create a TWA, which you can then upload to the Play store.

1. Open Android Studio and create an empty activity

2. Go to the project’s build.gradle file and add the jitpack repository

3. Go to the module level build.gradle file and add the following lines to enable Java8 compatibility

4. Add the TWA support library as a dependency

5. Add the activity XML inside your AndroidManifest file between the application tags

6. We need to create an association from the application to the website using a digital assets link. Paste the following inside your strings.xml file

7. Add the next meta tag as a child to your application tag inside the AndroidManifest.xml

8. Create an upload key and keystore

9. Use the following command to extract the SHA-256

10. Go to the assets link generator, supply the SHA-256 fingerprint, the package of your application and the web site's domain

11. Place the result in a file named assetlinks.json under the location /.well-known in your website’s directory. Chrome will look for this destination specifically.

12. Generate a signed APK and upload to the Play store

_Photo by [Unsplash](https://unsplash.com/@aaronburden?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Aaron Burden on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

Lighthouse

By now, I am sure you have already lost track of what is required from your PWA so it will be valid for publishing. There are so many things to take into consideration, that it is easy to lose track of what the requirements are.

Luckily for us, Google has created Lighthouse. It can be found in the Chrome Developer Tools (from Chrome version 60). It can be accessed easily by right-clicking inside the browser and selecting inspect. When the new pane opens, you will see an Audits tab at the far right corner.

The Audits Tab

Leaving the settings in this tab as they are, you can now run an audit by clicking on the “Run audits” button. This will take a minute or two, but by the end of it, you will receive an informative, graphical presentation of where your PWA ranks in respect to three properties:

• Performance
• Accessibility
• Best Practices

Each property has a breakdown of where your application passed the requirements and where it didn’t. This lets you see where you need to make adjustments and where you are meeting the standard. If you are interested, you can find a breakdown of the checklist here.

PWA it up

We are at our journey’s end and hopefully you are feeling better prepared to navigate the world of PWAs. This article was inspired by the process I went through when creating one recently. You can check it out below:

Android Menu XML Generator - Apps on Google Play
_Generate any type of menu you need for your Android application. Choose from an Options, Context or Popup menu and…_play.google.com

In this tutorial, we’re going to build up the fundamentals of Progressive Web Applications (PWAs). I’ll help you understand the pain points of the traditional web and the need for something better to combat native applications. We’ll dive deeper into the components that make up a PWA — Service Workers, IndexedDB, manifest.json & Web Push Notifications. And the most interesting bit — we’ll build a PWA from scratch.

How I Got the Idea to Write This Tutorial

I was having dinner with my entire family, and a notification for a new text message popped up on my mobile phone. The message confirmed that I received a new paycheck. While this is regular news, my family gets delighted every time this happens.

Taking advantage of the pleasant environment, my brother exclaimed that he wants a new mobile phone. When I asked him why did he need one, he said that his phone has become very slow and gets low memory warnings every now and then. I was surprised to hear this as his phone is more advanced than mine which is still working perfectly fine.

To satisfy my curiosity, I checked his phone and found that he has installed more than 40 applications for his diverse needs. ?‍♀️ There were two applications for reading blogs on different categories, two of them were for getting news updates, three of them were E-Commerce apps, three for gaming, one for keeping an eye on his mutual funds and another one for handling his bank account transactions and there were a few more that he didn’t use frequently.

I asked him if he has ever tried going to the respective website before taking a bold step of installing the native application. He kept aside his piece of pizza and turned towards me in a mood of having a detailed conversation.

He began by saying that he has always visited a website first and it’s the website that forces him to download the native application by showing fat install banners. He says the experience on the web is so frustrating that it is impossible to get through even a simple task.

His E-Commerce applications are really great at giving him timely updates on his orders and do an amazing job of informing him of discounts by sending push-notifications. The user experience on native applications is simply amazing and the web can’t beat that. He was stern in his opinion about the web. However, he agreed that the size of the native application bloats his phone memory but he cannot do anything in that regard.

Misconceptions People Have About the Web

My brother thinks exactly what most users think about the web. The traditional web is slow and ugly. Let’s take a moment and check out Twitter on the mobile web, popularly called Twitter Lite, and understand the significance of the word traditional in my last statement.

Is the experience on par with the native app? It loads instantly. There is no janky scrolling. It doesn’t look like an old traditional website. You might’ve noticed a small banner at the bottom asking you to Add Twitter to your home screen. Is it the fancier way of urging users to install native applications? No, it isn’t. It won’t download a native application of megabytes in size. It is asking you to add Twitter Lite on your home screen. It literally means adding a shortcut to access twitter mobile web using that icon on the home screen.

Let’s experiment with this by clicking on Add Twitter to home screen and check out what the newer web has to offer. In case the banner didn’t appear in your case, please click on the three dots on the right side and choose option Add to home screen. Now, click on the twitter icon from your home screen. Isn’t that amazing? Oh yes, this app can also send you real-time push notifications. The web won’t feel like a lost world now. Once you opt-in for push notifications on a web application, it does a great job of engaging users by showing them all the updates.

There is one more important thing that is lacking in traditional old web — the ability to deal with intermittent or no internet connection. The Web behaves quite differently on 2G devices compared to on WIFI. Most of the times, it’s nothing or a loader on the screen while browsing on a 2G connection. This is frustrating to the end user.

The good news is, the modern web can deal with this problem too. You don’t see the dinosaur when your internet goes off. It’s a nice application shell that pops up when you are not connected to the internet. I really like the way Trivago deals with this problem, they show a nice application shell to play around an offline maze.

Let’s check out one more application of this kind — Financial Times. Load Financial Times in your browser and now switch off your internet. Reload the page. The experience is still the same. Isn’t this something that makes the web look great? These web applications that solve the pain points of the traditional web are popularly called Progressive Web Applications.

In this tutorial, we’re going to explore Progressive Web Applications and also build one from scratch.

Benefits of Progressive Web Applications

Progressive Web Applications (PWAs) are:

Fast

They make good use of local caches to store static assets. Caching of static assets reduces the number of rides to the server to fetch these assets on every load. This makes for an incredible user experience similar to that of native applications. They respond quickly to user interactions.

Reliable

PWAs load data almost instantly. Every fetch network request from the application goes through Service Workers (more on that later). They operate the cache (IndexedDB or any other local cache). Service Workers can send the response to a network request directly from the cache in case of intermittent or slow internet connections. PWAs work reliably even on 2G connections.

Engaging

Native applications leverage the power of operating systems to show important notifications to the users and this is one of the powerful features of an application. Sending timely push notifications helps to retain users for a longer duration. PWAs make use of web push notifications to inform users of relevant updates.

Progressive Web Applications is used as terminology for web applications that are fast, reliable and engaging and they provide an experience similar to that of native applications. Applications that are eligible to be called Progressive Web Applications consists of and employ the following:

Service Workers

Service Workers, in simple terms, are a few lines of JavaScript code that keep running in the background. However, they go to a dormant state when they are not in use. They operate as an event-driven system. Whenever a particular event (for example, a fetch request to the server) is invoked, service workers come to life.

We can handle the response of the fetch event using the fetch event listener in the Service Worker. For a service worker to start doing its work of handling fetch requests and a few other events, it should be registered, installed and activated on a web application.

IndexedDB or any other local cache

PWAs store the static assets like JavaScript files, stylesheets, and images in the local cache for subsequent visits. Some of the PWAs make use of IndexedDB, which is basically a structured key-value pair data structure. IndexedDB is used for storing large amounts of data as compared to other client-side storage options.

We saw earlier the way Financial Times handles the no internet condition. It still displays all the articles on the home page. It makes use of IndexedDB to store data from these articles.

Let’s see this in action. You’ll find IndexedDB in the Chrome DevTools under Applications tab. Under IndexedDB, go to the Articles section.

Web Push Notifications

Service Workers also listen to a push event and have a respective push event handler that takes care of showing the push notification to the user. An application must have the user’s permission in order to show them push notifications. Once a user opts-in for receiving push notifications, the browser generates a unique token for them. The server can then communicate with the user using this unique token.

manifest.json File

manifest.json is typically a metadata file of an application. An application includes the manifest.json in index.html as follows

<link rel="manifest" href="manifest.json">

manifest.json does the job of telling the browser that the application is a PWA. It tells the browser the Name, Background Color, Theme Color, and Icons to be used for this application. It also tells the mode in which the application should be opened. For example, a standalone mode launches a PWA by giving a feel similar to that of a native application.

Rich User Experience

PWAs are known to have a rich user experience. They access the static assets directly from the cache so there is no delay in responding to user interactions.

Let’s build a Progressive Web Application by making use of the components listed above.

Use Case — Building a Treasure Trove of Books

We will be building an application called BooksKeep. It will help in maintaining a systematic record of the books we’ve read and also the ones that are in our pipeline. No wise word learned should go in vain.

The following features will be incorporated in this application:

1. Displaying a list of books (Title, Author, Summary, & Favorite Quotes)
2. Adding a new book to the list

Prerequisites — Our Technology Stack

• React — for building the front-end
• IndexedDB — for storing the books records (please note, there is no back-end database)
• WebPack — as a development server and for bundling assets

Let get going! To make things simple, I’ve created a boilerplate to get started with.

Understanding the Boilerplate

package.json - package.json contains the project dependencies. When you do npm install, these dependencies will be downloaded in your system. Since we're using React to build up our front-end, react & react-dom libraries are included in the dependencies section.

In devDependencies object, babel presets and few webpack related plugins are included. Babel is a JavaScript compiler that is used for syntax transformation, converting the next-gen JavaScript into a browser compatible version.

The browser doesn't understand the React syntax directly, so we're using babel-preset-react to convert React and JSX into JavaScript that the browser understands. We're using WebPack as a module bundler.

webpack.config.js contains the configuration setup required for generating a bundle of static assets. The entry object in module.exports contains the entry point of the application, which in our case is app.js. Webpack generates a dependency graph using this entry point and keeps adding dependencies in the bundle starting from app.js. The output object contains the path of the output folder and filename generates dynamic filenames based on their value in the entry object. In our case, it will be bundle.js as we've mentioned bundle in the entry point.

Next, there are some rules to convert .js & .scss specific files. These files are to be transformed with their respective loaders before adding them to the main bundle.

• HTMLWebpackPlugin adds the generated output bundles in the provided index.html template.
• ExtractTextPlugin moves the .css modules into a separate file.
• CopyWebpackPlugin simply copies the manifest.json file and service-worker.js file from src to dist.

We will be building up src along this tutorial. For now, it contains index.html that has one div element with id app. app.js is the root component of the application. It contains simple header & body components for now.

Let’s start building our BooksKeep PWA. We will be building this progressively in the following steps:

1. Building a table component for displaying book records
2. Provision to add a new book in the table
3. Storing book records in IndexedDB
4. Adding Service Worker to cache static assets
5. Adding manifest.json

Building a Table Component for Displaying Book Records

We’re using react-bootstrap for building the UI. Let's import the Table component from react-bootstrap.

Start the server by using the command npm start in your terminal. Head over to localhost:8080/dist/. We don't have any book records yet so the table is empty. BooksHeaders are being imported from the constants folder. Please add BooksHeaders in books-headers.js file in the constants folder from here.

BooksHeaders is simply an array of objects that we're displaying in the table. getTableMarkup function builds up the table headers with getTableHeaders & body with getTableData functions. booksData maintains the state of the component. If any new book record is to be added, it should be pushed into booksData array.

Provision to Add a New Book in the Table

Let’s take it further and add our first book record in the table. All we have to add is to import the BookForm component from the base folder and provide it a onSubmit prop. onSubmit prop accepts a function that will be called when the user clicks on the submit button in the form, and that will give us the details of the new book. Once you're done with that, your Body Component should look like this.

Here’s the BookForm component:

FieldGroup is just a wrapper for labeled inputs. Please put this inside the field-group.js file in the utils folder. BookForm component maintains its state in the formData object. Whenever a user enters name, author or summary, it gets saved in the component state. The submit button passes the component state to the parent Body component, which then adds it to its state - booksData array.

After adding a book record, you'll see that your table is now populated with that record. But when you refresh the page, all of this is gone. We've got to fix this.

Storing Book Records in IndexedDB

IndexedDB is a structured client-side storage database. The records in IndexedDB are stored as key-value pairs. We’ll be saving the book records in IndexedDB. IndexedDB provides APIs for adding, deleting and updating the records in a database. Let’s explore these APIs by creating a wrapper in the indexeddb.js file in the utils folder.

Operations performed on IndexedDB are asynchronous in nature. So, the IndexedDB APIs provide appropriate hooks for success and error events.

First, we’ll have to create our database. Let’s write a initialize function that will handle the initialization tasks:

In the above code snippet, BooksKeep is the name of the IndexedDB database and books is an ObjectStore. ObjectStore is analogous to a table in SQL. The statement idb.open(DB, 1) is an asynchronous request to open IndexedDB database BooksKeep, and the second parameter 1 signifies the version of the database. The request variable is of type [IDBOpenDBRequest](https://developer.mozilla.org/en-US/docs/Web/API/IDBOpenDBRequest).

We've defined onsuccess, onerror and onupgradeneeded functions on the request object to be called at the respective events. For example, onsuccess callback would be called when the database is opened successfully and in onsuccess method, we're caching the instance of the BooksKeep database. onupgradeneeded method is invoked whenever there is a change in the version of the database.

Currently, with version 1, we've added only one ObjectStore called as books. Let's say, at a later stage, when our application grows we decide to add one more ObjectStore. We'll have to upgrade the version of our database to 2 and add the schema of this new ObjectStore in onupgradeneeded method.

We will be writing three important methods — get, update & delete — in our IndexedDB wrapper. The general idea for performing any of these operations is to first get the instance of the store, wrap the operation in a transaction, and then write success and error event handlers for the respective asynchronous requests. A transaction is simply a wrapper around an operation to ensure data integrity. If any of the actions in a transaction fails, then no action is performed on the database.

For example, our put or update method will look something like this:

update method takes three parameters:

type is the name of the objectStore, data is the book record that we intend to add/update in our objectStore, and callback is of type function that would be called after successfully adding data in the objectStore.

transaction is defined on the [IDBOpenDBRequest](https://developer.mozilla.org/en-US/docs/Web/API/IDBOpenDBRequest) instance and it takes the name of the objectStore and the mode with which the operation is to be performed. In this case, the mode is readwrite since we're writing to the objectStore.

As mentioned previously, IndexedDB accepts data in the form of key-value pairs. We're using timestamp to generate a unique identifier for a particular record. store.put(data) asynchronously adds book records into the books objectStore. On the same lines, I've added get & delete methods in our wrapper. Please check the complete code of IndexedDB wrapper here.

Now that our IndexedDB wrapper is all set, it’s time to use the add/update function from our wrapper whenever a user tries to add a new book record. Let’s modify our Body Component to accommodate these changes.

First import IndexedDbWrapper in the Body component. We will be calling the initialize function of IndexedDbWrapper in componentDidMount. The initialize method takes the callback as initializeDB function, which is defined in the Body Component. initializeDB does the work of setting up the initial state of our application by fetching the stored books records from IndexedDB.

One last thing to do with IndexedDbWrapper is to call its update method on submission of a book record. We've to modify the onSubmit method of the Body component as follows:

Now, the new record will be first added to IndexedDB, and once that is done successfully, we’re updating the state of the component. Try adding a new book record and reloading the page. You will still see your book record in the table. Here’s where it is coming from!

Let’s add one record and refresh the page. Data is preserved and that’s exactly what we wanted. We’ve built up a means to fetch data directly on the client-side. We’re getting closer to our goal of building a Progressive Web Application.

Adding Service Worker to Cache Static Assets

The next step is to leverage the power of Service Workers by fetching static assets from the cache. A service worker first has to be registered on a web page.

Service Worker Registration

initializeSW function is defined in the Body component, and we'll call it in componentDidMount lifecycle hook. serviceWorker is defined on navigator. According to MDN,

the Navigator interface represents the state and the identity of the user agent. It allows scripts to query it and to register themselves to carry on some activities.

A Service Worker is registered using the register method defined on navigator.serviceWorker object. The register method takes the URL of the service worker file. It returns a Promise which resolves when the service worker is registered successfully on the webpage. Once this is done, you'll see a success message in the console. By default, service workers can intercept all the fetch requests coming from the web page.

register method also takes an optional second parameter, which defines the scope of the service worker.

navigator.serviceWorker.register('./service-worker.js', { scope: '/products' })

The above service worker will intercept only /products/* requests. So, something like /payments is not intercepted by the above service worker.

As said earlier, Service Workers operate as an event-driven system. After successful registration, an install event is triggered. We can make use of the install event handler for initialization tasks. In our case, we will be setting up our cache for storing static assets.

Here’s the install event handler:

event.waitUntil makes sure that the service worker is active while the URLS are getting added into the cache.

The service worker hasn’t yet started doing its magic. After getting installed successfully, an activate event is triggered and this is a good place to clear off old unused caches. Let's do our bit:

activate event handler takes care of deleting all the caches except bookskeep-cache. When a web page makes a network request to the server, the fetch event of the service worker is triggered. So, if we were to manipulate or modify the response to be sent for a particular request, we'll have to do this in the fetch event handler.

event.respondWith method lets us send a modified response back to the client. It returns a Promise that resolves to a valid response. cache.match checks if the request is a valid resource for caching (if you remember, we've added a few specific URLs to urlsToCache variable in the install event handler).

If the response to that request is present in the cache, we send it directly to the client otherwise, we request that resource from the server, put it into the cache for subsequent hits, and send it to the client.

Here’s the service worker file with the three event handlers explained above.

Adding manifest.json

short_name is used on the home screen as the name of the application. In case short_name is not provided, then the name property is used in its place. icons show up as a home screen icon for the application in the app launcher and on the splash screen. start_url tells the browser about the starting page of the app. A user will be directed to this URL when the app is launched. standalone as the display property of the app gives it the look & feel of a native application. The application runs in its own window and hides some of the browser specific elements like URL bar. background_color sets the color of the splash screen when the application is first launched and theme_color tells about the color of the toolbar.

This is it. We’ve set up our BooksKeep PWA. Let’s have a quick recap of the things we learned in this tutorial:

1. The traditional web lacks some of the important features that native applications provide out of the box. Progressive Web Applications help in improving the user experience on the web tremendously. They are fast, reliable, and engaging and provide an experience similar to that of native applications.
2. PWAs make use of Service Workers, IndexedDB (or any other local cache), manifest.json, and Web Push Notifications.
3. Service Workers operate as an event-driven system and listen for fetch & push events. fetch event lets us send the response to a network request directly from the cache in case of slow or intermittent connections. push event lets us show push-notifications to the user and helps in engaging user by apprising them of timely updates.
4. IndexedDB is a key-value structure. It helps in storing a massive amount of data on the client-side. manifest.json informs the browser about some of the important properties of an application.
5. We learned how to get started building a Progressive Web Application.

This was a quick introduction to Progressive Web Applications. If you want to explore more, here are some of the resources:

1. An Extensive Guide To Progressive Web Applications
2. Check out my BooksKeep application on GitHub. I’ve added a few more features like updating book records, adding quotes & support for web push notifications. I’ll keep adding more!
3. Service Workers

Please let me know if you found this tutorial to be helpful and share it with whomever you think might benefit from it.

Originally published at hashnode.com.

The project we’ll describe here is an interactive internet kiosk that’s used as an extension for the LikeUs mobile application. LikeUs is a mobile app that makes it easy for users to choose a place to go out, have coffee or listen to a concert. Because Zagreb’s Tkalčićeva street is a place where quite a lot of young people hang out, we decided it was the right place for our offline promotion of the LikeUs app.

Implementing the Kiosk Mode

One of the first challenges we faced was the implementation of the kiosk browser mode on our device. It was an Android Box and we used Chrome as a web browser that will run the app. Kiosk browser mode is a mode in which you run the application in fullscreen and without any browser user interface or, in our case, without any Android user interface.

The intent is to prevent users from running anything other than the browser-based content. As there are hundreds of kiosk mode apps, we decided to use one of the available applications instead of building one from the ground up.

After some research, we decided to use the Kiosk Browser Lockdown app. It has all of the features we were looking for:

• Locking the device to a single URL
• Hiding toolbar options
• Hiding the notifications screen
• Hiding the Android user interface

The next step was to test the PWA in the Android environment and in the Kiosk Browser app. That’s when we discovered that things wouldn’t go as smooth as we planned!

The first problem we encountered was on the frontend side — the final website seemed like an upscaled version of the initial design, and this was due to some screen limitations and a different rendering environment. As the deadline was approaching, we didn’t have enough time to tweak every single item in CSS to fit the initial design outlines, so we decided to downscale the entire document.

It was a reasonable approach considering all the inputs we had. Having to test everything once more was a big downside, but we had to be sure that everything will work in this context.

The second problem was that external scripts like Google Maps weren’t loading in the Kiosk Browser app with the PWA, so we did a little tweak. We started the Kiosk Browser app, which removed the Android user interface, and then exited the Kiosk Browser app and started the PWA outside of the Kiosk Browser app. This way we managed to remove the Android interface with all external scripts loading as they were supposed to.

Developing a Progressive Web App

After going through the project brief and specifications, the first thing that came to our mind was… we should do a PWA (Progressive Web App). A Progressive Web App is an application that provides similar capabilities and functionalities as native mobile apps:

• Service workers allow apps to show content nearly instantly and reliably because they cache every request
• There is an ability to add the app to the home screen like a normal native app
• Push notifications can be implemented for multipurpose usages
• The app is fast and smooth
• It uses HTTPS and is easy to implement.

After evaluating client’s requests, all features of the PWA were meeting our requests.

Our requests were:

• To build an app that could be used on an interactive screen
• The app should use an existing API we built for our LikeUs mobile app
• The device used will be an Android Box
• Internet access would be restricted because the app would be connected to a public network (this would change later)
• The app should have an additional section for banners and a banner management system

We could build a web app with our existing API without having to implement additional functionalities, and we could also build a simple CMS (content management system) for banner management and push notifications for content reloading. As internet access would be restricted and unstable, we could use the PWA feature to cache pages and serve them even when the app is offline.

Be sure to check out this in-depth tutorial and explanation for Service Workers.

Tweaking the Banner Management System

The app is divided into two sections. The top section is the banner section, and the bottom part is the main section divided into tabs.

We have two types of banners — Youtube videos and images. Since banners can be changed, we needed to develop a CMS. We developed a simple CMS in which the client can enter Youtube videos and images into a slider.

The problem we encountered here was refreshing the app to reload new banner content. You see, because the app was using Barba.js, it was never refreshing. To make it work, we used a cool feature of our PWA — push notifications. Push notifications are a feature that uses the Notifications API and the Push API to send messages from the server to the client.

How did push notifications help solve our content reloading problem? The solution is pretty simple and straightforward. When the user changes banner content in the CMS, we send a push to the PWA and then the PWA refreshes two times. The PWA needs to be refreshed two times to delete the cache and to reload new content.

Dealing with External Obstacles

Internet kiosks are often placed in outdoor environments where internet connection is sometimes unstable and slow. When the internet connection is public and in a pretty crowded street, you face a lot of problems when using real-time communication and external APIs.

A common “hacky” approach is to extend the delay time and hope that everything works well. Even though this is not the preferred way, it can serve as a backup if everything else fails.

Google Maps was one of the external APIs that gave us a lot of headaches. We had to reload and add new pins, but on a slow connection, this was sometimes impossible.

Balancing Between Fixed and Dynamic Content

Optimization is not only applied in the realm of advanced caching techniques and content delivery networks. Smart layout placement and understanding elements that can be “pushed out” of the page reloading flow can reduce the number of requests and speed up the entire navigation flow.

The advertising content in the kiosk was hosted on Youtube — it was a video slider that was repeating through all pages. Below that, we had the main content with inline navigation. When selecting different navigation items, the default browser behaviour was to reload the entire page, including that fixed advertising area. It’s a performance nightmare, especially when having external scripts such as Youtube API.

The question here is — how to reload only one specific part of the page? Well, there will be no browser reloading and the only thing that can be done is changing content in the background without leaving the page.

Because of the implemented analytics, we had to update the URL accordingly. We did this by using the PJAX (Push State Ajax) technology. This technology allows content prefetching and swapping target DOM nodes in the background.

To avoid content flashing, create a simple fade transition that fires when content changes. As it’s time-consuming to manually manage all states of content swapping, we used an external library called Barba.js. This library allows advanced transition management and is compatible with all animation frameworks.

Barba.js has internal state caching that can be used to leverage browser caching and optimize loading time. Barba cache is a global Javascript object where every value is a Promise that has to be resolved.

Implementing Analytics and Virtual Pageviews

We wanted to measure user interaction and page views. Because we are using Barba.js, this is basically a one-page app without page reloads, so the trick to measure page views in this type of app is to use Virtual Pageviews. They are page hits sent to Google Analytics, without actually reloading the page.

The first step is to include the Google Tag manager code, and then to actually send Virtual Pageviews to the data layer. We can do it with the next snippet:

dataLayer.push({ 'event': 'VirtualPageview', 'virtualPageURL': currentUrl, 'virtualPageTitle': title });

This snippet needs to be called on each new page. On each user interaction that opens a new “page”, we call this snippet that sends the page URL and the page title to Google Analytics. This way we can track pageviews in single page apps that use Barba.js or any other PJAX technology.

To Conclude

When working in a specific environment, sometimes the “by the book” solution is not your only solution. There is usually an opportunity to innovate and use some common tools and libraries in a not so standard environment with a specific set of challenges.

Originally published at www.bornfight.com.

“The key is to embrace disruption and change early. Don’t react to it decades later. You can’t fight innovation.” — Ryan Kavanaugh

Lately, there’s been a lot of buzz around PWAs with many claiming it to be future of web development, especially in terms of mobile devices. At its core, a Progressive Web App (PWA) is simply a web application that uses modern web techniques to deliver a native app-like experience to users. These are web applications with progressive enhancement to implement features like caching, background sync, and push notifications.

Even though PWAs have been around for more than two years now, the response is quite underwhelming. Few big players have adopted this philosophy but most haven’t actually embraced it very much. Chrome and Mozilla are perhaps the best browsers to test out your PWAs as Apple is yet to get into this stuff.

PWA — Is it really good ?

On one hand, we have native apps that are undoubtedly fast and efficient in most of the cases. On the other hand, there are websites that are kinda slow and with the connectivity issues, it only gets worse.

Accelerated Mobile Pages Project (AMP) spearheaded by Twitter and Google was launched in 2016 to solve those slow connection issues only. PWAs work flawlessly in all the possible scenarios. With a good connection, there is never a problem. The problem is when we have no connection and we are greeted with the error page.

But this can become most annoying if we have a slow connection. The page seems to be loading and all we see is a blank screen. We just wait, wait and wait but the page never seems to load. This is where PWA comes to our rescue. The best part about PWAs — you get the best user experience possible in slow connectivity as well as no connectivity (yep , you read it right..).

Why it makes sense to use PWA

According to a study, an average user spends 80% of his total time on apps on only three of his apps (For me its Chrome, Quora and Medium).

The other apps just sit idle for most of this time consuming a precious portion of the memory. Moreover, it costs around ten times to develop an app rather than creating a website for the same. The cost can get much higher if you plan to develop and maintain separate code bases for different platforms like Android, iOS and the web.

Native App features that PWAs can use

• Push notifications
• Full Screen
• Offline working
• Splash screen is supported giving it a more app like feel

PWAs can make use of many more such features. The above points are only to give you a hint of what PWAs are capable of. However, there are some traditional features that only native apps enjoy as of now.

Native App features that PWAs can’t use as of now

• No or highly restrictive access to different hardware sensors
• Alarms
• Phonebook Access
• Modfiying System Settings

PWAs are evolving quite fast and we can hope to see these features come to action pretty soon.

Two Major Components of a PWA

App Manifest
It’s a JSON file that defines an app icon, how to launch the app (standalone, full-screen, in the browser etc), and any such related information. It’s located in the root of your app. A link to this file is required on each page that has to be rendered.

It is added in the head section of the HTML page:
<link rel=”manifest" href="/manifest.json">

Service Worker
Service worker is where most of the magic of happens. Its nothing but JavaScript code that acts as programmable proxies solely responsible for intercepting and responding to network requests. Since it acts as a proxy and can be easily programmable, the application must be served over HTTPS to keep the data secure.

Its worth noting that the service worker caches the actual response, including all HTTP headers, rather than just the response data. This means that your application can simply make network requests and process the response without any specific code to handle the cache.

How do I get started?

The best thing about getting started is that it’s quite easier than it seems. In fact, it’s very much possible to take an existing site and convert into a PWA. I highly suggest you watch this if you intend to develop a PWA.

Thanks for reading! If you liked it, please support by clapping and sharing the post.