Beginner’s Guide to Web Development

View All Chapters
Badge single page applications

Single-page Applications

7 minute read

The term “single-page application” (or SPA) is usually used to describe applications that were built for the web. These applications are accessed via a web browser like other websites, but offer more dynamic interactions resembling native mobile and desktop apps.

The most notable difference between a regular website and an SPA is the reduced amount of page refreshes. SPAs have a heavier usage of AJAX — a way to communicate with back-end servers without doing a full page refresh — to get data loaded into our application. As a result, the process of rendering pages happens mostly on the client-side.

Single-page App Cons

While building SPAs is trendy and considered a modern development practice, it’s important to be aware of its cons, including:

  • The browser does most of the heavy lifting, which means performance can be a problem — especially on less capable mobile devices.
  • Careful thought must be put into search engine optimization (SEO) so your content can be discoverable by search engines and social media websites that provide a link preview.

Mitigating Cons With Server-side Rendering

Most modern JavaScript frameworks are working on ways to handle server-side rendering of SPAs — meaning the user would get a fully populated page when the SPA is loaded for the first time, instead of, for example, seeing a loading indicator.

Server-side rendering can alleviate some of the burden browsers have to go through when rendering pages, and will also help with the problem of SEO and content discoverability.

Popular JavaScript Frameworks for Building SPAs

The more interactivity that happens on the client-side, the more JavaScript code is needed to make those interactive pieces function well. And the more code is written, the more important it is to have a clean and well-architected codebase. And this is exactly the problem JavaScript frameworks help solve — each with its own approach.

There are a lot of open source JavaScript frameworks that help with building SPAs, such as:

The list could go on and on — but let’s dive a bit more into the first two here: Angular and React.


Angular is a front-end framework built to ease the burden of writing complex apps while keeping everything testable and organized. The first version of Angular was created back in 2009, and it was way ahead of its time. When Angular was first written, it solved a lot of problems that have now been fixed at the JavaScript language level with the release of ES2015. While Angular 1 had to create its own solution for modules, for instance, ES2015 now provides a solution to JavaScript modules right at the language level.

With inadequacies like this in mind, the Angular team at Google rewrote the framework from scratch. The new and improved version of Angular (known as Angular 2) is very promising. Angular’s overall proposition has not changed: It provides a holistic solution to writing apps. Built right into the framework is a way to do application routing, communicating with web servers, and more. You won’t need any extra packages to get a basic but fully functioning web app up and running.

Angular also provides a whole ecosystem (Angular CLI) for actually building apps that includes a tool to scaffold applications, as well as a solution for building mobile web apps with performance in mind as a first-class citizen (Angular Mobile).


React is not considered a framework, per se — rather, it touts itself as a view library. But don’t let that fool you, as React was built to solve user interface problems at a very large scale.

React was pretty disruptive when it was first announced. The idea of “Rethinking Best Practices” was attached to it with good reason — React’s proposition was very different than the trends the rest of the JavaScript community was moving toward at the time. While other framework authors were focusing on applying the MVC pattern to writing apps and having a clear separation of code associated to the view and other parts of the application, React proposed coupling those together and simplifying the code by means of composition and other functional paradigms through components.

In the time since React was released, other popular frameworks, such as Angular and Ember, have also moved toward a more component-based architecture, as well as applied similar ideas React brought to light, such as the virtual DOM, which is how React applies changes to the view.

React’s overall approach to building apps is different than Angular and Ember because it is just a view library — it does not provide a way to do client-side routing or even a way to load data from a back-end server bundled with the library. This means that to get a simple yet fully functioning app (that needs these missing features) to work, you will need to look into other libraries that are not maintained by the same Facebook core team that maintains React.

Don’t be intimidated by the idea of relying on outside libraries, though. There are many popular community-backed libraries that have even been adopted by teams inside of Facebook, including react-router, which provides a way to client-side routing; axios, which has a system to make AJAX calls that easily integrate into React apps; and redux, which is a state container that helps developers handle the flow of data in React apps.

Finding the Right Framework for You

There are ongoing flame wars online about which is the best framework for building apps. Indeed, each has its own strengths and weaknesses, which we will not get into in this chapter. They all, however, have one thing in common: JavaScript.

And that’s what we recommend: Learn JavaScript and its modern ecosystem well. Adopt Node.js, even for your client-side development, as it will bring a lot of good tooling to help bundle your code, run linters to avoid common syntax mistakes, run unit tests, and more. Once you’ve adopted Node.js, be sure to bring all your dependencies in through NPM, including your CSS dependencies, such as Font Awesome, Twitter Bootstrap, etc. Adopt ES2015 (also known as ES6) and all its latest features through Babel, which transpiles ES6 code back to ES5 JavaScript code that browsers can understand, since they haven’t been fully upgraded to support the latest features of JavaScript yet. Also, if you are a fan of strict typed languages, then be sure to look into Flow and/or TypeScript.

Once you’ve gotten a hang of tooling and the JavaScript ecosystem, and have identified which parts you like the most, pick a framework that fits your choice. Ultimately, the each framework’s goal is the same: building an awesome app. So it will be up to you to figure out if you want, for example, a more object-oriented or a more functional approach when building apps.

You’ll also have to decide how much control you want over your application’s architecture. If you want to make most of the architecture decisions yourself, then you might be more interested in bringing different libraries together, which is more compatible with how React works. But if you prefer to have most decisions made for you, and you’re okay with giving up a bit of flexibility, then maybe Angular or Ember will be the best choice, as they both provide more opinionated ways of writing your app right out of the box.

Ultimately, there is no wrong or right answer when choosing your JavaScript framework and tooling of choice, so it is up to you to figure out what works best in your situation, depending on your level of experience, how much flexibility your job provides, how much code is already written, and other factors.