A few times a year, a client comes to us with a brief that begins "we want to rebuild our site as a React SPA." We read these briefs carefully, ask what specifically the SPA architecture is meant to enable, and find that the answer is almost always "smoothness" or "modern feel" — never a concrete user-facing benefit. The SPA has become an aesthetic, not an engineering decision.
This matters because SPAs are expensive. Not only in initial build cost, but in long-term maintenance, in performance for users on poor connections, in accessibility, in search-engine indexing, in the discipline required to keep the bundle small. Every team we have worked with that picked an SPA against our advice has, two years later, hit one of these walls.
The default architecture for the public web is server-rendered HTML, progressively enhanced with JavaScript where interactivity demands it. This is what HTMX, Hotwire, and Phoenix LiveView all model. The mental model is: the server is the source of truth, the URL is the application state, and JavaScript is for the few moments where touching the network would feel slow. For most marketing sites and a surprising number of dashboards, this is the right shape.
When is an SPA actually right? When the application has long-lived client state that would be expensive to round-trip — a real-time editor, a graphical canvas, a complex form with cross-field dependencies. For these cases, the SPA pays for itself. Outside of these, it is paying off architectural debt that need not exist.
Our default for new projects: server-rendered, with islands of interactivity. We reach for the SPA when the brief makes the case. We have found this conversation is often the most valuable single thing we do with a client — it saves them, on average, eighteen months of regret.