With the last 2 blogs, we understood a lot about application architecture patterns and how isolation of business logic and the code is an essential element at an organisational level. A small decision wrongly taken before building the application can lead to inconsistencies later in the application stage, where a change can be too costly(both in time and money) to incur.
But since we're talking about Frontend Architecture patterns, it's very essential to understand how the entire page gets delivered and updated to the user too, So going forward, we'll discuss more about application-level architectures for web products like:
- SPAs (React, Vue, Angular — client-rendered)
- BFF (Backend for Frontend)
- SSG/ISR/SSR (Next.js, Nuxt, Astro)
- Frontend Monoliths
- Microfrontends
In this blog, we'll learn about how SPA(Single Page Applications) came into the picture and what did they bring to the table.
Before SPAs, there were MPAs or Multi Page Applications. These, as the name suggests, were Multi because of the way they rendered pages. Every interaction rendered a new HTML page, reloading the old screen. These were mostly server-controlled applications (thin client) with very minimal JS dependency, but very slow UX.
To resolve this issue of entire page reload, AJAX was born. AJAX stands for Asynchronous JavaScript and XML. It introduced the XMLHttpRequest (XHR) API, letting pages request data without reloading. This is called partial updates. The concept of Promises and callbacks was born, later which came to be known as fetch().
But as apps grew, thus grew the need of a faster JS execution speed. Doing DOM manipulations and complex UI logic on slower JS engines was painful. And also maintaining apps with so many XHR calls and DOM changes turned out be a challenge. Thus came, probably one of the most revolutionary moment in web development history, Google's V8 engine.
V8, at a high level:
- introduced JIT(Just In Time) compilation, which compiled JS code to native machine code instead of line-by-line interpretation
- implemented optimisations like hidden classes, inline caching, and a modern garbage collector
This also enabled the creation of Node.js (2009) and huge server/client ecosystem growth. Here's a video on JS Engine internals and the V8's architecture in detail.
These pieces along with some others like client-side routing(history API), concept of virtual DOM and componentization of modules, bundlers together produced single page capabilities: no reload on navigation, client-rendered UIs and modular code.
With all these benefits, SPAs can be considered as a landmark in frontend engineering and quite honestly gave rise to the role of a frontend engineer. There is an option for a lot more interactivity and complex engineering ideas to be implemented on the web and thus came the, quite infamous, rise of dashboards and SaaS. And this in turn, was adopted and some groundbreaking libraries were created by top product companies.
The evolution continues — SPAs didn’t end the story; they changed it...
Top comments (0)