Single Page Application (SPA) is an old, yet only lately popular way of creating programs for the web. The idea is to fetch most of the resources from the server when user loads a website and then, as the user interacts with the site, fetch and store data via calls to an API endpoint (typically REST). In effect, page is never reloaded, wich makes the expecience more smooth than with traditional webpage. This article highlights main characteristics of SPA and specifies conditions under which the concept is preferably applicable.
With recent advent of client-side frameworks (AngularJS, EmberJS, MeteorJS, ReactJS), SPA gained much more attention in the community. New frameworks provide new abstractions that force good client-side programming techniques. Creating rich web clients is now much easier and faster. Despite the benefits that come with new frameworks, SPA isn't always considered the right way to write software for the web and not all new web projects end up being SPA.
Pros
- Application can be usable when offline. An example of popular SPA, that is connection-aware, is GMail. When user goes offline, functionality is very limited, but the app is still usable. This makes the client fault-tolerant. Things can be taken one step further. Since HTML5 brings multiple client-side storage technology to the table, server-side storage may be used only as backup and synchronization medium1.
- Application can respond very fast after each click. According to research done at Google, user feels that application is fast and responsive only if it gives him a feedback after less than 200 ms. If operation lasts longer (potentially), an indication of operation in progress should appear (e.g. spinner or progress bar). These requirements may be hard to achieve with traditional server-side HTML rendering. SPA makes it much easier.
- API is a well defined boundary that slows down software entropy. Sole fact that there is an API to be designed forces a very good practice of actually designing the software. Lack of well defined boundaries may (in time) lower maintainability of a system, because of accidental inter-dependencies being added.
- Moving presentation logic to the client reduces the need for server resources. Total cost of the system may be reduced significantly, depending on the technology at use and size of the part that handles presentation3. This point gains weight with rescent popularization of many IaaS solutions, where payments are directly dependent on resources at use.
- Modern ways of creating sofware increase morale. New things are more exciting and give people a space to grow. This can be a big factor affecting team's productivity.
Cons
- Multiple programming languages used in one project. Either people of two skillsets (client and server) or more experienced (full-stack) developers are needed4 when building SPA. To alleciate this problem, single-language technology stacks are being developed. We see successful expansions of client-side languages to the server (Node for JavaScript) and vice-versa (GWT for Java, Opal for Ruby, pyJS for Python, GopherJS for Go).
- Indexer robots do not run JavaScript. As of 4th quarter of 2015 Google crawler is able to interpret JavaScript and CSS just like modern web browsers, but if some pages from SPA website are to be posted on Facebook, authors must implement mechanisms that provide the same content in another form, which can be read by Facebook's robot5 6.
- Extensive use of JavaScript can lead to memory leaks. It is especially apparent in older versions of Internet Explorer, where there are two memory managers (one for DOM elements and one for JavaScript objects). Many of moders JavaScript libraries contain IE leak-protection code, but expert knowledge of the matter may also be required in the team. Page reload frees all memory associated with it, thus problem is circumvented in non-SPA websites.
- Coding in JavaScript requires much discipline, as the language contain many features that are considered bad programming practices7 8. What's more, JavaScript is untyped9, which makes it more prone to mistakes made by the programmer. Multiple linting solutions (jslint, jshint, eslint) are being developed by the community in order to mitigate these problems.
When to use SPA?
Following conditions can be considered as favorable for SPA:
- Required high responsiveness,
- Required connection awareness of the client,
- Heterogenous client applications,
- Code base estimated to be large (> 100kLOC),
- Experienced development team.
Under following conditions SPA may be not advisable:
- Limited knowledge of JavaScript language and browser technology,
- Web-app without additional client applications,
- Required compatibility with very old browsers.
References
- Jose Maria Arranz Santamaria (ItsNat Java Web Framework) wrote a document titled The Single Page Interface Manifesto, where he advises on how to transition from server-side thinking to modern SPA.
- Personal website of Douglas Crockford (member of ES standards committee) contains article on causes of memory leaks in IE and how to avoid them.
- Report on research of client-side template engines written by Veena Basavaraj can be found on LinkedIn's engineering blog.
Annotations
{1} The concept of client-side web application that provide functionality on its own (without the assistance of a server) is often called Rich Internet Application.
{3} I participated in a project in which half of server-side resources were consumed by presentation logic and session storage (JSF was used extensively).
{4} Multiple programming languages in one project can be considered the right approach. Experienced programmers often seek to use the right tool for the job.
{5} Prerender.io provides serverside components that prerenders HTML pages in headless browser. Rendered HTML can be sent to robots visiting the website.
{6} Facebook's robot fetches the content of first URL written in a post. To test if Facebook's robot runs JavaScript paste http://softwarephilosophy.ninja/js-test in the post.
{7} EcmaScript standard version 5 instroduced Strict Mode, which changes the semantics of JavaScript by removing many unwanted behaviours.
{8} EcmaScript standard version 6 resolves many semantical problems that were present in previous versions of the language.
{9} A super-set of JavaScript called TypeScript (created by Microsoft) adds type declarations to the syntax and type inference to the semantics of the language.