SPA Architecture

Written by Backbone Tutorials Team

Last updated: June 2026 · 10 min read

Open a modern web app, click around, and notice what does not happen: the page never goes white and reloads. Menus, panels, and detail views appear instantly, as if you were using a desktop program. That feel is the product of a specific architecture, the single page application, where the browser loads one document and a layer of JavaScript takes over the job the server used to do on every click. Understanding how those pieces fit is the foundation for everything else in frontend architecture.

This guide is the engineering view of the SPA, the structure rather than the search angle covered in SPA indexing. It builds on the application structure ideas from Foundations and anchors the rest of this cluster.

What a single page application is

In the older model, every link asked the server for a complete new HTML page, and the browser threw away the current one to draw it. An SPA breaks that loop: the server sends one page, and from then on JavaScript decides what to show.

One document, many views

The single document stays loaded for the whole session, while the app replaces the content inside it as you move around. Navigation becomes a matter of swapping views in place rather than fetching documents, which is why an SPA can feel as responsive as a native application. That single shift, who builds the next view, the server or the client, defines the whole architecture.

The app shell

Because the document loads only once, it plays a special role. It is the shell that hosts every view, and it carries the scripts and styles the app needs to run.

Loading the shell once

<div id="app"><!-- views render here --></div>
<script src="/assets/app.4f9a2c.js"></script>

The shell is typically a small HTML page with a mount point, like the #app element above, plus the application bundle. Once it loads, the framework boots inside it and owns that mount point for the rest of the session. Everything that follows, routing, data, rendering, happens within this one loaded page rather than across many.

Client-side routing

If the server no longer hands out pages, something has to decide which view matches the current URL. That job belongs to the client-side router.

Mapping URLs to views

The router watches the address, using the History API to keep clean paths like /products/42, and maps each one to the view that should render. When you click an in-app link, it updates the URL and swaps the view without a full reload, and it runs the matching view when someone lands on that URL directly. This is the architecture behind the routing basics guide, now seen as a structural layer rather than a feature.

The data layer

Views need something to display, and in an SPA that data usually comes from an API the client calls, then holds in memory. Keeping that concern in its own layer is what stops a growing app from tangling.

Fetching and holding data

The data layer fetches from the server, shapes the responses into models or a store, and caches what has already been loaded so repeat views are instant. Separating it from the views means rendering code never talks to the network directly; it reads from the data layer, and the data layer worries about requests, caching, and freshness. That boundary is one of the most important in the whole architecture.

Rendering and updates

With a router choosing views and a data layer supplying data, the last layer turns that into pixels and keeps them current as things change. The defining idea here is that the UI is a function of state.

Rendering from state

// The view renders from state; re-render when state changes
function render(state) {
  app.innerHTML = viewFor(state);
}
store.subscribe(render);

Rather than hand-editing the DOM on every event, the view layer describes what the UI should look like for the current state and re-renders when that state changes. Frameworks make this efficient by computing the minimal set of changes instead of redrawing everything, but the mental model is the simple one above: state in, view out. Get this right and the interface stays consistent with the data without a web of manual updates.

Trade-offs of the SPA model

The SPA is powerful, but it is not free, and treating it as a default for every site is a common mistake. Like any architecture, it trades some costs for some benefits.

When an SPA is the right choice

On the plus side: fluid, app-like navigation, rich interactivity, and a clean separation of client and server. On the cost side: a larger initial JavaScript payload, the rendering and indexing complexity the JavaScript SEO cluster covers, and real state management work as the app grows. The honest rule is to match the model to the job, reach for an SPA when the interface is genuinely interactive and stateful, and prefer a multi-page or server-rendered approach for content-first sites. With the shape of an SPA clear, the next guides drill into its layers one at a time, beginning with how to structure the client side itself.

Read next: back to the Frontend Architecture hub, or revisit application structure in Foundations for the groundwork.