Don't Panic — Progressive Web Applications

A Progressive Web Application is still a website. It does not climb out of the browser at night and become a small native app with a convincing hat. It is a web application that can gain installed-app presentation, resilient access, and selected device features when the browser and operating system support them.

The useful starting point is the ordinary web path: pages, navigation, forms, data, and accessible HTML. That path must work before any PWA layer arrives carrying a manifest and a service worker. The web app manifest is a JSON description of the installed application: its name, icons, preferred launch address, and display preference. It describes how the browser may present the app. It does not cache a page, grant installation, or negotiate with the operating system on your behalf. Browsers retain that particular privilege, which is probably for the best.

The service worker is where the machinery becomes both useful and slightly fussy. It is an event-driven worker that can receive fetch events for requests in its scope and choose a response. For a versioned script, that might be a cached release asset. For a navigation, it might be a network attempt followed by an offline fallback. For a write, a cache alone is not a plan; the interface needs a visible pending state, safe retries, and a way to deal with conflicts.

The surprise is that offline is not one switch labeled Offline. It is a separate promise for each request type. Cached content can be stale. A stored response cannot prove that a server recorded a write. A service worker also has no page document and no permanent memory, so durable state belongs in browser storage or on the server. The worker can stop between events, leaving any grand in-memory scheme to contemplate its choices.

Updates need the same care. A newer worker can install while an older one still controls open pages. That protects a current session, but it means activation, reload behavior, and stale-cache cleanup need an intentional design. The practical rule is pleasantly unglamorous: decide the response policy for navigation, assets, reads, and writes, then test it on a first visit, repeat visit, offline use, upgrade, and failed request.

Read the Intro for the full layer and lifecycle map. Use the Cheatsheet when you need the request strategies, worker states, and failure rules in one place. The Practice tab turns that map into a test routine, and the Exercise gives one small offline journey a chance to misbehave safely before a larger application does it in public.

Don't Panic — Progressive Web Applications

Relevant careers