dot CMS

What is a Single Page Application? (And Should You Use One?)

What is a Single Page Application? (And Should You Use One?)
Author image

Will Ezell

Chief Technology Officer

Share this article on:

In many homes and offices, use of web applications has been outpacing that of desktop applications for quite some time. Web apps are generally more intuitive to use, easier to update, and their utility isn’t restricted to the one device they have been installed on.

You may read headlines stating that users are flocking from web application to mobile apps -- and they aren’t wrong -- but that doesn’t mean that browser-based applications are dead. In fact, the existing market for web apps is actually still growing.

So, the opportunity to build and launch a wildly popular web application still exists, but how do you make the most of it?  

If you have been thinking about creating your own web app, you are probably aware that there are two primary options: single page applications (SPAs) or multi-page applications (MPAs). Of course, each format comes with its own set of pros and cons, but today we’ll be focusing on what makes single page applications an increasingly attractive option.

What Is A Single Page Application?

The term “single page application,” or SPA, is used to characterize a certain type of software application that is designed and built to operate efficiently on the web.

Like other websites, SPAs are accessed via a web browser, but they have the ability to deliver more dynamic user experiences, similar to what you might expect from a native mobile application or desktop application.

SPAs differ from traditional websites in that they greatly reduce the number of page refreshes needed to serve up the desired user interactions. They achieve this by leveraging AJAX - a tool that allows the site to exchange information with back-end servers and load data into the application without executing a full page refresh.

More directly, a single page application transfers most of the processing work to the client side, which allows the user to load a single HTML page and dynamically update the content on that page, without refreshing it, as they interact with the application.

If you’re reading this article, there’s a good chance you’ve already used a single page application today. Have you checked your Gmail inbox, scrolled through your Facebook news feed, or looked up directions using Google Maps?

Yep, those are all single page applications.

SPAs are a great option for delivering an outstanding user experience inside the browser, because they can provide intuitive user interfaces with no page reloads with little or no wait time.

But, as with most things in life, single page applications also have some drawbacks when compared to the alternative, multi-page applications. To make sure that an SPA is the right solution for you, let’s weigh our options.

Single Page Applications vs. Multi-Page Applications

If you want to understand the difference between single page applications and multi-page applications at a glance, here’s a helpful graphic from an article written by Mike Wasson on the Microsoft Developer Network

SOURCE:  https://msdn.microsoft.com/

Multiple-page applications are the more “traditional” way of delivering a dynamic user experience inside of a web browser.

As you can see in the top portion of the graphic above, every change to the page, initiated by some action that has been taken by the user, sends a request back to the server and requires the rendering of a new page in order to update the appearance of data and content from the user’s perspective. 

In the past, these applications were much, much bigger than their single page cousins, which meant they required longer load times and more complex user interfaces to function properly. Thanks to AJAX, structural complexity and the speed of data transfer isn’t as much of a concern, but MPAs are still more difficult to develop than single page applications.

Single Page Applications Vs Multi Page Applications

The theory behind how SPAs and MPAs work isn’t hard to understand, but what about the pros and cons of each model when they are actually put into practice?

Here is a snapshot of the advantages and disadvantages that SPAs and MPAs bring to the table, respectively:

Single Page Application (SPA)

Advantages:

  • SPAs are fast, since most resources (Ex: HTML, CSS, Scripts) are only loaded once throughout the lifespan of application.

  • The product development is simple and streamlined. You don’t have to write code in order to render pages on the serve. In fact, you can usually get started without using any server at all.

  • You can debug single page applications using Chrome, which allows you to monitor network operations, inspect page elements and examine the data associated with individual elements.

  • The back-end code can be reused to develop a native mobile application.

  • SPAs send one server request, store the data locally, and retain the ability to use that data over and over again without another request, even when the user is offline.

One of the most significant advantages of SPAs is their ability to load all the data in one request. This structure ensures that the user does not need to make multiple requests to the server every time they want to see new information since all the application content goes to the client in one trip.

Since all the content, template and data are all preloaded, SPA can deliver faster page navigation, browsing, and performance. Providing a better user experience as a result.

The development, deployment, and debugging processes also make SPAs easier for developers. These applications rarely require any server-side coding and can be deployed to a server much like a typical web page. Programmers can also debug single page applications using the Chrome browser, which gives users the capability to monitor network operations, examine individual page elements and review the data connected to each element.

Drawbacks:

  • This is an evolving situation (read: getting better), but it can still be very tricky to conduct search engine optimization on a single page application because of its use of AJAX.

  • The initial data request can be slow to download, because heavy frameworks have to be loaded to the client side.

  • If users have JavaScript disabled for any reason, it won’t be possible for an SPA to appear or function as intended.

  • Compared to multi-page applications, SPAs are less secure. Theoretically, an attacker could inject malicious scripts (client-side) that would directly affect users.

While SPAs are fast and easy to operate, that speed comes at a cost, The high amount of content on a single-page application can make it slow to load on initial server request. If the page takes too long to load, the client could lose out on views and conversions. Also, since SPAs are heavily dependent on JavaScript to enable their functions, users who have turned off JavaScript in their browsers may not be able to access all of the application’s features and functions.

Another notable disadvantage is that optimizing an SPA for search engines can be problematic. The use of AJAX (Asynchronous JavaScript and XML)  to load the content without calling to the server to refresh the page makes it difficult to optimize the content for search engine crawlers, which could lead to lower search engine rankings and lower visibility. However, this is an issue that is continuously being looked into and reviewed.

Single Page Application Examples

Social networks and websites that display news feeds will often leverage single page applications to streamline the customer experience. However, newsfeeds aren’t the only examples of SPAs at play. Here’s a short list of SPAs you’re probably using regularly.

  • Facebook

  • LinkedIn

  • Twitter

  • Gmail

  • Netflix

Multi-page Application (MPA)

Advantages:

  • Multi-page applications are a great option for products where users need a visual map of where to navigate inside of the application.

  • MPAs are much easier to manage when it comes search engine optimization. They afford more control and flexibility around optimizing individual pages for specific keywords.

A major advantage of multi-page applications is that each page can be tailored for search engine optimization with specific keywords and content. Also, each page can contain Google Analytics tags, which can help site owners determine which content is reaching clients, which content is receiving the most interaction, and where visitors are finding out about specific types of content.

Drawbacks:

  • There is no option to re-use the same back-end code to develop a mobile application.

  • Front-end and back-end development has to work in unison, which could require additional time and resources.

  • In general, product development for MPAs is more complex. Developers often need to use independent frameworks for client and server side functionality, which again requires more time and resources.

The additional levels involved in multi-page applications require a much more complex development process. The front-end and back-end systems may be developed independently but must work together to ensure that the user has a smooth experience. This split between the front and back ends also makes the debugging and maintenance processes much more difficult, which can lead to longer downtimes and loss of revenue.

Plus, if a multi-page application is too large and complex, it will have slower page loads, leading to a poor user experience.

Multi-Page Application Examples

Multi-page applications are often used by companies that want to offer multiple levels of static content, such as a blog, a set of landing pages, or corporate web application. Industry-leading brands have largely moved away from MPAs, but if you’ve ever used a web application that directs you to a new page, or refreshes your current page whenever you interact with it, you can be sure that you’re using a multi-page application.

What are Your Objectives?

Prior to building and deploying any web application, you first need to determine what the your strategic objectives are.  

  • What are the goals that you have for the product?

  • What are the expectations that your users or customers have for the product?

  • What is the functionality that is required to make both of those dreams a reality?

As an example, let’s say that you run an eCommerce site or you publish a lot of written content that needs to be searchable and you know that users will want to have the ability to filter a large and growing inventory of items by a selection of tags or categories.

In this particular instance, you might want to opt for a multi-page site that will handle the complex information architecture while providing an intuitive set of buttons or menus that users can leverage to find exactly what they are looking for. 

On the other hand, maybe the data queries that are generated by user interactions are not numerous enough to warrant an MPA, so a single page application would be a faster, simpler, and possibly cheaper solution. 

The primary takeaway from this comparison is that deciding whether or not a single page application is the right format for your product should begin by taking stock of the objectives that you have for the product and the specific needs of your users. 

Both models come with inherent advantages and disadvantages, but when deployed in the right situation, single page applications can provide an outstanding experience for the end user while saving you time and money.

Why Are Single Page Applications Becoming Popular?

There is a growing sentiment that in the near future almost everyone will use single page applications to deliver a delightful user experience in the browser.

This is supported by data sources like the one below, which shows that interest in developers who are proficient in AngularJS - a programming language that is an integral part of developing single page applications - has skyrocketed.

spa-graph-1.png

SOURCE:  https://aimconsulting.com/

Making the Transition from MPAs to SPAs

When we take a step back, it’s not hard to see why plenty of large companies are making the transition from MPAs to SPAs: 

  • They are simple to deploy and easier to iterate on over time. There is more control when it comes to versioning and walking back unwanted changes.

  • They are less complex, which means they can be developed faster and are easier to debug when something goes wrong.

  • They provide a better user experience, because pages aren’t constantly being reloaded while the website calls for data from a back-end server

  • They give developers a re-usable codebase that can be tweaked to produce a native mobile application. The usage of mobile devices for research, social interactions, and shopping has also taken off, so the impact of this ability should not be underestimated.

Sure, they come with some downsides, but every day there are smart people who are coming up with clever ways to overcome those hurdles while still capitalizing on all of the upside that SPAs have to offer.

Imagine a world where Amazon.com was just as amazing, but was also more SEO-friendly, had fewer page refreshes, faster loads times, and an improved user interface that got you to exactly the product you’re looking for, only much faster and with fewer headaches. 

That’s where web applications are heading and single page applications will almost certainly be a large part of the final solution. There may be some growing pains along the way, but all signs point to SPAs playing a significant (and increasingly important) role in how we design the next generation of consumer web apps.

What are Hybrid Applications?

If you’re looking to balance the advantages of both SPAs and MPAs for your next project, then you’re not alone. Many developers are working on combining the ease-of-use that comes with SPAs with the depth of content found in the multi-page variety. The result of this unification is referred to as a hybrid application.

These hybrid applications function much like an SPA that employs URL anchors as synthetic pages to mimicking the site navigation functionality traditionally found with multi-page applications only. Alternatively, developers might deploy multiple SPAs which share data between themselves. This is achieved by combining single page applications with a server-rendered shell application.

Uses for Hybrid Applications

A hybrid application can be highly useful for clients who want to have the speed that comes with the SPA model, while still delivering a full range of content. Although this appears to be an optimal solution, it doesn’t always work out that way. The development process still involves some coordination between the front and back ends, while the user may still experience slow load times or difficulties with browsers that do not accept JavaScript.

But to successfully operate a hybrid application, you need to optimize it and pinpoint any user experience areas where your user could benefit from having an SPA delivery, and where they would benefit from multi-page delivery.

Single Page Application Development: Things to Keep In Mind

When it comes to developing Single Page Applications, there are some pitfalls and things to keep in mind, as it’s not as simple as coding a normal website or mobile application. Below, we’ve listed key things to remember during single page application development.

1. Providing End Users With Browser History Gets Tricky

Typical websites that run in HTML run on multiple pages. Browsers are familiar with this concept of a website and so easily accommodates for interaction and navigation through websites like these.

Creating an SPA means that certain common functionalities of a browsers become non-functioning such as the “Back” or “Forward” button on a browser as all data is now stored within one container on one page.

In order to combat this the SPA must mimic a typical HTML website, but with JavaScript. This means having a way to emulate the navigational structure that a normal HTML page may use.

2. Search Engine Optimization Gets Trickier

Search engines such as Google and Bing work by reading HTML data of websites when you enter a search. With standard HTML websites storing pages in a hierarchical format with data on each, a search engine has a lot to work with in terms of searching and finding.

Not forgetting that data within an SPA is all held within a single page and may not hold explicit links to its content, this brings up the issue of your website not being as easy to find search-wise.

One way of mitigating the drawbacks of this is to create a sitemap for your website. This will allow search engines to search and find your websites on a deeper level.

With dotCMS you can expose your content through two ways, using either ID’s or slugs:

ID URL: http://localhost:8082/recipes/3fdc86d5-76fe-48c2-9ed9-24dba3c7c78b

The ID URL relates to each element within the SPA such as an image or text container. The purpose of this URL is to allow your SPA’s router to know which content to find and show.

Slug URL: http://localhost:8082/recipe/fiery-chipotle

The slug URL contains relevant words, all of which should relate back to the data the page is trying to convey. These are much more human-friendly and clean, they should not contain any hashtags but if your links do you can get around this by using your router.

Learn More: Single Page Applications & SEO: How to Make it Work

3. You May Be Unable to Capture Elements with Automated Testing

The most commonly used automated softwares and API’s function by knowing when a website is fully loaded, and by being able to capture paths to relevant elements on a webpage. Without these explicit connections to the data that the automation needs, it is unable to properly assess anything let alone continue on its intended path.

An SPA may have areas of its website which are constantly polling for changes either from the user or servers that it runs on, which gives the feeling of a “live” page. The problem with this is that when looking for elements that you want to capture though automation they can be ever changing or not there when you need them.

dotCMS’s previously mentioned routing, paired with other kit features will help to mitigate this.

4. You’ll Need to Make Plans to Accommodate Analytics

Analytics may be used to track data points within a website such as traffic flow on a website and page level, length of time on a page and the number of clicks that an element receives.

Since most SPAs are javascript and not technically made of “pages” this creates problems for these analytical softwares. To avoid this you will need to create a pseudo hierarchy of the pages elements with which analytics are able to interact, such as through routing as mentioned before.

This should not be a worry if your website is only intended for encapsulated usage, such as for an intranet site, but if your website is intended to be used on a much larger scale then this should be considered greatly.

dotCMS makes use of Google Analytics to allow you to track and report usage of your SPAs. The codes given through Google are simply attached to the content within your website via the dotCMS GUI, which once again helps to streamline single page application development.

Choosing Between SPA, Multi-page, and Hybrid Applications

The choice between SPA, multi-page, and hybrid applications lies less in what kind of experience you’re looking to deliver.

To make the right choice, measure the voice of the customer, evaluate your technology (along with your ability to procure single page application-building software), and—if you are leaning towards an SPA or hybrid solution, consider what you’ll need to do in order to manage single page applications.