For roughly a decade the default answer to "how should we build this" was a single-page application: ship a JavaScript bundle, render everything in the browser. A lot of sites got built that way which had no need of it, and paid for the decision in load time and complexity.
What an SPA costs
- Nothing renders until the JavaScript downloads, parses and runs. On a mid-range phone that is the difference between fast and slow.
- Search engines can render JavaScript, but not always promptly and not always the way you expect.
- You reimplement things the browser already does: routing, history, scroll restoration, focus management.
- Accessibility gets harder. Route changes do not announce themselves without deliberate work.
When it earns its place
- 01Genuinely app-like interfaces. A dashboard, an editor, a design tool. Long sessions where state persists across many interactions.
- 02Highly interactive views where a round trip per action would feel broken.
- 03Anything behind a login where search does not matter and the initial load happens once a day.
What most sites need instead
Render on the server or at build time, send HTML, then add JavaScript only where interaction requires it. The page is usable before any script runs, and the interactive parts hydrate afterwards.
This is what modern frameworks default to now, having spent years defaulting to the opposite. A marketing site, a blog, a content site and most of a store all fit this model, and it is faster in every measurement that matters.
The hybrid that usually wins
Most real products are a fast static or server-rendered public site, and a separate app-like section behind a login. Treating them as one problem forces a compromise that serves neither.
| Surface | Approach | Why |
|---|---|---|
| Marketing pages | Static | Speed and search matter, content changes rarely |
| Catalogue and product | Server-rendered or static with incremental updates | Search matters, data changes |
| Cart and checkout | Interactive, server-backed | State matters, search does not |
| Account or dashboard | Client-side app | Long sessions, no search value |
The question to ask
Does the person using this page stay for one action, or for twenty minutes? One action wants HTML. Twenty minutes justifies an application, and everything in between is worth thinking about rather than defaulting.
Working on something like this?
We build websites, stores and custom applications, and we will tell you honestly if the thing you are describing does not need one.