Josh Lewis

Single Page Applications explained

When the complexity of a web app increases, at some point it makes sense to switch to a Single Page Application (SPA), for a better user experience and quicker development.

In a traditional web-app (that is a website that is far more complex than a static site, with functionality such as user accounts or other complex functionality) every action involves a page load.

Say we have a form for the user to create a To do list. When the user clicks 'add' the request is sent to the server and a whole new page is loaded, this page might have an error in the form or it might now display the new item in the list.

In a Single Page Application there is one initial page load when the user first visits the website, and all other page loads or actions happen behind the scenes via an API. This means Javascript (the only language available in a users browser) has to do lots of the stuff that is normally done by the server such as rendering data into templates, validating data and displaying the correct page based on the URL.

Options for building an SPA

Because the 'front-end' of the website is suddenly responsible for requesting, loading and displaying content it becomes a lot more complex than on a traditional static site. To help manage this complexity, just as on the back-end, there are frameworks to simplify common tasks.

The two big frameworks AngularJS and React were developed at Google and Facebook respectively.

Advantages of an SPA

There are a number of advantages to using an SPA over a traditional web-app. Firstly, the user experience for a complex application will normally be better, especially when handling large amounts of data. This is because only the data and not the whole site is being loaded in the background and it is easier for the site to be more dynamic. There are no page loads and everything happens very quickly.

From a business and software development perspective a SPA help split up the complexity of the app allowing two seperate (smaller and less complex) systems to be built, the back-end server and the front-end site. If the interaction between the two is well defined then this can allow much quicker development and the work is more easily spread among multiple developers.

Another advantage of building the API required for an SPA is that the same API will normally be used for any mobile apps that are built in the future.

Problems with using an SPA

Because in an SPA most content is loaded dynamically, it makes a poor choice for a site that needs to be publically visible and indexed by Google. Work arounds do exists but these must be carefully done.

Because of it's reliance on Javascript a SPA is also more vulnerable to the quality of the client or browser accessing it, with older browser support presenting a real issue.

I would also argue an SPA is harder to test, a key factor for small projects.

Deciding when to use an SPA

Deciding if to use a SPA is a complex decision that must be made at the very start of the project. An SPA will normally make sense for more complex projects that may need to scale rapidly, require users to login and might need an app either now or in the near future.

There has been a tendancy, in my opinion, to over-use the SPA structure simply for the sake of it. For all but the most complex applications a traditional web-app still makes sense.

I have experience building both traditional web-apps and single-page-applications in Angular and am happy to advise on future projects.