Guides

"SPA vs PWA" is one of the most common mix-ups in front-end development, and the reason is simple: the two terms are not opposites at all. A single-page application (SPA) describes how an app is built and navigates, while a progressive web app (PWA) describes what an app can do for the user. Putting them head to head is a bit like asking "manual vs electric car" — you are comparing two different axes, and an app can easily be both, one, or neither.

What an SPA is

A single-page application loads one HTML document and then rewrites the page in the browser as you navigate, instead of fetching a fresh page from the server on every click. After the first load, JavaScript swaps the relevant parts of the interface and pulls only the data it needs, usually as JSON from an API. The result feels closer to a desktop or mobile app, with instant transitions and no full-page reloads. React, Vue, Svelte and Angular all exist largely to make this model practical.

What a PWA is

A progressive web app is a different idea entirely: it is a website that uses modern web standards to behave more like an installed app. The three pillars are a web app manifest (so it can be added to the home screen with an icon and name), a service worker (a script that can cache assets and serve them offline), and HTTPS (required for those capabilities). A PWA can send push notifications, work without a connection, and launch in its own window — all from a normal URL, with no app store.

• SPA = architecture (client-side navigation, no reloads)
• PWA = capabilities (installable, offline, push)
• A PWA is often an SPA — but neither requires the other
• SSR is a separate axis (rendering, not app type)
• Choose by what the product needs, then layer features

Why they are not opposites

This is the heart of the confusion worth clearing up: the two are not mutually exclusive. A PWA is very often built as an SPA, but it does not have to be — you can add a manifest and service worker to a traditional multi-page site and make it a PWA. Likewise, plenty of SPAs are not PWAs at all, because they never add offline support or installability. SPA is about the navigation architecture; PWA is about the delivery and capabilities layered on top.

The SPA trade-offs

Looked at on its own, the SPA model buys you fluid interactivity at a cost. Once the bundle has loaded, interactions are fast because the app requests data rather than whole documents. But the first load is heavier — the browser must download and run JavaScript before showing meaningful content — and search engines may see an empty shell unless you render on the server. SPAs shine for dashboards, editors and app-like products, less so for simple content sites.

The PWA trade-offs

The PWA capabilities solve a different problem: re-engagement and resilience. Offline support means the app still works on a flaky train connection; installability puts an icon on the home screen and removes the browser chrome; push notifications bring users back. The trade-offs are real too — service workers add caching complexity that can serve stale content if handled carelessly, and Apple’s support on iOS, while much improved, still lags behind Android in places.

Where SSR fits in

A third term usually crashes this comparison: SSR, or server-side rendering. It is worth separating because it is yet another axis — a rendering strategy, not an app type. Meta-frameworks like Nuxt and Next.js render the first page on the server so users and search engines get real content immediately, then hydrate it into an SPA in the browser. You can combine SSR with an SPA, and a PWA can use SSR too; none of these labels rules out the others.

How to choose

So how do you actually choose? Start from what the product needs, not the acronym. If it is highly interactive and behaves like software, the SPA architecture fits. If users would benefit from offline access, installability or push, add PWA capabilities on top — it is incremental by design, which is what "progressive" means. If the site is mostly content and SEO matters most, lean on server-side rendering or even a traditional multi-page approach, and add PWA features only where they earn their keep.

The takeaway

The honest takeaway is that "SPA vs PWA" is the wrong framing. They are complementary layers: one decides how your app navigates, the other decides what it can do once it is there. The strongest modern web apps often combine all three ideas — an SPA for interactivity, server-side rendering for fast first paint and SEO, and PWA features for offline and installability — chosen deliberately rather than treated as rival camps.