You Shouldn't Start with an SPA

Original Article ↗ Hacker News Discussion ↗

Single-page applications (SPAs) are being reassessed as the default choice for new web projects, with many engineers arguing that modern server‑rendered approaches (often enhanced by tools like htmx, Hotwire or LiveView) now deliver comparable interactivity with less complexity and operational overhead. Proponents of SPAs point to benefits for rich, long-lived interfaces, offline or local‑first behavior, and shared APIs across web and mobile clients, while critics highlight heavier JavaScript bundles, fragile tooling, slower performance on poor networks, and tighter-than-advertised coupling between frontend and backend. A recurring theme is that architecture should follow product needs and team structure: SPAs can be the right fit for complex, data‑dense apps with deep user sessions, but are seen as overkill for simpler sites or small teams that benefit from tightly integrated, server‑driven UIs.

When an SPA Makes Sense

  • Several commenters argue SPAs are justified for complex, highly interactive UIs (e.g., rich admin dashboards, data-heavy apps, local-first/offline-first scenarios).
  • Others suggest SPAs should be chosen only when session depth or app “holotype” shows users stay and interact deeply, not for simple blogs/marketing pages.
  • Some believe SPAs will become simpler via newer tools (Remix, Livewire, WASM frameworks like Blazor/Leptos).

Coupling vs Decoupling Frontend and Backend

  • One camp says true decoupling is impossible: frontends always depend on backend data structures; attempts to hide this boundary are misleading.
  • Another camp reports success with public APIs consumed by both UI and power users, designed up front, with mock APIs enabling parallel work.
  • There’s a recurring argument that “backend for frontend” (per-view endpoints) reintroduces tight coupling even in nominally decoupled systems.

Tooling, JavaScript, and Scaling Concerns

  • Many complaints focus on SPA tooling: bundling, build times, cache invalidation, and huge bundles that grow with features and team size.
  • Some argue this is inherent to SPAs; others say tools like esbuild, simpler setups, or not using heavyweight frameworks mitigate the pain.
  • Debate over JavaScript itself: some see it as inherently messy; others say “spaghetti” is more about team practices than language choice.

UX, Performance, and Network Conditions

  • Pro-SPA voices cite faster subsequent navigations, less data transfer via JSON, adaptive behavior, and better opportunities for offline support and optimistic UI.
  • Critics counter that large JS bundles hurt first load, especially on slow networks and weak devices, and that many SPAs fail badly and opaquely under network issues.
  • Disagreement over whether SPAs truly send less data than HTML once compression, layout chrome, and overfetching are considered.

Org Structure, Teams, and Culture

  • Some say architecture naturally follows the org chart (Conway’s Law); SPA splits often reflect separate frontend/backend teams.
  • Others argue choosing architecture based on org structure is risky; full-stack workflows with tightly coupled server-rendered UIs can be more productive for small teams.
  • Cultural critiques: SPAs partly arose from frontend devs escaping backend-centric frameworks, but also from fad-following and “cargo cult” adoption.

APIs, Mobile, and Alternative Approaches

  • One side holds that mobile apps make APIs mandatory anyway, making SPA reuse sensible.
  • Others respond that in practice mobile and web often diverge enough that shared APIs don’t buy much.
  • Alternatives like htmx, Hotwire/Turbo, LiveView, Livewire, and classic frameworks (Django/Rails/Laravel) are frequently cited as simpler, productive non-SPA options.