Frontend Architecture Patterns

Micro frontends are one of several architectural approaches for building web applications. Choosing the right pattern depends on your team size, product requirements, performance needs, and organizational constraints. This page provides an overview of the major patterns and how they relate to micro frontends.

For an interactive, context-driven recommendation engine, visit Frontend Architecture Patterns — a companion site with a pattern selector tool that matches architectures to your specific constraints.

The Architectural Landscape

Multi-Page Application (MPA)

The traditional model: each page is a separate HTML document served by the backend. Modern enhancements like HTMX and Hotwire/Turbo bring dynamic behavior without full client-side frameworks.

Best for: Content-heavy sites, SEO-critical applications, teams with strong backend skills. Limitation: Page transitions cause full reloads (unless enhanced with Turbo-style libraries).

Learn more at frontendpatterns.org

Single-Page Application (SPA)

A single HTML page with JavaScript handling all routing and rendering. Frameworks like React, Vue, and Angular dominate this space.

Best for: Rich, stateful user interfaces (dashboards, editors, complex forms). Limitation: Large initial bundle, SEO challenges without SSR, single team usually owns the entire app.

Learn more at frontendpatterns.org

Server-Side Rendering (SSR) & Hybrid

SSR generates HTML on the server for each request, then hydrates it on the client. Hybrid approaches (Next.js, Nuxt, SvelteKit) combine SSR for initial loads with SPA-like navigation afterward.

Best for: SEO-sensitive applications that also need rich interactivity. Limitation: Server infrastructure complexity, hydration cost.

Learn more at frontendpatterns.org

Islands Architecture

Only interactive portions of the page (“islands”) are hydrated with JavaScript. The rest is static HTML. Frameworks like Astro pioneered this approach.

Best for: Content-centric sites with pockets of interactivity (blogs, marketing sites, documentation). Limitation: Not suited for highly interactive, stateful applications.

Learn more at frontendpatterns.org

Modular Monolith

A single application with strong internal module boundaries. Teams own modules, but everything ships as one deployment.

Best for: Organizations that want team ownership without the operational complexity of distributed deployments. Limitation: Coupled releases — a bug in one module can block deployment of all modules.

Learn more at frontendpatterns.org

Micro Frontends

Independently developed, deployed, and composed frontend applications. Each team owns a vertical slice of the product. This is the focus of this site.

Best for: Large organizations with multiple teams, products requiring independent release cycles, polyglot frontend stacks. Limitation: Operational complexity, shared dependency challenges, UX consistency overhead.

Start with What Are Micro Frontends? for a deep dive.

Module Federation

A runtime mechanism (primarily via Webpack 5) for sharing code between independently deployed applications. Often used as the implementation layer for micro frontends.

Best for: Teams already using Webpack that want runtime code sharing without iframes or script tags. Limitation: Tied to the Webpack/Rspack ecosystem.

Learn about Module Federation patterns on this site.

Web Components

Browser-native custom elements with encapsulated styles (Shadow DOM) and behavior. Framework-agnostic by nature.

Best for: Reusable components that must work across different frameworks, design system distribution. Limitation: Styling constraints with Shadow DOM, limited framework integration for complex state.

When to Choose Micro Frontends

Micro frontends shine when:

Multiple teams need to ship independently on different cadences
The application is large and complex, spanning multiple business domains
Teams want technology flexibility (e.g., one team on React, another on Vue)
You need fault isolation — one team’s bug should not bring down the whole app
Incremental migration from a legacy monolith is required

Micro frontends are often overkill when:

You have a small team (1-3 developers)
The application is simple and well-scoped
You are building an MVP or prototype
Release coordination is not a bottleneck

For a detailed analysis, see When Not to Use Micro Frontends.

Use the Pattern Selector

Not sure which pattern fits your context? The Frontend Architecture Pattern Selector provides context-driven recommendations based on your team size, product type, and technical constraints. It uses a transparent, deterministic scoring model — no black-box AI — to help you make informed decisions.

Go Deeper in the Book

Get the complete guide with detailed examples, diagrams, and production-ready patterns in Micro Frontends Architecture for Scalable Applications.