A story on Frontend Architectures - Birth of the FE engineer

Source: Dev.to

Introduction

With the last two blogs, we understood a lot about application architecture patterns and how isolation of business logic and code is an essential element at an organisational level. A small decision wrongly taken before building the application can lead to inconsistencies later, where a change can be too costly (both in time and money) to incur.

Since we’re talking about Frontend Architecture patterns, it’s essential to understand how the entire page gets delivered and updated to the user. Going forward, we’ll discuss more about application‑level architectures for web products such as:

• 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 how SPA (Single Page Applications) came into the picture and what they brought to the table.

From MPAs to SPAs

Before SPAs, there were MPAs (Multi‑Page Applications). As the name suggests, each interaction rendered a new HTML page, reloading the old screen. These were mostly server‑controlled applications (thin client) with minimal JavaScript dependency, resulting in a very slow user experience.

AJAX and Partial Updates

To resolve the issue of full‑page reloads, AJAX (Asynchronous JavaScript and XML) was introduced. AJAX brought the XMLHttpRequest (XHR) API, allowing pages to request data without reloading—known as partial updates. The concept of Promises and callbacks later evolved into the modern fetch() API.

JavaScript Engine Evolution

As applications grew, the need for faster JavaScript execution became critical. Performing DOM manipulations and complex UI logic on slower JS engines was painful, and maintaining many XHR calls and DOM changes turned out to be a challenge. This led to one of the most revolutionary moments in web development history: Google’s V8 engine.

V8 Highlights

• Introduced JIT (Just‑In‑Time) compilation, converting JS code to native machine code instead of interpreting line‑by‑line.
• Implemented optimisations such as hidden classes, inline caching, and a modern garbage collector.

These advances also enabled the creation of Node.js (2009) and spurred massive growth in the server/client ecosystem. For a deep dive, watch this video on JS engine internals and V8’s architecture.

Key Enablers for SPAs

Together with other innovations—client‑side routing (history API), the concept of a virtual DOM, component‑based modules, and modern bundlers—SPAs became possible, offering:

• No reload on navigation
• Client‑rendered UIs
• Modular, maintainable code

Impact on Frontend Engineering

With all these benefits, SPAs can be considered a landmark in frontend engineering and gave rise to the role of the frontend engineer. They opened the door to richer interactivity and more complex engineering ideas on the web, leading to the rise of dashboards, SaaS products, and groundbreaking libraries created by top product companies.

Conclusion

The evolution continues—SPAs didn’t end the story; they changed it.