Single Page Application (SPA) – A Brief

Single Page Application, popularly called a SPA is the trendy buzzword in web application design. Beeline of modern JavaScript(JS) frameworks and their tall claims into the Front End (FE) arsenal in the recent time fuels this SPA tend. A decision of going with this trend needs careful considerations on multiple aspects.

CHARACTERISTICS OF SPA
It gives an impression of a single page in the browser. Pages never get re-drawn on interactions. Clicking on a link in the page changes the state of the app and shows the different content.
Page transitions (route) and state of the application-driven by JavaScript. Heavy role of JS, unlike traditional applications.
Url structure containing hash location (often – Google’s hash-bang model) that drives the state of the applications.
Single fully compliant HTML page which is the initial page (often called layout template) that gets loaded. The rest of them are HTML fragments or just JSON.
HTML/JS – Either all of the required artifacts get loaded on the initial load or obtained from the server on demand.

SPA – ARCHITECTURE

SERVER ARCHITECTURE
Usually, a thin server serving static resources (HTML, CSS, JS, Images, etc.) and providing data APIs. If cloud infrastructures are leveraged, it could even be a serverless architecture where static FE resources are hosted in object bins and data APIs (RESTful) are modeled as cloud functions (remember function as a service – FAAS. Example, AWS lambda or Google functions).

CLIENT ARCHITECTURE
The client is thicker than usual backed by JS frameworks such as Angular(JS), React, Vue, Ember, CycleJs, Aurelia or Backbone. Client architecture is mostly dictated by the framework used. These frameworks are often opinionated. Across the spectrum – there would be views that are often modeled as a template with data-bound to models (one way or two-way binding). This framework and their allies usually provide the necessary mechanisms to deal with variety of requirements such as managing application state, routing, watching, connecting to REST APIs, etc.

SPA – GOOD SIDE

• Single tab browsing provides native application experience and hence presumably enhanced usability.
• Performance – Since most of the FE artifacts required are loaded on initial load, subsequent interactions are faster. The on-demand load of data or HTML fragments is lighter in terms of network footprint.
• Allows code re-use. With cross-platform enabling technology such as Apache Cordova, ionic framework, the code can be reused to build hybrid or cross-platform mobile applications.

SPA – DARK SIDE

• Increased initial load time – FE resources with JS code need to be loaded and executed on the first hit which increases the DOM ready time. Often lazyload (client-side) and caching at CDN (server-side) strategies employed to reduce it.
• SEO – Search engine crawlers usually fail with javascript and hence SEO fails with SPA. To circumvent this, the community adopted a number of hacks. One such hack which is widely followed is to pre-render from the server and serve the html to search engine bots. SEO and SPA are certainly not friends.
• Dealing with back and forward buttons in the browser. As browsers are traditionally not built for SPAs, dealing with such browser behaviors are often a challenge. Dealing with a scroll position is another challenge in this line.
• Performance – Due to heavy JS, chances of JS issues, browser memory leaks esp. on mobile devices are high.
• Analytics – Traditional analytics metrics get measured on page load. SPAs need an alternate strategy for analytics.
• Security – Certain security credentials (example, for integrations) and presentation logic have to be made available in the browser for JS execution. This has been carefully crafted to avoid security vulnerabilities.