In the early days of the Internet, most web sites consisted of largely static pages 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. To this effect IFrames were created to allow small modules of content to be dynamically loaded without requiring a reload of the entire web page. Shortly after this, the Ajax specification was adopted 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 design of Single-Page Applications, or SPAs.
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 that many Internet users are familiar with is Gmail. Whether you are switching mailboxes, opening an email, or writing an email, you 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. Over the past several years, SPAs have been rapidly growing in popularity, particularly with the advent of newer JavaScript frameworks such as Backbone, Angular, and Ember, which have adopted SPA principles to simplify the creation of scalable 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 what factors should be considered? The fact is, there is no perfect answer to that question, and for different companies and different applications, the answer may change. SPAs are designed for a more fluid user experience – especially when the user is interacting with the application – but this becomes significantly less noticeable if the website in question minimizes user interaction. Websites whose focus remains primarily on content consumption (eg. blog sites, news sites, and online encyclopedias) expect very little interaction from the user and may not fully benefit from the advantages of a Single-Page architecture.
Single-Page Applications also present different challenges that developers of Multi-Page Websites may not be looking out for. One primary concern is the additional overhead; by their very nature SPAs tend to be slower on initial page load since they require loading the framework and the application code prior to rendering the required view in the browser. By contrast, a server-loaded application would only have to push the required HTML to the browser. It is possible to speed up the initial page load through caching, optimization, and lazy-loading modules on an as-needed basis, but the speed difference is a small trade-off to consider between the two design models.
There are a couple other potential pitfalls to at least be aware of, although modern frameworks and best practices make it easy to resolve all of these issues. One concern that has been voiced 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. Older browsers which do not support these new functions can also easily handle browser navigation through techniques such as hash-based routing.
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 is able to fully crawl websites using either the SPA or MPW architecture without any issue, as can many of the more popular search engines. There are likely some search engines that still do not crawl non-static pages, but it is left up to the developers if reaching the audience served by these few limited search engines is crucial enough to offset the user experience benefits inherent in SPAs.
One final concern with adopting SPAs is largely non-technical: considering the legacy code and current developers for an application. Switching an existing web application to a Single-Page architecture is not trivial, and given project timelines, engineering knowledge, and resources, maintaining and enhancing a Multi-Paged Website might be the most efficient solution. For other applications, the more streamlined user experience offered by SPAs might be essential. For each application the intended audience, available developers, and resources have to be individually weighed to determine what architecture makes the most sense.
What about you? Have you used Single Page Applications? Leave a comment with your experiences to start a dialog.