Server-Side Rendering or SPA

Few architecture decisions are made so casually and have such long-lasting effects as the choice of where an application assembles its user interface — on the server or in the browser. It is often not experienced as a decision at all but as a given: you take whatever is currently customary, usually a single-page application, because that is how modern frontends are built. The risk lies precisely in this casualness, because the choice shapes the complexity a team carries over the system's entire lifetime.

This document treats the choice as what it is: an architecture decision with long-term consequences. It names how the two approaches really differ, which costs the shinier option hides, and the criterion on which the decision honestly hinges. It follows no framework fashion and crowns no winner; it describes what each approach is the right fit for. No versions and no numbers are given.

1. The wrong question

"Are we building an SPA?" is rarely a real question; it is usually an assumption already made. The single-page application has become the default, and being the default is a strong but poor reason: it tells you what is widespread, not what fits. The real question is not whether to follow the usual path but how interactive the application really is and how long it is meant to live — because that, not fashion, is what determines the right approach.

The question matters because of its reach. Whether the user interface is built on the server or in the browser determines not only loading behavior but the entire way the system is built: how many moving parts it has, how much state is held twice, how much toolchain you maintain and how much of it will still be understandable in ten years. A casually made choice ties the team to a complexity it never consciously chose.

Trade-off. Asking the question deliberately means challenging the convenient default and judging for your own system — more work than following the usual path.

Cost. The judgment requires an honest assessment of how interactive the application really is — and teams regularly overestimate their need for interactivity.

When we decide differently. Where an application is obviously highly interactive — an editor, a tool with constant, fine-grained state in the browser — the SPA is the obvious choice, and a lengthy assessment is unnecessary.

2. What really distinguishes the two

At its core, the difference is simple: with server-side rendering, the server assembles the finished user interface and sends it to the browser, which displays it; with a single-page application, the server essentially sends an empty shell and a program, and the browser assembles the user interface itself and keeps it up to date while running. In the first case, the work and the state lie mostly on the server; in the second, both shift into the browser.

Almost everything else follows from this one shift. An SPA becomes a standalone application in the browser, with its own state, its own logic, its own toolchain — and usually needs an API to the server through which it fetches its data. A server-side rendered system remains one application that lives in one place and whose browser part stays small. The choice is therefore less about technology than about how many independent systems you build and operate: one or two.

Diagram: Server-side, the server builds the user interface and the browser displays it. With an SPA, the browser builds it itself and fetches its data through an API — two systems instead of one.

Trade-off. Shifting into the browser buys richness and decoupling at the cost of a second independent system that you build and operate.

Cost. Two systems mean two toolchains, two places for state and logic, and an API in between — complexity you don't have with the server-side approach.

When we decide differently. Where richness in the browser is the very purpose of the application, the second system is not overhead but the point — then the shift is the right one.

3. The strengths of the single-page application

The SPA has real strengths that should not be downplayed. It allows rich, immediate interaction: state changes in the browser without a round trip to the server, the user interface responds instantly, and complex, app-like workflows — dragging, editing, instant feedback — feel fluid. For software that should feel like an application rather than a sequence of pages, it is the natural approach.

There is a second, frequently cited advantage: after the initial load, navigation within the application feels instant, because a full page change is no longer needed — the browser only swaps out what changes. For applications in which a user spends a long time and switches between views a lot, that is a noticeable gain in fluidity. It is paid for with a longer initial load: the SPA loads more up front in order to be faster afterward — a good trade for tool-like applications, a bad one for those a user visits only briefly.

Then there is decoupling. Because the SPA gets its data through an API, the frontend is detached from the server and can be developed independently — sometimes by a separate team, on its own cadence. Where the same API serves several user interfaces, such as a web and a mobile application, this decoupling pays off, because the logic lives once on the server and the interfaces share it.

Trade-off. You buy the SPA's strengths — richness and decoupling — with the complexity of a second system and an API that becomes a contract.

Cost. Rich interaction and a decoupled frontend require more code, more tooling and more care with state and the API than a server-side user interface.

When we decide differently. Where the application needs neither rich interaction nor multiple user interfaces, the SPA's strengths go unused and you carry only its price — then the server-side approach is the better one.

4. The strengths of server-side rendering

Server-side rendering has a strength that is easily overlooked amid the trend: simplicity. It remains one system in one place. There is no second application state in the browser that has to be kept up to date, no duplicated state, no API as an additional boundary. The user interface arrives finished, which makes the initial load fast and brings initial visibility for search engines and people without extra effort. The browser part stays small and therefore easier to understand and maintain over the years.

Another, quieter advantage is robustness. Because the user interface arrives finished from the server, its basic functions work even when something fails to load in the browser or a device is underpowered — it depends less on a large program executing flawlessly. An SPA stands or falls with its browser program; a server-side rendered system delivers basic value even when not everything succeeds. For applications with a broad, unknown audience, this robustness is real value.

This simplicity is a strong argument especially from the standpoint of longevity. A system made of one part ages more slowly than one made of two, because it has fewer moving parts that can drift apart and because its small browser part isn't exposed to the fast-moving toolchain of the SPA world. If you are building a system for a decade and don't need rich interaction, the server-side approach buys you calm — less that changes, less you have to keep up with.

Trade-off. The simplicity of server-side rendering buys calm and longevity by giving up the rich, instant interaction an SPA offers.

Cost. Where app-like interaction is needed after all, you have to recreate it with more effort than an SPA provides by nature.

When we decide differently. As soon as the application's core demands rich, fine-grained interaction, server-side simplicity isn't enough — then the SPA's richness is worth the price.

5. The hidden costs of the SPA

Because the SPA is the default, its costs often go unnoticed — they are considered the normal price of building. Yet they are real and weigh heavily over the system's lifetime. The first is duplicated state: what the server knows, the SPA must know too, and keeping both current and consistent is a constant source of bugs that doesn't exist in a single-part system. The second is the toolchain: the SPA world moves fast, and a frontend built in a modern way today will require repeated adaptation to new tools, versions and patterns over ten years.

The third, often underestimated cost is the two-systems problem itself. You don't build and operate one application but two, connected by an API that becomes a contract and demands all the care of long-lived interfaces. Every bug can lie in either of the two systems or at their boundary, which makes diagnosis harder. These costs are why the SPA should not be the unconditional default it is taken to be: it is the right choice when its richness is needed, and an expensive detour when it isn't.

These costs also include one that doesn't show up in the design and weighs all the more heavily in operation: the skills two systems require. A server-side rendered system needs a team that masters one domain; an SPA needs people who understand the server, the standalone frontend and the API in between — and who keep pace with the rapid change in frontend tooling over the years. Over a decade in which people come and go, the additional, broader skill set an SPA demands is a real and recurring cost. A system that requires fewer skills to operate survives the turnover of its builders more easily.

Trade-off. Acknowledging the hidden costs means not treating the default as free but weighing its price against its benefit.

Cost. The honest calculation requires a sober assessment of your own need for interactivity instead of — as usual — overestimating it.

When we decide differently. Where the SPA's richness is the core of the application, its costs are well spent; the caution applies where you carry them out of habit without reaping the return.

6. The criterion: interactivity and lifespan

The decision hinges on two questions. The first: how interactive is the application really — does it feel at its core like a tool, with constant, fine-grained state in the browser, or like a sequence of views that display data and occasionally change it? The second: how long is it meant to live — is it a long-lived system whose maintainability matters over a decade, or something short-lived whose later maintenance hardly counts?

Diagram: Not an either-or but a spectrum. Page-like applications sit on the left, tool-like ones on the right — and the broad middle is rendered server-side and made interactive where needed.

Together, the two questions yield the honest answer. A page-like, long-lived application should be rendered server-side — that is where simplicity wins over the years. A tool-like application whose value lies in interaction should be built as an SPA — that is where its richness is worth the price. The most common mistake is to build a page-like, long-lived application as an SPA because it's the default, and to carry its costs for a decade without ever reaping its benefits.

Trade-off. Deciding by these two questions requires honestly naming your own need for interactivity and the lifespan, instead of following the default.

Cost. Both assessments are error-prone — teams regularly overestimate the interactivity they need and underestimate the lifespan.

When we decide differently. Where a team has deep mastery of one of the two approaches and the application sits in the borderline zone, familiarity may tip the balance — a well-mastered approach beats one that is theoretically a slightly better fit.

7. The middle ground

The choice is not an either-or. Probably the most underrated approach is the middle one: a server-side rendered application that embeds targeted islands of interactivity where rich interaction is genuinely needed. The foundation of the system stays simple and long-lived; only the few places that demand app-like interaction are built richer. That way you get the calm of the server-side approach and the richness of the SPA exactly where it counts — without turning the whole system into an SPA.

This middle ground reflects the attitude that runs through good engineering: keep what is costly and volatile small and confine it to the places that really need it. Instead of building an entire application as an SPA for the sake of one rich spot, you take the richness to where it is needed and leave the rest simple. For many systems — administration tools, portals, applications with a few interactive parts — this is the best-fitting answer and at the same time the one least often chosen deliberately.

Trade-off. The middle ground buys simplicity at large and richness in the small with the care required to draw the boundary between them cleanly.

Cost. Mixing two approaches in one system requires discipline so that the islands stay contained and don't imperceptibly turn the whole system into an SPA.

When we decide differently. Where almost every part needs rich interaction, the middle ground is artificial and a full SPA is more honest; where almost none does, pure server-side rendering without islands is enough.

8. Common mistakes

The recurring patterns on which the frontend choice fails — almost all of them variations of following the default instead of the need:

• Building an SPA because it's the default, without checking whether its richness is needed.
• Overestimating your own need for interactivity and treating as tool-like what is in truth page-like.
• Treating the SPA's hidden costs — duplicated state, fast-moving toolchain, two systems — as a free default.
• Underestimating the lifespan and not factoring in the later maintenance of the SPA toolchain.
• Building a page-like, long-lived system as an SPA and carrying its costs for a decade without reaping the benefits.
• Overlooking the middle ground and turning the whole system into an SPA because of a few interactive spots.
• Designing the SPA's API casually, even though it becomes the long-lived contract between two systems.

9. Decision checklist

Before choosing the frontend architecture, clarify the following in order:

• How interactive, really? Does the application feel at its core like a tool — or like a sequence of views?
• How long-lived? Does maintainability matter over a decade, or is the application short-lived?
• Multiple user interfaces? Does the same logic serve several frontends that justify a shared API?
• SPA costs considered? Have duplicated state, the fast-moving toolchain and the two-systems problem been factored in?
• Middle ground checked? Is server-side rendering with islands of interactivity where they are needed enough?
• API as a contract? If SPA: is the API designed with the care of a long-lived contract?
• Team? Which approach does the team reliably master over the years?

Anyone who can answer these questions has chosen the frontend architecture by interactivity and lifespan — not by what happens to be customary.

FAQ

Isn't an SPA the modern standard? It is the widespread standard, and that is a poor reason to choose it. Prevalence tells you what is customary, not what fits. For tool-like, highly interactive applications, the SPA is the right choice; for page-like, long-lived systems, server-side rendering is often the better one, because it is simpler and calmer.

How do I know whether I need an SPA? By the interactivity. If the application feels at its core like a tool — with constant, fine-grained state in the browser, instant feedback, app-like workflows — then the SPA is natural. If it is a sequence of views that display data and occasionally change it, it is easy to overestimate the need, and server-side is enough.

What are the hidden costs of an SPA? Mainly three: duplicated state that has to be kept consistent on the server and in the browser; a fast-moving toolchain that requires repeated adaptation over ten years; and the two-systems problem with an API that becomes a contract. These costs are real, but they are considered normal because the SPA is the default.

Is there a middle ground? Yes, and it is often the best option: server-side rendering with targeted islands of interactivity where rich state is needed. The foundation of the system stays simple and long-lived, and the richness is confined to the few places that need it. For many administration and portal applications, this is the best-fitting answer.

Does the choice matter for longevity? A great deal. A server-side rendered system has fewer moving parts and a small browser part that escapes the fast-moving SPA toolchain — it ages more calmly. An SPA repeatedly requires you to update its toolchain over the years. Where maintainability over a decade matters, that weighs heavily.

Does the choice depend on the framework? Less than it seems. The question is not React or Vue or a server-side framework, but where the user interface is built and how many systems you build. Frameworks follow this decision; they don't replace it. Deciding by framework would mean putting the tool before the question.

Further reading

• Software That Still Runs in Ten Years — why the frontend choice quietly determines ten-year maintainability.
• Mature Technology over Novelty — why the default is not a reason and the fast-moving toolchain has its price.
• Reversibility over Prediction — keep richness contained and reversible instead of locking in the whole system.
• API Design for Long-Lived Systems — if SPA: design the API as a long-lived contract.

The foundation is the Batunet Engineering Method: decide by interactivity and lifespan, keep what is costly small, follow the need instead of fashion.

Closing engineering principle

The frontend architecture is one of the few decisions you make once and carry for a decade — and one of the few most often made unconsciously, because the default seems to have answered it already. That is exactly why it pays to make it deliberately. A single-page application is a powerful tool for tool-like applications and an expensive detour for page-like ones; server-side rendering is the calm, long-lived foundation for the broad middle that doesn't need rich interaction in every corner. The most mature answer is rarely one or the other in pure form, but the simplest approach that carries the actual interactivity — with richness only where it is worth the price. Deciding this way produces a frontend that is still understandable long after the fashion that would otherwise have dictated it has moved on.

The question is not whether to build the way everyone builds, but how interactive the application really is and how long it is meant to live. The default answers neither of these questions — it only obscures them.