Modern Frontend Architecture Patterns
Application Architecture Styles
How Web Apps Are Built
You know how to build individual components. But how do those components get from your codebase to a user's screen? The answer lies in the application's architecture—the high-level pattern that dictates how the user interface is structured, delivered, and updated.
This isn't about specific frameworks, but about the fundamental strategies for assembling a user experience. Let's explore the main approaches and their trade-offs.
The Single-Page Application (SPA)
A Single-Page Application behaves more like a desktop program than a traditional website. When you first visit an SPA, the browser loads a single HTML page along with all the necessary JavaScript and CSS. From that point on, navigating the site doesn't trigger full page reloads. Instead, JavaScript dynamically rewrites parts of the current page as you interact with it.
This creates a fluid, seamless experience. Think of using Gmail or Google Maps. Transitions are quick, and the application feels responsive because the browser is doing most of the work, fetching only the data it needs from the server without refreshing the entire view.
SPAs load everything up front—the application shell—and then manage views and data on the client-side.
To achieve this, SPAs often use an App Shell model. The shell is the minimal HTML, CSS, and JavaScript needed to power the user interface. It’s the skeleton of your app. Once the shell is loaded and cached by the browser, it can be displayed instantly on subsequent visits, while the dynamic content is populated by the JavaScript application.
This leads to the primary trade-off. The initial load can be slow because the browser has to download a large JavaScript bundle containing the entire application. But once that's done, navigation between pages is nearly instantaneous.
The Multi-Page Application (MPA)
The classic web model is the Multi-Page Application. Every time you click a link or submit a form, the browser makes a new request to the server, which then sends back a brand new HTML page to render. It's simple, reliable, and great for content-heavy sites where search engine optimisation (SEO) is a top priority, as each page is easily crawlable.
The downside is the user experience can feel clunky. Each navigation results in a flash of a white screen as the new page loads. All application state, like what's in a shopping cart, has to be resent with each request or stored carefully.
Modern web applications increasingly leverage server-side rendering (SSR) to improve initial load times and search engine optimization.
However, modern frameworks are blurring the lines. Server-first approaches now combine the benefits of MPAs (fast initial loads, strong SEO) with the interactivity of SPAs. This has led to clever new patterns.
Islands and Micro-Frontends
One of the most exciting modern MPA patterns is the Islands Architecture. The server sends a mostly static, non-interactive HTML page, which loads very quickly. Dotted within this page are self-contained, interactive components—the "islands."
Each island can be "hydrated" independently. Hydration is the process of attaching JavaScript event listeners to the static HTML, making it interactive. This can happen when the page loads, when the island scrolls into view, or even when the user first clicks on it. This avoids loading a single, monolithic JavaScript bundle and significantly improves performance, especially on slower devices.
Islands Architecture: Ship static HTML from the server and hydrate small, independent widgets of interactivity on the client.
For very large organisations, even a single application can become a bottleneck. When dozens of teams need to work on the same frontend codebase, they can slow each other down. This is where Micro-Frontends come in.
The idea is to break up a large frontend monolith into smaller, independently deployable applications. Each team can own a specific feature or section of the site, like the search bar, the product recommendation carousel, or the checkout process. They can choose their own tech stack and have their own release cycles.
These micro-apps are then composed together into a cohesive user experience. This promotes team autonomy and allows large applications to scale, but it introduces its own complexity. Orchestrating the different pieces, managing shared styles, and ensuring consistent performance across all micro-frontends requires careful planning.
| Architecture | Key Advantage | Key Trade-off |
|---|---|---|
| SPA | Fluid, app-like navigation | Large initial bundle, slower first load |
| MPA (Modern) | Fast initial load, strong SEO | Less fluid navigation, potential for more server requests |
| Islands | Excellent performance, minimal JS | Can be complex to manage state between islands |
| Micro-Frontends | Team autonomy, scalability | High operational complexity, potential for inconsistency |
Choosing the right architecture depends entirely on your project's needs. A highly interactive dashboard might be a perfect fit for an SPA, while a content-focused blog would benefit from a modern MPA with islands. A massive e-commerce site with multiple development teams might need to adopt micro-frontends to stay agile.
Ready to test your knowledge?
What is the primary trade-off associated with a Single-Page Application (SPA)?
Which application architecture is best suited for a massive e-commerce site where multiple independent teams need to work on different features like the search bar, product recommendations, and checkout process simultaneously?
Understanding these patterns is the first step in designing applications that are not just functional, but also scalable, maintainable, and performant.
