The Single Page Application (SPA) Model

What is a Single Page Application?

A Single Page Application (SPA) is a web application delivered to the browser that doesn’t reload the page during use.  

This means all the code for structure (HTML), presentation (CSS), and behavior (JavaScript) is retrieved with the initial page load.   The content of the site is fetched dynamically via Ajax calls to the server.  

Over the past few years, this model has exploded in popularity with the advent of JavaScript frameworks such as Angular, BackBone, Knockout, and Ember. 

Some real-world examples include Gmail, Trello, and GitHub.   If you use Gmail, you've noticed that you can move between mailboxes, open emails, or write emails without leaving the page at all.  The content of the page is simply updated to reflect the current state of the application.

What are the advantages?

Single Page Applications offer a faster, more fluid user experience (UX) similar to a native desktop application. Since the page never reloads, this reduces the number of round trips to the server.

User experience is a key factor to consider when building a product that competes with other companies.  Even if the application is for internal use, saving time for your users means better productivity.

In traditional web applications, the client initiates the communication with the server by requesting a page. The server then processes the request and sends the HTML of the page to the client.  Each subsequent interactions results in a new request being sent to the server.  The server processes these requests and responds with a new page.   This can lead to a slow, clunky, and frustrating user experience.

The SPA model eliminates page reloads by leveraging asynchronous requests to the server for updating content.


Sounds great, so what are the disadvantages?


Search Engine Optimization (SEO)

SEO compatibility is something that has been problematic with SPA.  Search engine crawlers don't execute JavaScript which poses an issue for public-facing sites employing the SPA model. , posing an issue for public-facing sites.  There are a few workarounds that can overcome this challenge outlined here.

When they access your pages, they're most likely going to get a bunch of empty div's.   There are a couple solutions out there that allow your site to pre-render HTML for use by the crawler (BromBone, Prerender)

Browser history

SPA breaks the browser's design for page history navigation using the Forward/Back buttons. This presents a usability impediment when a user presses the back button, expecting the previous screen state within the SPA, but instead the application's single page unloads and the previous page in the browser's history is presented.

The traditional solution for SPA's has been to change the browser URL's hash fragment identifier in accord with the current screen state. This can be achieved with JavaScript, and causes URL history events to be built up within the browser. As long as the Single Page Application is capable of resurrecting the same screen state from information contained within the URL hash, the expected back button behavior is retained.

To further address this issue, the HTML5 spec has introduced pushState and replaceState providing programmatic access to the actual URL and browser history.

What if I need more than a single page?

The single page is the starting point. It’s the first part of the app that gets the ball rolling. When a SPA starts, the first visible thing we notice is the initial server rendering of the shell. That shell is our single page.   You can think of other pages as views.   Some examples may be a search view, order view, etc.

Use Cases


Single-page applications lend themselves to applications that are highly-interactive based around a consistent view.   If a site serves mostly static content or has substantially different interfaces per user, then a single-page application would not be suitable.