Katie Lawson

Jul 19, 2018

What is a Single Page Application and why do people like them so much?

Part 1 of a 4 part series.

First of all, you’re most likely a regular user of Single Page Applications (SPAs) already. If you use Gmail, Google Maps, AirBNB, Netflix, Pinterest, Twitter, Paypal - the list goes on - you’ve used an SPA. As you click through your Gmail account you’ll notice that a lot doesn’t change during the navigation - the sidebar and header information stays untouched as you flip between Inbox, Sent, Drafts, etc and simply the list of emails changes. That’s the core principle of an SPA - it’s a single page where a lot of information stays the same and only a few pieces need to be updated at a time. This makes load time a lot quicker for you, the user, and makes the amount of information a server has to send to you a lot less (and a lot cheaper). Basically a win-win.

What’s the special Single Page Application setup that enables this?

On most websites there is a lot of repeating content. Some of it stays the same no matter where the user goes (headers, footers, logos, navigation bar, etc), some of it is constant in just a certain section (filter bars, banners), and there are many repeating layouts and templates (blogs, self-service, the google mail setup mentioned above). Single Page Applications take advantage of this repetition.

Let’s say your view of the website is a painting of a house and a tree. Traditional, multi-page websites paint the entire picture for you on the server and send it over to your browser.

SPAs give you the paint-by-numbers guides for the site, including the repeating guides you’ll likely be using, and then pipes the right paint (data and content) to fill out the template.

Either way you see the same tree, but the speed of SPA comes in when you request new content - like clicking on “next”, filtering results, opening a mail or - in this little metaphor - asking to see a different tree.

In a traditional website your request for a new tree would cause the server to repaint the entire picture and send it back.

With an Single Page Application, the server says “hey, I’ve got a new tree for you, but you’ve already got the house so just leave that the same”, then sends you updated instructions for a new tree and the paint to make it. By transferring the painting work (page rendering) from the server to the client (you) the page can be dynamically rewritten, instead of going through an entire reload. This makes things a whole lot faster.

So with an Single Page Application, after the initial page load, the server doesn’t send any more HTML to you -  you download it all right at the beginning. The server sends you a shell page and your browser renders the user interface (UI). Then, as you click around, the SPA sends back requests for data and markup, the server shoots back the raw materials needed, and your browser takes it and renders an updated UI - interchanging pieces without ever needing to refresh the full page. This quick interchangeability makes SPAs incredibly useful on pages that are highly navigated and use repeating templates.


With less server work required, SPAs also make it more feasible to build more complicated UI features such as those with animations. Additionally, because the server doesn’t need to spend time & energy doing the full drawing, SPAs lower the impact on your servers overall - meaning you can save money by using less servers for the same amount of traffic.

Why do developers like Single Page Applications?

Along with the quicker performance time explained above, SPAs also let developers build the front-end a lot faster. This is due to the decoupled architecture of SPAs, or a separation of back-end services and front-end display.

Many business critical functionalities don’t change all that much on the back-end. While how your customers log-in, register, purchase and track orders may change it’s “look” or presentation from time to time, the logic and data orchestration behind it is pretty constant - and you don’t want to risk messing it up.

Similarly, your raw content and data might stay the same but how you want to display it differs. By decoupling that back-end logic & data from how it’s presented you turn it into a “service”, and developers can build many different front-end ways to show and use that service.

With a decoupled setup, developers can build, deploy, and experiment with the front-end completely independently of the underlying back-end technology. They design how they want the user experience to look and feel, and then pull in the content, data, and functionality through those services. This is done using APIs, which are a standard set of rules between applications on how they will structure, exchange, and reassemble data.


This API setup lets developers work quickly on the UI with no risk to business critical back-end technologies. As more and more functionalities are built as modular services (a microservice architecture) that can be updated independently, it becomes easier to experiment with how they are displayed and used. SPAs frameworks are great for playing around with these services to create engaging, dynamic, and even animated user experiences.

Also, a lot of people just simply like developing in a certain programming language (many SPA frameworks use javascript) and, thanks to APIs, the SPAs you build in one language can work happily with back-end services developed in different languages.  

Single Page Application? Angular? React? Ember? Vue?

Angular and React (and many others such as Ember and Vue) are frameworks that developers use to create SPAs efficiently and eloquently. Simply put, these frameworks are a collection of reusable components, that many developers have contributed to, that follow a defined set of building rules. If you think of it like building a house, you could mix up the clay, dry the bricks,  mine and mold the steel yourself - or you could use the bricks and pipes other people have already designed and focus your time on what makes your house unique.

As for the differences between them all, I’m no expert (but this guy seems to be), but a great thing about SPAs and the frameworks that support them is that, thanks to APIs, with the right integrations you can use whichever framework you prefer with your other API-enabled technologies.

Up next in part 2 is why these super efficient applications have historically caused a lot of headache when trying to get them to work with a Content Management System.

How to Use Single Page Applications with a CMS

Prefer PDF? Read the full SPA story here. 

download the guide
How to Use Single Page Applications with a CMS