Single Page Application, popularly called as 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
- Gives an impression of single page in the browser. Pages never gets 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 as layout template) that gets loaded. Rest of them are HTML fragments or just JSON.
- HTML/JS – Either all of the required artefacts get loaded on initial load or obtained from 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 modelled as cloud functions (remember function as a service – FAAS. Example, AWS lambda or Google functions).
Client architecture
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 which are often modelled as template with data bound to models (one way or two way binding). These 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 persumably enhanced usability.
- Performance – Since most of the FE artefacts required are loaded on initial load, subsequent interactions are faster. The on-demand load of data or HTML fragments are lighter in terms of network footprint.
- Allows code re-use. With cross platform enabling technology such as Apache cardova, 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 first hit which increases the DOM ready time. Often lazy load (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, community adopted number of hacks. One such hack which is widely followed is to pre-render from server and serve the html to search engine bots. SEO and SPA are certainly not friends.
- Dealing with back and forward buttons in browser. As browsers are traditionally not built for SPAs, dealing with such browser behaviours are often a challenge. Dealing with 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 gets measured on page load. SPAs need alternate strategy for analytics.
- Security – Certain security credentials (example, for integrations) and presentation logic have to be made available in browser for JS execution. This has be carefully crafted to avoid security vulnerabilities.