Design Thinking Process

Should It Be A Single Page App?

Should It Be A Single Page App?

It’s a question every developer faces when creating a web product: use emerging technologies and build a single-page application, or stick to the traditional route of a multi-page concept? The answer has implications in terms of cost, complexity, flexibility and, perhaps most importantly, user experience.

Over the past 5 years, the team here at Handsome has built dozens of web applications. They all vary in size, complexity and purpose. During this time the world of web application development has divided into two categories: single-page applications (SPAs) and multi-page applications (MPAs). Let’s start with some simple definitions.

The multi-page application (MPA) is the traditional way of building web applications. In an MPA, every attempt to display data or submit data back to the server requires a request of an entirely new page that is then rendered in the web browser. With the introduction of AJAX, it became possible to refresh only parts of the page, rather than the whole page. As a result, user experience improved dramatically, although technical complexity increased as well.

“So why not build every site as an SPA? That depends on the goals of your business and the purpose of your site.”

The single-page application (SPA) is essentially an evolution of the MPA+AJAX pattern. In an SPA, displaying new data doesn’t require requesting a whole page; instead, only the necessary new pieces of data are requested through an API, and a Javascript framework on the front end refreshes certain parts of data on the page, or the page as a whole.

The web experience we created for Walsh, an innovative master-planned community in the Dallas/Ft. Worth area, is a good example. Here you can see the elegant transitions that are possible in an SPA.

So why not build every site as an SPA? That depends on the goals of your business and the purpose of your site. Let’s take a look at the advantages and disadvantages, to show you how we decide here at Handsome.

SPA Advantages

More control over the user experience. Very often, this is the determining factor. With an SPA, you are no longer dependent on how the browser behaves when it loads new pages, or when certain action are performed within the page; rather, you, as a creator, control the way browser behaves when it makes requests for new content, when it receives new content or when it interacts with the user. A majority of award-winning websites and applications are built as an SPA precisely for this reason.

Lighter request load. An SPA makes fewer resource requests in general. But even more importantly, since the browser doesn’t load every page from scratch the requests made can be much lighter than in an MPA.

Less server-side load. Instead of generating pages for thousands of users, the server only transmits the necessary pieces of data – and the browser on those thousands of machines generates the front end. With the capacity of modern day computers and mobile devices, and as long as the application is programmed properly, users will never see any slow-downs in the experience. In fact, it’s quite the opposite: because the server isn’t overloaded anymore, it responds to the browser’s requests much faster!

Ability to use existing APIs. If you already have a mobile application that is communicating with the API on server side, more often than not you can use the same API in an SPA, with no or minimal adjustments to it. And if the mobile application is in the planning stages, creating an API for an SPA will save time later on.

SPA Disadvantages

Tricky SEO implementation. This might be tough, although it’s most certainly possible. This is due to the fact that search engines like seeing server-generated pages with static content on them, and they might not work so well with pages that are designed to be generated on a client (in browser). Worth mentioning, Google claims they can now crawl dynamic pages, but Google engineers mentioned it doesn’t always yield ideal results. We recommend following progressive enhancement practices through adding server-side rendering, allowing the server to pre-render pages for search engines and users without JS enabled in their browsers; luckily, many modern SPA frameworks support that functionality, to some extent. Note that SEO is only a concern with marketing sites; you most likely won’t need search engines to go behind authentication forms on the website, which is where SPA interfaces usually are.

Memory leaks. Because the experience is now very JS-heavy, it’s very easy for memory leaks to appear during long periods between page reloading, if the application is not developed carefully and tested thoroughly.

Adapting for third-party tools. Those that aren’t adjusted for usage in an SPA will require some extra time to implement. With a multi-page application, all you usually do is drop those couple lines of code onto the page. With a single-page architecture, certain events, such as page or URL changes, might have to be handled with extra code triggered through application routing.

Unexpected behavior of the browser’s “Back” button. Browsers by default don’t support dynamic content loading, so instead of going to the previous state of the application you would end up going to the actual previous page that the browser remembers. Luckily, this is easily resolved through an HTML5 History API and is already included in most modern SPA frameworks.

Managing user-initiated requests. Due to the asynchronous nature of an SPA, this might be tricky. Imagine a user clicking a button, and while waiting for the result to load, he clicks a couple more buttons. With an MPA, it’s very straightforward: the browser will just stop any previously started actions and only perform the latest. With an SPA, responses from the backend come in an asynchronous way, and not necessarily in the order that the buttons were clicked, since the server might have completed the latest request faster than the one before that. As a result, the application code will need to explicitly manage situations like this to avoid any confusion in user experience and business logic.

An SPA requires an API on the server side. The client side of the application requires end-points to fetch data from and push data to. This is both an advantage and a disadvantage, depending on the particular case.

 

Both modern single-page applications and traditional multi-page applications have advantages and disadvantages that should be carefully considered and the cost and benefits compared, whether you plan to build a full-scale digital product or a simple marketing website. We always like to remind our clients that, while an SPA might require more development efforts to build, with proper design and execution it results in a user experience that could never be achieved with an MPA. In the end, the question to ask is: Is it strategically important for this product to have an excellent user experience, or will an ordinary experience suffice?

Other Journals