But wait... are they Single Page Applications?


This is part 5 in a series on multi-page behaviours in modern web apps

In this post I’ll address a vexing and potentially contentious question concerning terminology, in which I’ll argue that CSR applications that support multi-page behaviours are not Single Page Applications. Warning: this is going to be opinionated.1

A recap

In the previous two posts, I described two design patterns for web applications that are both fully Client-Side Rendered and support all multi-page behaviours:

  • The Simple CSR-MPA pattern is the simpler of the two patterns, but its simplicity comes with the cost of reloading the page every time the user clicks a link.
  • The Stateful CSR-MPA pattern uses the HTML5 History API to suppress page reloads for the majority of user navigation actions, and in the remaining cases where page reloads cannot be suppressed, it handles those page loads smoothly and efficiently.

An obvious question arises regarding these two design patterns: are they Single Page Applications?

There are several ways to look at this. First, how is the term “Single Page Application” used in everyday speech?

How the term “SPA” is used in everyday speech

In everyday speech, the term “Single Page Application” (SPA) is often used informally to mean any CSR application—that is, any web application that “runs in the browser”, where nothing but static files are served from a web server or CDN, and which (optionally) makes asynchronous server-side API calls.

According to this loose definition, the Simple CSR-MPA pattern and Stateful CSR-MPA pattern would both qualify as SPAs, since both run entirely in the browser.

However, this interpretation of the term “SPA” is highly questionable. To understand why, let’s first look at how the term “Single Page Application” is defined traditionally.

How the term “SPA” is traditionally defined

A traditional definition of the term “Single Page Application” typically looks like this.

A single-page application (SPA) is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the web server, instead of the default method of a web browser loading entire new pages. The goal is faster transitions that make the website feel more like a native app.


In a SPA, a page refresh never occurs; instead, all necessary HTML, JavaScript, and CSS code is either retrieved by the browser with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions.


— from Single Page Application, Wikipedia, 29 January 2022

This aligns closely with the definitions provided elsewhere—such as here, here, here, here, and many others. Nearly all sources state that in a SPA, “a page refresh never occurs”, or words to that effect. After an initial page load, all further content updates are made by updating the current page without any subsequent full page reloads.

The conflict

This results in a slight conflict between SPA’s original definition and its current everyday usage. On the one hand, a SPA never reloads the page. On the other, a CSR application that fully supports multi-page behaviours must support page reloads—at a minimum, to allow opening links in new tabs, which many consider to be a normal part of using web applications. The discrepancy is greater when you look at the Simple CSR-MPA pattern, which reloads the page every time the user clicks a link—even in the current browser tab.

In summary: the traditional definition of “SPA” appears to exclude certain types of CSR application. This might seem like a minor thing, but it’s actually very significant.

When the term “Single Page Application” was first coined circa 2005, SPAs did what they said on the tin: they were single-page by name, single-page by nature. Your mental model was that they behaved like a native application which happens to run in the browser. You used the URL once to open the application, following which all interaction occurred within the browser’s content area. You didn’t dare touch the browser’s native controls such as Back, Forward, or Reload—because they would probably make the application explode.

Since then, technology has evolved and it’s now possible for CSR applications to exhibit all kinds of multi-page behaviours. Some CSR applications make full use of these; some don’t. For those that do, the mental model has changed: they’re more like a web application that runs in the browser, rather than a native application. This newer breed of CSR application supports deep links, history traversal, page refreshes, and opening links in new tabs; and they happily permit being used in multiple browser tabs concurrently. That makes them a very different beast from your traditional SPA. But the definition of a “SPA” has not caught up with this change. Should this newer breed of CSR application really be known as SPAs, or do they deserve to be known by a different name?2

One way to resolve this conflict would of course be to amend the definition of “SPA” to include this newer breed CSR applications and bring it in line with everyday usage of the term. A suitably revised definition would need to state that SPAs can reload the page, at least sometimes. Some sources have already started doing this (“full page reloads are rare”).

However, to encompass all types of CSR application, an amended definition of “SPA” would need to allow for the Simple CSR-MPA pattern as well as the Stateful CSR-MPA pattern. That’s quite a shift away from the original notion of what a SPA is.

Worse, overloading the term “SPA” in this way is extremely misleading and also semantically incorrect. I’ll explain why shortly. First, what is the right approach?

A resolution

One way to resolve this conflict is to keep the definition of “SPA” exactly as it is and accept the implication. In my view, Wikipedia has it right. The traiditional definition of a SPA doesn’t need changing at all. But the implication of that is this: there exists an entire class of CSR applications that are not SPAs.3

There exists an entire class of CSR applications that are not SPAs

But if they are not SPAs, then what are they?

A taxonomy of CSR applications

A strict interpretation of the traditional definition of the term “SPA” implies that there is a taxonomy of CSR applications, which looks something like this.

A taxonomy of CSR applications

A taxonomy of CSR applications

At the root of the hierarchy is the complete set of all CSR applications. You can think of these as all web applications that “run in the browser”. This means there is no SSR, and all dynamic rendering uses client-side code. Under the CSR applications are two subtypes:

  • Single Page Applications (SPAs)
  • Client-Side Rendered Multi-Page Applications (CSR-MPAs)

A SPA is a CSR application that loads once and then runs in the context of a single page load. This is your classic SPA, pretty much as the term was meant back in circa 2005. In effect, a SPA behaves like a native application that happens to run in the browser. It may support a limited subset of multi-page behaviours, but generally not those involving page reloads.4 This is how many sources define the term “SPA” today.

A CSR-MPA is a CSR application that supports all multi-page behaviours, including those that involve page reloads. In effect, a CSR-MPA behaves like a web application that runs in the browser, not a native application—which means it supports deep links, history traversal, page refreshes, and opening links in new tabs; and it happily permits being used in multiple browser tabs concurrently.

Examples of CSR-MPAs include any applications that use the Simple CSR-MPA pattern or the Stateful CSR-MPA pattern.

Why you should stop using the term “SPA” to mean any web application that runs in the browser

In order to defend the taxonomy above, I’ll now argue why you should consider breaking the habit of using the term “SPA” to mean any web application that runs in the browser.5

1. It’s semantically incorrect

It is axiomatic that a Single Page Application has a single web page. But what is a web page?

I’d argue that a web page is a hypermedia document displayed in a browser, addressable by its own unique URL, which may contain hyperlinks to other hypermedia documents, addressable by their own unique URLs.

And if the page happens to be generated entirely using CSR? That’s an implementation detail. There’s nothing in the definition of hypermedia that says there has to be markup. It’s true that web pages sometimes need to be machine readable—to help with SEO, for example—in which case, your server might need to emit markup.6 But emitting markup is not a prerequisite for a web page. If you visit a URL and it generates content using 100% CSR, that is still a web page.

By this definition, a CSR application that fully supports multi-page behaviours has multiple web pages. My demo application, for example, has 16,777,217 web pages. School Bus Yellow is a distinct web page from Wild Watermelon—even though they’re both entirely Client-Side Rendered by the same hunk of JavaScript.

And, crucially, an application that has multiple web pages prima facie cannot be a Single Page Application. It is absurd to refer to it as such. It is semantically incorrect.

2. It’s extremely misleading

When you use the term “Single Page Application” to mean any CSR application, it sends a confusing signal that such applications are technically incapable of supporting multi-page behaviours. It strongly implies that CSR applications must exhibit single-page behaviour—which is extremely misleading.

Experienced front-end developers know this is not the case. They’re used to the cognitive dissonance of calling something a “SPA” even though it has multi-page behaviour. But outside the niche of front-end development, this is not very well understood.

When evaluating terminology, you need to consider not just experts, but also those on the periphery: back-end developers, designers and product managers. Students learning web development for the first time. Engineers who “dabble” in web development to build tools and utilities.

When they hear the term “Single Page Application”, people outside the bubble of front-end development naturally assume SPAs behave as the name suggests, until they learn otherwise. Can you blame them? Historically they’ve been conditioned by years of using grim SPAs that fail to support multi-page behaviours, often for no particularly good reason. They’ve experienced the frustration of not being able to open links in new browser tabs, share deep links, and so on. As a result, they have low expectations about SPA usability when it comes to multi-page behaviours.

The term “Single Page Application” makes this worse. Why would you complain about a SPA’s defects if you believe they’re the result of technical constraints inherent in the design pattern? Given the web’s usability deficit with respect to multi-page behaviours, this confusion is unwelcome.

As a generic term for any web application that runs in the browser, “Single Page Application” has to be one of the worst-named design patterns in the history of computing.

SPA used too broadly; MPA used too narrowly

Just as the term “SPA” is used too broadly to include CSR applications that support multi-page behaviours, so the term “MPA” is used too narrowly to exclude them.

The way the terms “MPA” and “SPA” are often used seems to be fossilized by the technical limitations of 1993 and 2005 respectively. As a result, they’re often used as a weird kind of surrogate for SSR and CSR. The term “MPA” is routinely used to mean “it runs on the server”, and “SPA” to mean “it runs in the browser”. But this usage duplicates the terms “SSR” and “CSR”, and serves no useful purpose.

In the modern web, the paginess of a web application is quite distinct from where it renders content. Conflating these concerns can lead to confusion and contradictions. Here’s an example: in a helpful article about extending a SPA using the History API, the author concludes with the following sentence:

And there you have it! A multi-page single page application

This sentence perfectly illustrates the problem with using the term “SPA” to mean CSR application. An application cannot be both multi-page and single-page at the same time. In my view, a CSR application that fully supports multi-page behaviours is not a SPA; rather, it is a kind of MPA. More precisely, it is a CSR-MPA—an MPA that runs in the browser.

In summary, the confusion can be avoided with a terminology rebaseline:

  • Use MPA/SPA to describe only paginess (i.e. whether multi-page behaviours are supported or not)
  • Use SSR/CSR to describe where content is rendered (on the server or in the browser)

These dimensions are orthogonal: you can support any paginess using any place of rendering.

A taxonomy of Multi-Page Applications

If we take this argument to its logical conclusion, it implies there is a taxonomy of Multi-Page Applications, which complements (but overlaps with) the taxonomy of CSR applications described earlier.

A taxonomy of Multi-Page Applications

A taxonomy of Multi-Page Applications

In this taxonomy, the term “Multi-Page Application” means quite simply any application that has multiple web pages, as defined above. More specifically, it means any web application that supports multi-page behaviours. How it’s implemented is entirely irrelevant. This is a more modern and behaviour-centric definition of “MPA”, which I think better reflects the reality of how web applications work today.

As you can see, the taxonomy of CSR applications and the taxonomy of Multi-Page Applications intersect with the CSR-MPA—which is both a CSR application and an MPA.

So, are they Single Page Applications?

No, in my view the Simple CSR-MPA pattern and Stateful CSR-MPA pattern are not SPAs. They are CSR-MPAs. It’s time for the CSR-MPA to emerge from the shadow of the SPA as a first-class web application type in its own right.

In the next post I’ll take a brief step back in time, and look at a workaround for achieving a semblance of multi-page behaviours in CSR applications that was widely used before the HTML5 History API became available—the location hash.


  1. What’s the point in having your own blog if you can’t use it to be opinionated? 

  2. I suspect that in human psychology, there’s a kind of unique name bias whereby concepts are treated differently more seriously once they’re given a unique name and become differentiable by name. But I looked at Wikipedia’s extensive list of cognitive biases and couldn’t find it there. 

  3. To be clear: either resolution involves some degree of disruption. One involves changing the definition of “SPA” to align with everyday usage, while the other involves changing everyday usage to align with the established definition. There’s no way to resolve this conflict that is not disruptive in some way. And I’m not the only person to have noticed the discrepancy

  4. You have to draw the line somewhere, and this seems like a good place since it’s aligned with the definition of “SPA” provided by many existing sources. You only get to be a CSR-MPA if you support all the multi-page behaviours. 

  5. I’m not suggesting to stop using the term “SPA” entirely; rather, consider limiting its use to traditional SPAs as described above. Furthermore, this does not mean that CSR-MPAs are preferred over traditional SPAs, or that CSR applications are preferred over SSR applications. Use each design pattern where it works best

  6. If web pages need to be machine-readable, there are several ways to achieve this: you can combine SSG and CSR (which arguably still yields a CSR application, since no SSR is involved); or you can use some amount of SSR, as in a traditional MPA or a hybrid application, for example. All these approaches are perfectly valid, but they don’t negate the arguments made in this blog post.