跪拜 Guibai
← All articles
Frontend · JavaScript · Programmer

MPAs Are Quietly Replacing SPAs as the Default Web Architecture in 2026

By ErpanOmer ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Teams maintaining large SPAs are paying a growing tax in memory leaks, client-side auth exposure, and code complexity that modern MPAs eliminate outright. The infrastructure that made SPAs necessary — slow networks, no edge caching, primitive browsers — no longer exists, so the architectural trade-offs have flipped.

Summary

A decade of SPA dominance left front-end teams managing memory leaks, bloated client-side routing, and fragile authentication logic that should never have lived in the browser. The core problem is the SPA's long memory lifecycle: state accumulates across dozens of route changes with no hard reload to clear it, forcing engineers to invent lifecycle hooks and cleanup routines that add weight without solving the root cause.

Modern MPAs reverse this by moving routing and auth back to the server. HTTP/3, edge-node latency under 30ms, bfcache, and the Speculation Rules API make full-page navigations imperceptibly fast. Frameworks like Astro ship zero JavaScript by default and inject interactivity only where needed through island architecture.

MPAs now match or beat SPA navigation speed for most workloads. Content sites, e-commerce storefronts, and even many B2B dashboards built with charts and forms gain nothing from bundling the entire application into a multi-megabyte JS payload. The rule of thumb: use SPAs for Figma-class tools with dense, persistent state; use MPAs for everything else.

Takeaways
SPAs accumulate memory leaks and stale state across route changes because the browser never performs a hard reload, unlike MPAs where each navigation triggers garbage collection.
Client-side routing forces authentication logic into the browser where tokens in localStorage are trivially exposed; server-side routing keeps auth behind HTTP 302 redirects with zero client code.
HTTP/3 multiplexing, edge-node latencies under 30ms, bfcache, and the Speculation Rules API make MPA page transitions faster than SPA JSON-fetch-and-diff cycles.
Astro and similar frameworks default to zero client JavaScript, injecting JS only for interactive islands like buttons, rather than shipping an entire router and state manager.
SPAs still make sense for Figma-like tools and dense spreadsheets with high-frequency state flows; content sites, e-commerce, and most B2B dashboards gain nothing from the SPA model.
Conclusions

The SPA default became so entrenched that teams stopped asking whether their application actually needed client-side routing — the infrastructure that justified SPAs a decade ago has been replaced, but the habit persisted.

Eliminating state by letting the browser hard-reload is a simpler and more robust strategy than any state-management library, yet the front-end ecosystem spent years building tools to solve a self-inflicted problem.

The code-complexity argument is lopsided: an MPA route handler with a server-side 302 redirect replaces an entire client-side router, lazy-loading wrapper, Suspense boundary, and localStorage token check.

Concepts & terms
MPA (Multi-Page Application)
A web architecture where each page navigation triggers a full browser reload, fetching a new HTML document from the server. Memory, state, and JavaScript context are physically reset on every transition.
SPA (Single-Page Application)
A web architecture where the browser loads a single HTML shell and JavaScript intercepts all navigation, rewriting the DOM without a full reload. State persists across route changes, which causes memory accumulation over long sessions.
Island Architecture
A pattern where a page ships with zero or minimal JavaScript by default, and interactive components (islands) are hydrated independently. Astro popularized this approach, shipping static HTML and injecting JS only where needed.
bfcache (Back/Forward Cache)
A browser feature that stores a full snapshot of a page in memory so that back/forward navigation is instant. MPAs benefit from bfcache because each page is a complete document the browser can cache and restore.
Speculation Rules API
A browser API that lets developers declare which pages the browser should preload or prerender before the user clicks, making MPA navigations feel instantaneous without client-side routing.
From the discussion

The discussion is thin. One comment frames MPAs as a face-saving measure for a de-skilling frontend industry. Another dismisses the entire SPA/MPA debate as irrelevant because AI will eliminate frontend roles, a view immediately countered by a reply insisting the role won't vanish soon. A final comment simply asks what the difference is, receiving no answer.

MPAs serve as a cover for an industry with a rapidly lowering technical barrier to entry.
AI will make the SPA/MPA distinction and frontend roles themselves obsolete.
Frontend roles will not disappear in the short term, directly contradicting the AI-driven obsolescence claim.
Featured comments
chlingzool 1 likes

MPAs can provide a decent fig leaf for the frontend industry, where the barrier to entry keeps getting lower.

ErpanOmer

[facepalm][facepalm][facepalm]

世界和平467

Frontend roles are about to die out, and you're still hung up on this. AI will just do it all in one go.

ErpanOmer

It won't disappear in the short term.

See top comments, translated →
Source: juejin.cn ↗ Google Translate ↗ Backup ↗