Why we love Single Page Applications built in React
Web applications come in many shapes and sizes. They serve different functions and different audiences. They inform, entertain, sell and more - but each one relies on a smooth-running user interface. Until fairly recently, most web applications were based on what is known as the Multi-Page Application (MPA) approach: each navigation or interaction performed by the user is sent to the server, which renders and sends back a whole new page of HTML to reflect the changes. In other words: a full page reload is required every time the screen needs to update.
The new(ish) kid on the block: Single Page Application
MPA’s younger brother, the Single Page Application (SPA), has only been around for a few years, but is already wildly popular in the development of modern web applications - and with good reason, in our humble opinion! However, as with any aspect of software development, it’s not necessarily the right choice for every problem.
One of the first questions to ask yourself when starting out on a software development project is whether you need a Single Page Application (SPA), or whether a traditional Multi-Page Approach (MPA) would work better. Which one is the best fit for you? As usual, the answer is: “it depends”, but there are a number of reasons why a SPA approach might be preferable.
Why choose a Single Page Application (SPA)?
First, let’s look at what a Single Page Application (SPA) is. In simple terms it does what it says on the tin: serves an interactive web application from a single page. Rather than loading a new page of HTML from the server each time the user clicks on something, as a multi-page web app would, a SPA dynamically updates the current page on the client-side using JavaScript.
Behind the scenes, the web page communicates with the server by sending requests in the background. These background requests (known as AJAX requests) ask only for what’s needed to update the page, and do not prevent the user from interacting with the application while they load. The data that comes back from these requests is much smaller, and therefore quicker to receive, than the traditional reams of HTML travelling back from the server.
Some examples of SPAs that you’ve probably used (or at least heard of) include Facebook, Twitter, Google Docs, Google Maps, and Gmail.
So, why choose a SPA approach? There are a number of reasons, from both a developer point of view and a user experience point of view. For one thing, your end users will have a much snappier experience, with less waiting around for pages to load. Users are impatient and won’t tolerate staring at a loading bar or unresponsive screen. They expect web apps and mobile apps to react as quickly as, if not more quickly than, their old-fashioned desktop software.
At Ghyston, one thing we really love about building a SPA is the positive impact on the development process. SPAs are much quicker to write because developers can leverage the component-based nature of modern frameworks to reuse the code they write across different parts of the application, and work more easily in parallel with each other.
There are higher initial setup costs involved because the development work needed to start using a SPA approach is heavily front-loaded. However, once that setup is complete the rest of the code can be created more quickly and more efficiently, which helps reduce the budget overall - especially if you’re planning on adding more complex features further down the line.
SPA frameworks - introducing React
There are a number of different frameworks you can use to create a SPA. The three that have emerged as the most popular over the last three or four years are Angular (written by Google), Vue (an open source project), and React (written by Facebook).
Every development team will have their favourite framework, and for us it’s React. Mostly the reasons are a bit on the technical side. For example, React code is written in a declarative style. For you this means that the focus is on the end result of what should be shown, rather than the details of how to achieve that. You tell React what you want the page to look like, and it figures out how to get there from what is currently shown. By contrast, an imperative style requires you to spell out what updates needs to be performed in order to achieve the desired result.
As I’ve already alluded to, another reason we like SPAs is because of the component-based approach taken by many modern frameworks such as React. Instead of having each page of your website defined in one enormous code file, each element of your user interface can be split out into its own file and written as a self-contained unit. This makes code easy to reuse, and it allows different developers, or even teams of developers, to work on different isolated parts of the codebase in parallel. With React there are big advantages for clients who require multiple different web applications, as components written in one application can be pulled out and shared easily with others.
And then there’s the wider React ecosystem or community, which is very active and forward-thinking. We’ve found that, thanks to the large number of people creating SPAs with React and sharing their code, we can save huge amounts of time (and therefore budget) for our clients by pulling in open-source packages to solve common problems rather than starting from scratch each time. Of the three most popular SPA frameworks, React offers the greatest variety of easy-to-use, off-the-shelf, reusable component packages.
Making the ‘right’ choice
There are no hard and fast rules for whether or when you should choose a Single Page Application over a traditional Multi-Page Application. Or indeed whether, having chosen to go down the SPA route, you choose React above another tool. After all, there is no silver bullet that will solve all your software development problems!
Much of it will be down to the problem you’re trying to solve, and the experience of the development team you’re working with. But React has a lot of fans (ourselves included), and when it comes to tech, tools are usually popular for a very good reason. What it boils down to for us is the fact that the code is easy to understand, and therefore debug and update, and we also get far fewer user interface bugs. All of this means we can do our job more quickly, more efficiently, and more effectively - delivering the right solution for our clients in good time and within budget.
