Single Page Application - Pros and Cons

In the early days of the Internet, mostly web sites consisted of largely static pages that filled with content but expecting minimal interactions from the end user. As the Internet grew over the past few decades, however, many web sites began seeking ways to interact with their users; creating a more streamlined and fluid user experience for these interactions. As IFrames were used to allow small modules of content to be dynamically loaded without requiring a reload of the entire web page. Shortly after, the Ajax specification was evaluated as an enhanced method of implementing web applications that could maintain their current state while still communicating with a server in the background. This ability to dynamically load content and modify the state of the page without actually requiring a new page to be loaded led into the conception and design of Single-Page Application or SPA.

An SPA is a web application that fits on a single page rather than the more traditional Multi-Page Websites. In an SPA, different content can reside in different ‘states’ of the page, instead of requiring a new page. One modern example of an SPA is Gmail. Whether we are switching mailboxes, opening an email, or writing an email, it always remain on the same page: it is merely the content of the page that is updated to reflect the current state of the application. Other popular examples are Rally etc. Over the past several years, SPAs have been rapidly growing in popularity, particularly with the advent of newer JavaScript frameworks such as Backbone, Angular, Ember, React, which have adopted SPA principles to simplify the creation of scalable, extensible Single-Page Applications.

SPAs have certainly become popular for their fluid user experience, but there are still a lot of websites built across multiple pages. When designing a new web application, should you go with a Single-Page Application or a Multi-Page Website, and there are few factors to be considered.

Advantages

• Easier state tracking - It is easier to switch states between pages using routing for SPA applications.
• Boiler plate content that is on every page (header, footer, logo, copyright banner, etc.) only loads once per typical browser session.
• No overhead latency on switching pages.
• SPA applications can be extended to provide offline support.
• SPA applications are good for mobile first approach for web pages, that supports mobile and desktop devices with the same page model.
• REST easy - it is easily integrated with REST endpoints.

Disadvantages

• Performance monitoring - Most browser-level performance monitoring solutions we have seen focus exclusively on page load time only, like time to first byte, time to build DOM, network round trip for the HTML, onload event, etc. Updating the page post-load via AJAX would not be measured. There are solutions which let us instrument to record explicit measures, like when clicking a link, start a timer, then end a timer after rendering the AJAX results, and send that feedback. New Relic, for example, supports this functionality. By using a SPA, there are fewer tools to support for performance monitoring considering all the aspects for websites.
• Security / penetration testing - This issue is not unique to SPAs, we have to deal with security in exactly the same way as client-server app (the HATEOAS model of using Hypertext to link between pages). It's just that the user is making the requests rather than JavaScript, and that the results are in HTML rather than JSON or some data format. In a non-SPA app we have to secure the individual pages on the server, whereas in a SPA app we have to secure the data endpoints.
• Bundling: It is easy to get into a situation when we are downloading all of the code needed for the entire web site on the initial page load, which can perform bad for low-bandwidth connections. We could bundle your JavaScript and CSS files to try to load in more natural chunks as we go, but now we need to maintain that mapping and watch for unintended files to get pulled in via unrealized dependencies. So bundling on demand for modules per page is doable, but with a cost.
• Big bang refactoring: If we want to consider a major architectural change, like say, switch from one framework to another, to minimize risk, it's desirable to make incremental changes. That is, start using the new, migrate on some basis, like per-page, per-feature, etc., then drop the old after. With traditional multi-page app, we could switch one page from Angular to React, then switch another page in the next sprint. With a SPA, it's all or nothing. If we want to change, we have to change the entire application in one go, otherwise it will be overhead for bundles and there may be other consequences for side by side executions.
• Complexity of navigation: Tooling exists to help maintain navigational context in SPA's, like history.js, Angular 2, react, most of which rely on either the URL framework (#) or the newer history API. If every page was a separate page, we don't need any of that.
• Client must enable javascript: This is a clear disadvantage of SPA.
• Only one entry point to the site: It is not very straight forward to manage multiple endpoints for SPA for deep linking.Using SammyJS and routing properly set up, user will be able to create deep-link bookmarks into SPA app that work correctly. The client-side JavaScript will handle the actual entry into the application.

Improve supports for SPA applications

There are few other potential pitfalls to at least be aware of, although modern frameworks and best practices make it easy to resolve all of these issues.

• Managing browser history: One concern that has been raised with SPAs is the handling of navigation within the browser. With the dynamic loading of modules, it is possible to change states without the browser knowing, and as a result essentially breaking the forward, back, and reload buttons of the browser. However, this is something which has been resolved in modern browsers with the introduction of the history.pushState() and history.replaceState() methods.
• Search Engine Optimization: In the past, there has also been concern with Search Engine Optimization as it related to SPAs, but as SPAs become more common, this has become less and less of an issue. Google, Bing are able to fully crawl websites using either the SPA or MPW[i.e. Multi Page Web] architecture without any issue, as many of the more popular search engines.
• Web Analytics : Web Analytic are the medium to capture the traffic on pages, modules or even on certain links on a page. Support for web analytic for SPA application has been extended , so we can capture almost every traffic for SPA.

Please share your comments, if any.

Happy reading.