Thomas Bonnet

Posted on Sep 20 Originally published at thomasbnt.dev

Progressive Web Apps (PWAs)

#pwa #pwabuilder #javascript #webdev

You’ve probably seen that little “Add to Home Screen” button when visiting a website on your phone. Behind it is often a Progressive Web App (PWA): a website that uses the same features as a native app—such as installation on the home screen, offline functionality, and push notifications—without going through an app store or requiring approval, and with a single codebase for all platforms.

This site (built with Astro, see How to Create Your Own Personal Blog with Astro (FR)) isn’t a PWA, but the same modern web building blocks apply as soon as you want to take it further.

What Is a PWA?

A PWA is built on three technical pillars:

HTTPS, which is required to enable advanced browser features
Service Worker, a script that runs in the background and intercepts network requests
The Web App Manifest, a JSON file that describes the application (name, icons, colors, splash screen)

Together, these three elements allow a browser to offer the site for installation as a true app, with its own icon and window, without going through an app store.

To learn more: What are progressive web apps? and the installability criteria for progressive web apps.

Service Worker: The Core of Offline Functionality

The Service Worker is installed once and then remains active regardless of which tab is open. It sits between the application and the network and can:

Cache static resources (HTML, CSS, JS, images)
Respond to a request directly from the cache if the network is unavailable
Synchronize data in the background once the connection is restored

The most common caching strategies are Cache First (serve from the cache; only access the network if the cache is empty), Network First (attempt to access the network; fall back to the cache if that fails), and Stale While Revalidate (serve from the cache immediately while refreshing it in the background).

To learn more: Service Worker Caching and HTTP Caching.

manifest.json and Installation on the Home Screen

The manifest.json file declares the app's metadata:

name and short_name
icons (multiple sizes, including at least one at 512x512 for Android app stores)
start_url, display (standalone to hide the address bar)
theme_color and background_color

{
  "name": "My Super Site",
  "short_name": "MonSite",
  "start_url": "/",
  "display": "standalone",
  "theme_color": "#111111",
  "background_color": "#ffffff",
  "icons": [
    { "src": "/icons/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

It is this file, combined with the Service Worker, that triggers the installation prompt (the famous “Add to Home Screen”) in Chrome and most Android browsers.

To learn more: Add a Web App Manifest File.

To generate the manifest, icons, and Service Worker without writing everything by hand, PWABuilder is a handy tool: it analyzes an existing site, flags what’s missing, and generates packages for app stores (Android, iOS, Windows).

Push Notifications and User Engagement

Push notifications rely on the Push API and Service Workers: the browser receives a message even when the app isn’t open, and the Service Worker handles displaying it. This requires:

An explicit permission request from the user
A server capable of sending messages via the browser’s push services
Useful and infrequent content, otherwise the user may disable notifications

const button = document.getElementById("notifications");
button.addEventListener("click", () => {
  Notification.requestPermission().then((result) => {
    if (result === "granted") {
      randomNotification();
    }
  });
});

To learn more: Re-engageable Notifications and Push.

Benefits: performance, cost, reach

Performance: Cached resources load almost instantly, even on slow networks
Cost: Only one project to maintain; no publication fees on app stores
Reach: Accessible via a simple link, search engine-indexable, and installable without friction

Limitations and Pitfalls (iOS Support, Storage, the Cache Trap)

iOS/Safari Support: Historically behind on push notifications and certain APIs; must be checked on a case-by-case basis depending on the targeted iOS version
Storage: The cache and IndexedDB are still subject to browser quotas, which may purge the least-used data
The cache pitfall: A poorly managed “Cache First” strategy can serve an outdated version of the site for days if the Service Worker is never updated. You must implement a cache versioning strategy (changing the cache name with each deployment) and a mechanism to purge old versions; otherwise, users will remain stuck on an old build without realizing it

To learn more: Caching.

Real-World Example: TOPLA as a PWA

TOPLA is a utility PWA for board games that puts the previous points (manifest, cache, installation) into practice.

Conclusion: When to Choose a PWA Over a Native App

PWAs are a good choice when the goal is reach and speed to market: a single codebase, no app stores, and one-click installation. Native apps remain the better option when the product relies heavily on advanced hardware APIs (such as advanced Bluetooth or specific sensors) or requires a presence in app stores for visibility.

DEV Community