What Is a Single-Page Application (SPA)? Pros & Cons With Examples
Selecting the correct technology stack can make or break a project. Sometimes, the desire to use the next ‘hot’ technology leads stakeholders (both technical and non-technical) to make unwise decisions in this department.
Twitter is a high profile example of this phenomenon. In 2010, the social giant shipped a new Single-page Application (SPA) architecture that pushed all the UI rendering and logic to client-side JavaScript. This resulted in slow initial page-load times, as the entire client-side library had to be loaded upfront. The SPA architecture also transferred the bulk of the processing power from the server to users’ machines, which resulted in an inconsistent user experience across browsers. Twitter quickly reversed the decision, re-architecting the application to render most of the page content on the server side. You can find out more on their blog.
While Single-page Application frameworks have been around for years, they continue to evolve, with new versions generating buzz within the development community. The above Twitter example shows that, while developing an SPA may sound like an exciting option, it may not be the right one for your project.
In this article we will look at the pros and cons of Single-page Application frameworks, to help your team make an informed decision.
Table Of Contents
Single-page Applications vs Multiple-page Applications
Before the first Single-page Application framework appeared, the landscape was dominated by Multiple-page Applications (MPAs) built in static HTML and server-side technologies like PHP, ASP, Java, Ruby, and Python. It should be noted that what we consider to be a “normal” website even today, is the same as what we’re calling an MPA.
MPAs work by making multiple requests between the client and the server. As websites have grown in complexity, so have the demands they make on servers. The introduction of AJAX, which allows web pages to be updated without reloading, partly alleviated this issue. It also gave developers a glimpse into how an SPA future might look.
The first significant step towards this future was the release of jQuery, in late 2006. While not an SPA framework, it was the first big name in what is now a long line of JavaScript frameworks. But jQuery was always a UI-focused framework and as such, didn’t support elegant ways of handling data. This may be a non-issue in simple web applications but becomes problematic when handling rich dynamic pages or large-scale enterprise applications.
Next came the Knockout.js framework and its introduction of MVVM data binding. Knockout.js simplified the data binding process by creating a separation of concerns between the view and the application’s data. It did this by taking the view model and binding it to the browser’s HTML, so any changes in the browser were automatically tracked and reflected in the view model – and vice versa!
