It's time for modern CSS to kill the SPA

Original Article ↗ Hacker News Discussion ↗

What SPAs Are Really For (Disagreement with the Article)

  • Many argue the article misidentifies the core value of SPAs: they’re not primarily about page transitions.
  • Claimed “real” reasons for SPAs:
    • Managing complex, long‑lived client state (chats, editors, dashboards, rich filters, CAD, Figma‑like tools).
    • Decoupling frontend and backend via APIs, sharing the same backend with mobile apps or other clients.
    • Offline/low‑connectivity use (local‑first data, aggressive caching, optimistic updates).
    • Componentization and improved developer workflow (reusable components, consistent patterns, testability).

Where SPAs Make Sense – and Where They Don’t

  • Widely agreed: heavy, app‑like UIs (Gmail, Slack‑style chats, Google Maps‑style tools, internal line‑of‑business apps, PWAs/Electron) are strong SPA candidates.
  • Equally widely agreed: most marketing sites, blogs, simple stores, forums, documentation, and content‑driven pages don’t need SPA complexity.
  • Some propose a rule of thumb: SPA “behind the login,” traditional MPA/SSR for public content.
  • Overuse of SPAs is blamed on bootcamps and hiring culture that teach only React‑style stacks, plus the appeal of a single “frontend API client” mental model.

Performance and UX Tradeoffs

  • Complaints about typical SPAs: huge bundles, slow first load, endless skeleton screens, broken back/forward, broken open‑in‑new‑tab, lost scroll position, heavy RAM/CPU.
  • Counterpoint: these are failures of engineering and optimization, not intrinsic to SPA architecture; SSR sites can be just as bloated.
  • Debate over networks:
    • One side: round trips aren’t that expensive if responses are small and server is fast; better to send minimal HTML/JSON frequently.
    • Other side: on high latency or flaky mobile links, many round trips or form‑per‑interaction SSR feels awful; well‑designed SPAs can hide latency with prefetching and background updates.
  • General consensus: people can build terrible experiences with any model; there’s no automatic win.

View Transitions & Modern CSS / HTML Features

  • Many appreciate learning about View Transitions and Speculation Rules; demos show SSR sites can have SPA‑like, smooth navigation.
  • Others find View Transitions hard to use reliably and call the API over‑complex or “a disaster.”
  • Key limitation: cross‑browser support is incomplete (notably missing in Firefox), so it’s not yet a universal SPA replacement.
  • Even fans say these APIs mostly address navigation polish, not core SPA advantages like persistent client state, offline mode, or API decoupling.

Alternatives and Hybrid Approaches

  • Several mention HTMX, Datastar, Hotwire, Astro, and Web Components as middle‑grounds: HTML‑first with selective client interactivity.
  • Pattern suggested: SSR or static for baseline, then progressively enhance parts of the UI with light JS or small islands of SPA‑style code.
  • Some argue Next/Nuxt already default to MPA with client‑side enhancements and have effectively “won” in practice.

Meta and Sentiment

  • Strong backlash against SPA overuse on simple sites, especially from users frustrated by slow, fragile banking, ecommerce, and admin SPAs.
  • Equally strong backlash against blanket “kill SPA” rhetoric; many see the article as clickbait, based on a shallow or SEO‑driven misunderstanding of why SPAs exist.
  • Underlying tension: developer experience vs user experience, and a desire to “let the web be the web” while still building rich applications where they’re justified.