Single Page Applications: When and Why You Should Use Them


Single Page Applications vs Multi page Applications Pros and Cons

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 up front. The SPA 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 SPA 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 SPA frameworks, so your team can make the decision based on information – not ego!

The road to Single Page Applications

Before the first SPA 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 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!

The road to the Single Page Applications we have today was far from a linear process. Other technologies, Flash and Silverlight for example, introduced rich internet applications (RIAs) that moved away from Javascript entirely. And while they were initially well received by the development community, their need for 3rd party browser plugins limited adoption and they are now considered legacy frameworks.

Back on the Javascript bandwagon, the 2009 release of Backbone.js offered developers a  lightweight client-side framework. You could build a SPA with Backbone, but took a lot of work and repetitive code. It wasn’t until 2010 that all these disparate ideas were brought together with the release of Angular.js. By providing client-side Model-View-Controller (MVC) architecture, two-way data binding, templates and dependency injection in one framework, Angular.js became the first true SPA solution.

The MPA (traditional web application) legacy

MPAs still form the vast majority of web applications online. While this is partly due to a head start over Single Page Applications, there are many use cases where building an MPA is simply the better option.  In fact, many of the web’s most popular websites have opted to remain as MPAs.  These include Stack Overflow, Amazon and most WordPress-based sites. MPAs have a long track record and are proven to work great for a variety of applications.

So, how can you decide which option is best for your project? The key to choosing the correct framework lies in understanding your project’s requirements and how they map to your technology needs. I’ve prepared the comparison below to aid in this effort.

MPA Pros & Cons 

User Experience

Green Flag Single Page Applications vs Multi Page ApplicationsMPAs are a simpler option when designing monolithic applications with only one state section.

Green Flag Single Page Applications vs Multi Page Applications The initial page load is normally faster than the initial page load of an SPA.

Red Flag Single Page Applications vs Multi Page ApplicationsSubsequent pages take equally long to load because a request is sent to the server for data and UI rendering.

SEO

Green Flag Single Page Applications vs Multi Page Applications SEO is easier and more effective as most search engine crawlers were built for MPAs.

Security

Green Flag Single Page Applications vs Multi Page Applications Requests are handled by the server and most MPA frameworks present tried and tested security.

Development

Green Flag Single Page Applications vs Multi Page Applications Most developers will have MPA experience already.

Green Flag Single Page Applications vs Multi Page ApplicationsMPAs are supported by many popular debugging tools included in Integrated Development Environments (IDEs).

Red Flag Single Page Applications vs Multi Page Applications  Not all code can be re-used for a mobile version of the application which means extra development time.

Cost

Green Flag Single Page Applications vs Multi Page Applications MPAs are generally cheaper to build because they use more established technologies and there are more developers in the market.

SPA Pros & Cons

User Experience

Green Flag Single Page Applications vs Multi Page Applications Pages load faster when a user navigates within the application which results in a “snappier” user experience after the initial load.

Green Flag Single Page Applications vs Multi Page ApplicationsMore advanced, richer applications can be built with Single Page Applications

Pros and Cons of SPAs and MPAsIt takes more time to initialize the application as it has to be downloaded to the user’s device. But this can be improved by server-side rendering.

Red Flag Single Page Applications vs Multi Page Applications SPAs require the user to have JavaScript turned on.

Red Flag Single Page Applications vs Multi Page Applications Memory leaks in JavaScript can lead to a drop in performance (or crash).

Red Flag Single Page Applications vs Multi Page Applications Enterprise apps can be harder to design and maintain as SPAs due to the larger number of files generated as well as the need to maintain two states between the SPA and the RESTful API.

Red Flag Single Page Applications vs Multi Page Applications SPAs can drain battery power faster than MPAs, as there is a bigger workload on a device’s browser.

SEO

Pros and Cons of SPAs and MPAsSEO optimization can be less effective with content loaded through AJAX. This is because SEO crawlers mostly rely on stable content within distinct pages. This is rarely an issue as Google now crawls SPAs with high fidelity. 

Security

Pros and Cons of SPAs and MPAsJavaScript is not a compiled language so the source code can be potentially exposed to malicious users. Steps can be taken to ensure this does not happen. Such as working with a senior developer to ensure that critical business rules are not handled by the UI.

Development

Green Flag Single Page Applications vs Multi Page ApplicationsSPA frameworks can be used to develop mobile applications that facilitate code reusability down to the level of UI elements.

Green Flag Single Page Applications vs Multi Page Applications Smart developers are excited to work on Single Page Applications since they are new and are likely going to be used even more in the future

Pros and Cons of SPAs and MPAsThis is a relatively young technology but the active community means that many issues associated with SPAs are getting resolved.

Red Flag Single Page Applications vs Multi Page ApplicationsSingle Page Applications require more effort and knowledge to debug. This is because developers have to use their browser’s development tools rather than IDEs.

Red Flag Single Page Applications vs Multi Page ApplicationsSPA code can be hard to trace. Especially when integrating third-party modules and plugins.

Red Flag Single Page Applications vs Multi Page ApplicationsSingle Page Applications are newer and your development team will need to be familiar with the specific framework and tools (eg: NPM, Webpack, SystemJS, Gulp). These skill requirements can increase the hourly rate of your developer(s).

Cost

Red Flag Single Page Applications vs Multi Page ApplicationsSingle Page Applications are generally more expensive to build because they require developers to know newer technologies. Debugging is slower and harder. There are also fewer 3rd party libraries to use to keep costs down.

Popular Single Page Application frameworks

If you have decided that building an SPA best suits your project, there is still the small matter of selecting an SPA framework. This is a hotly debated topic (I’m not kidding, typing ‘Angular vs React’ is like stepping into a war zone) and one that is beyond the scope of this article.

SPA vs MPA. Single Page Applications vs Multi Page Applications

But I will leave you with a list of the 5 most popular and well-supported options. I suggest you apply the same rigorous analysis we carried out above to select the most appropriate framework for your project.

Final Thoughts

Improvements in the “snappiness” of an application and a richer, more immersive user experience are often cited as key reasons to go with Single Page Applications. The recent SPA redesigns of streaming music site Pandora and Google’s Gmail platform are great examples of this in practice. But, as we noted with Twitter, these benefits are not guaranteed. It is vital to take a considered, project-by-project approach to choosing your technology stack. Not doing so can result in emotions or social pressures hijacking the decision process.

The risks fall into a few broad categories: talent skills, talent cost, stability, SEO, and security. These shortcomings are not unusual for a new technology and are being fixed at pace thanks to an active and motivated community. They are, however, still factors that need to be considered in your decision-making process. If you find you are struggling to find the right talent for your project why not get in touch. Sourcing great talent is what we do best at Scalable Path. 

The good news is that this decision does not have to be as black and white as it may appear. In certain cases, a hybrid web application could be a viable option. Many popular platforms are doing just this. Facebook, for example, retains an MPA framework for its website but sprinkles advanced JavaScript into certain sections where a rich, snappy user experience is crucial. This hybrid approach is also a valid path particularly if a large MPA is already in place.