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, or should not be called Single Page Applications. Warning: this is going to be opinionated.1
- The Simple CSR-MPA pattern is the simpler of the two patterns, but its simplicity comes at 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.
However, this interpretation of the term “SPA” is highly questionable, and I would say, undesirable. 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.
— 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.
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, modern CSR applications that fully support 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 problem is that the traditional definition of “SPA” appears to exclude certain types of CSR application. This might seem like a minor thing, but it’s actually rather 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 in case they made 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 use of these; others 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 different beast from your traditional SPA. But the definition usually given for “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 say that actually, SPAs can reload the page—at least sometimes. Some sources have already started doing this (“full page reloads are rare”).
However, to allow for all types of CSR application, an amended definition of “SPA” would need to encompass the Simple CSR-MPA pattern, which reloads the page every time the user clicks a link, as well as the Stateful CSR-MPA pattern, which suppresses some page reloads using the History API. 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 do I think is the right approach?
A better 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 traditional definition of a SPA doesn’t need to change at all. It’s already perfect. But the implication 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 original definition of the term “SPA” implies a taxonomy of CSR applications, which looks something like this.
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 most 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.
Why you should stop using the term “SPA” to mean any web application that runs in the browser
In defence of this approach, 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’s 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.
Whether a web page is generated using CSR or SSR is 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. But emitting markup is not a prerequisite for a web page. If you visit a URL and it generates content using 100% CSR, it’s still a web page.
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, that 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. 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 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 situation worse. Why would you complain about a SPA’s defects if you believe they’re the result of inherent technical constraints? Given the web’s usability deficit with respect to multi-page behaviours, the 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 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 we already have perfectly good terms for “runs in on the server” and “runs in the browser”: SSR and CSR. Duplicating them serves no purpose.
In the modern web, the paginess of a web application is quite distinct from where it renders content. A modern web application can exhibit single-page or multi-page behaviour independently of whether it uses SSR, CSR, or a combination. Conflating these concerns can lead to confusion and contradictions. For example, in this helpful article about how to extend a SPA using the History API, the author concludes with the following sentence:
And there you have it! A multi-page single page application
While I appreciate the humour, this sentence perfectly illustrates the problem with using the term “SPA” to mean CSR application. Logically, a CSR application that fully supports multi-page behaviours cannot be a SPA; rather, it’s a kind of MPA. More precisely, it is a CSR-MPA—an MPA that runs in the browser.
I would humbly suggest that a bit of terminology rebaselining will go a long way to resolving the confusion:
- 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)
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.
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 overlap—and the intersection is the CSR-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.
What’s the point in having your own blog if you can’t use it to be opinionated? ↩
I suspect that in human psychology, there’s a kind of unique name bias whereby concepts are treated more seriously once they’re differentiable by name. But I looked at Wikipedia’s extensive list of cognitive biases and couldn’t find it there. ↩
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. I don’t see a way to resolve the conflict that is not disruptive in some way. And I’m not the only person to have noticed the discrepancy. ↩
You have to draw the line somewhere, and this seems like a good place since it’s aligned with how the term “SPA” is traditionally defined. You only get to be a CSR-MPA if you support all the multi-page behaviours, not just a subset. ↩
I’m not suggesting to stop using the term “SPA” entirely; rather, I’m suggesting to limit its use to traditional SPAs as described above. Further, 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. ↩