The myth that you can’t build interactive web apps except as single page app
Modern web developers are re-evaluating the assumption that rich interactivity requires single-page applications built with heavy JavaScript frameworks. Many argue that server-rendered, multi-page apps augmented with lightweight tools (like htmx, Alpine.js, or simple jQuery) plus good HTTP caching can deliver fast, responsive experiences with far less complexity, technical debt, and dependency churn. Others counter that SPAs still excel for highly stateful, app-like interfaces and long-term architectural flexibility, highlighting an emerging tradeoff between simplicity and client-side power rather than a one-size-fits-all solution.
Title and framing
- Several commenters note the original article title includes “…And Other Myths”; shortening for HN made it sound like a stronger, even “ragebait,” claim.
- Some see the essay as useful myth-busting; others consider “you can do X without Y” inherently uninteresting unless it addresses when you should or shouldn’t do Y.
SPA vs MPA and what “interactive” means
- Broad agreement that interactive apps can be built without SPAs, via server-rendered HTML plus “sprinkles” of JS (jQuery, Alpine, htmx, Hotwire, etc.).
- Some argue that for complex, app-like UIs (offline use, rich multi-form workflows, heavy client-side state), SPAs remain a better fit.
- Others counter that many real products (e.g., commerce sites, internal CRUD tools) don’t need SPA-level complexity.
Isomorphic apps, hydration, and alternatives
- Commenters mention isomorphic rendering and hydration (React, Next.js, SvelteKit, Qwik) as ways to mix server and client work.
- Drawbacks highlighted: complexity of state management, non-determinism between server and client runs, and entangled component/state logic.
Productivity, complexity, and long‑term maintenance
- Several developers report large reductions in code, dependencies, and build complexity when moving from SPA frameworks (e.g., Vue/React) to SSR with light JS.
- Others argue that once set up, React/TypeScript/Next.js allow much faster iteration, better composability, and easier refactoring for complex UIs.
- There is concern about framework churn, dependency graphs, and abandoned versions versus “boring” backends (Django, Rails, Laravel, .NET) with minimal frontend tooling.
Caching, service workers, and performance
- Many say classic HTTP caching with long-lived, hashed static assets can make MPAs feel nearly as fast as SPAs.
- Others stress that caches are finite, eviction is common (especially on mobile), and service workers give more explicit, offline-capable control.
- There is debate over how much benefit avoiding even a single network roundtrip adds; some see service-worker caching as overkill, others as essential for unreliable networks.
Philosophy and ecosystem
- Some see SPAs as a “hacky” but necessary evolutionary force that pushed the platform to add better primitives; others view SPAs as a clean architecture in their own right.
- Nostalgia for “PHP + jQuery spaghetti” and progressive enhancement is common, but several note that naïve jQuery can become unmaintainable in large apps.
- A recurring theme: choose the simplest stack that will keep maintainers in five years least miserable, rather than following fashion.