Spiria logo
Interested by the tech world?
You will receive weekly the blog posts written by our geeks.

Single-page application, pros and cons

Single-Page Applications (SPAs) are web apps that interact with users by dynamically updating the current page rather than loading whole new pages from a server. This strategy creates a fluid web experience by avoiding the interruptions caused by consecutive page loading from a server. With SPAs, all the necessary code — HTML, CSS and JavaScript — is included in a single page, with additional resources dynamically loaded and embedded into the page as needed, responding to the user’s actions.

These applications are essentially based on JavaScript, which can display the user interface, execute the application logic and communicate with a web server. Their recent surge in popularity is tied to Javascript frameworks (AngularJS, Ember.js, Meteor.js, React, Vue.js, etc.), which make them easier to create than if they were coded from scratch. Other tools can also be used, such as Google Web Toolkit which allows to develop the application in Java, a cross-compiler translating the code in JavaScript.

SPA requests sent to the server are either structured data (XML/JSON) or chunks of HTML code to embed into the DOM. The server is relieved of the task of building views, as everything is handled by the client.

While at first glance SPA development may seem the simplest, easiest way to go, the fact is that building a good single-page web application that provides an optimal user experience is often a complex task that poses certain challenges. The main ones are:

Interrupted Navigation

This is the most frequent problem with hastily-built SPAs. Users think they are on a new page, but the URL remains unchanged and the browsing history is interrupted. If they use the browser’s “previous page” function, either nothing happens, or to their surprise, they end up on a previously-consulted site. When returning in the application, users will curse at the programmer if this resulted in a loss of their data or of their position in the journey. Which is unfortunate, because this usability glitch is avoidable: there are several ways to create a pseudo-history that works with web browsers. Of course, this requires extra work on the developer’s part. And don’t forget to manage the beforeunload event to warn the users of the risk of data loss.

Search Engine Optimisation Problems

Search engine optimisation is partly related to the previous issue, as SPAs do not work like a traditional site. Unless developers have planned for this, search engine indexing robots don’t know what to do with an SPA. Indeed, these robots are not designed to execute JavaScript and try to understand what is going on. If referencing is crucial, then it would be best to avoid SPAs, or only partially. One solution is to develop robot-specific HTML pages that mirror the pseudo application pages, but this isn’t the most elegant solution and besides, it can lead to maintenance issues.

Compromised Accessibility

Almost all existing single-page applications are very partially or not at all accessible. The fact is that developing a decent SPA that also respects all the laws of accessibility is a major challenge. That said, all efforts to enhance accessibility, even the slightest — for example, providing a robust, valid, semantic HTML code and a browsing history — all benefit SEO.

Stuttering Statistics

Most statistical tools, such as Google Analytics, are based on the mechanism of loading complete pages. They can’t record the display of pseudo-pages generated by SPAs, since the app refreshes the display based on user actions without asking the server to get new HTML code. Since the execution is contained in the browser side, you must develop some kind of tool to track user movement within your application. In other words, you’ll need a function to keep the server in the loop and to record the state of the application at key points. It's also important to understand that if statistical services aren’t working, neither will most of the available performance-monitoring tools on the market.

Loading Time

The requirement to load large volumes of JavaScript code and copious amounts of CSS declarations takes time, delaying users’ interaction with your app. Sometimes, the delay is so long that users assume that the server is down, and they give up (developers usually have excellent Internet connections, which is not always the case for users). When applications take too long to load, the underlying code should be optimized using one or more strategies. For example, you could ask yourself whether you really need to include such a heavy CSS framework, or if you could manage with a lighter one or none at all. To continue on the topic of loading time, you could encourage users not to press “Refresh/Reload” by providing, if necessary, a visual loading indicator between pseudo-pages.

In Conclusion

Single-page applications are one of those ideas that can look good from far, but may be far from good. However, if you have good reasons to go for this solution, a quality product will require an investment in time, skills, best practices and resources. If you develop a SPA, use frameworks specifically designed for this purpose, like Ember.js, since they ease development while providing workarounds for some of the issues described above.

If you’re developing just a web site, encapsulating it in a SPA isn’t the best idea (remember: SEO, accessibility, browsing, statistics, etc.). In fact, it’s reminiscent of those sites created in Flash about twenty years ago, with similar problems, like loading times, referencing, user-friendliness, etc. In fact, if you have a look at some of the more “creative” SPA sites, you realize that some designers have recreated all of the Flash problems with modern technologies: “Look, it’s pretty, it moves, it’s interactive, it’s a rich user experience.”

The best examples of its use are those where the application, while residing on the Web, doesn’t need to “be part of the Web”. They can be a good solution if you need off-line functionality — something a Web site can’t provide. They can also be used to create more modern, functional interfaces for legacy systems, or control panels for devices. And one of their great advantages is to be multi-platform by default (Windows, Linux, OSX, Android, iOS…). SPAs are also well suited for complex applications that process a lot of data in interaction with the user. Think of the Gmail web client, for example.

To sum it up, single-page web applications are not the solution to all your problems, but they are a good choice in some circumstances. As with any technology, they have their advantages, drawbacks and challenges.

This entry was posted in Web Applications
by Laurent Gloaguen.
Share this article