Micro Frontends: A Practical Guide for Engineering Teams
Most web applications start with a single frontend: one codebase holding all of the client-side logic. That works beautifully until it doesn’t. As the product grows, more developers pile into the same repository, features start colliding, releases require coordinating half the engineering org, and a one-line change to the checkout page means redeploying the entire UI.
Micro frontends exist to break that bottleneck. The idea: apply the same decomposition that transformed backends to the browser, splitting a monolithic frontend into smaller pieces that autonomous teams can build, test, and deploy independently.
What Are Micro Frontends?
On the backend, the industry long ago embraced microservices, meaning separate modules that each own one business capability such as inventory, billing, or search. Micro frontends bring that modularity to the client side.
With a micro frontend architecture, each page (or even each significant section of a page) behaves like a complete, self-contained application living inside a larger shell. A team can own its slice end to end, with its own repo, pipeline, and release cadence. The practical benefits follow directly:
- Autonomous teams. Squads ship features without queuing behind a shared release train.
- Fewer merge and deployment conflicts. Smaller codebases mean fewer people stepping on each other.
- Incremental modernization. You can rewrite one section of a legacy UI in a new framework without a big-bang migration.
- Fault isolation. A bug in one module is far less likely to take down the whole experience.
Four Ways to Implement Micro Frontends
There is no single canonical implementation. The right pattern depends on whether you are starting greenfield or carving up an existing application, and on how much runtime integration you need.
1. Single-SPA (Framework-Orchestrated Composition)
Single-SPA is a JavaScript framework that acts as an orchestrator: it lets multiple micro frontends, even ones built with different technologies, coexist in one page. A root application decides which micro app is active based on the route, mounting and unmounting them on the fly. Crucially, it is framework-agnostic: one micro frontend can be React, another Angular, another Vue, all running side by side. This makes it a popular choice when different teams have different stacks, or during a gradual framework migration.
2. Multiple SPAs (Route-Based Composition)
The simplest pattern: build several independent single-page applications and let routing stitch them together. Navigation between major sections loads a different SPA, while shared concerns like authentication, navigation chrome, and design tokens are provided by common infrastructure. Each SPA is fully independent; they can exchange information (via URLs, storage, or events) but hold no direct references to each other. You trade a full page load at section boundaries for radical simplicity and total team isolation.
3. Web Components (Standards-Based Widgets)
Web Components are a browser standard for building reusable custom elements, and they map naturally onto micro frontends. A team can package a capability, say a checkout or payment button, as a custom element, develop and version it independently, and any page that needs it simply imports it like a widget. Because the standard is implemented natively in all modern browsers (Chrome, Firefox, Safari, Edge), no framework lock-in is involved. This pattern shines for embeddable, cross-cutting features consumed by many pages.
4. Iframes (Hard Isolation)
The oldest trick in the book still has a place. An iframe renders an entirely independent HTML document inside another page; a YouTube embed works exactly this way. As a micro frontend technique, iframes give you the strongest possible isolation: separate DOM, separate CSS, separate JavaScript context. The cost is clunkier communication and UX seams, so iframes fit best for embedding third-party or high-risk modules where isolation matters more than seamlessness.
When Micro Frontends Are Worth It (and When They’re Not)
Micro frontends solve an organizational scaling problem more than a technical one. They earn their complexity when several teams work on one product, when independent deployment cadence matters, or when you are strangling a legacy UI piece by piece. For a small team on a single product, a well-structured monolithic frontend is usually faster to build and easier to operate. As with services, the decision parallels the classic shared library vs. shared service trade-off: don’t pay a distribution tax you don’t need yet.
Frequently Asked Questions
Do micro frontends hurt performance?
They can, if each micro app ships its own copy of React and a full dependency tree. Mature setups mitigate this with shared dependencies (module federation or import maps), a common design system, and performance budgets enforced per team.
Do I need micro frontends if I already have microservices?
Not necessarily. Many organizations pair a microservices backend with a single frontend for years. Adopt micro frontends when the frontend itself becomes the bottleneck, whether through team contention, release coupling, or sheer codebase size, and not just because the backend is decomposed.
Can teams use different frameworks in each micro frontend?
Yes. Orchestrators like Single-SPA make it possible. But treat that freedom as an escape hatch for migrations, not a goal. Converging on one primary stack keeps bundle sizes and hiring simpler.
Ship a Modular Frontend Without the Guesswork
Choosing the right composition pattern, while avoiding the ones that quietly double your bundle size, is where micro frontend projects succeed or fail. Stage28 delivers exactly this kind of work as fixed-scope, fixed-price projects: AI-native senior engineers, a specification agreed up front, and payment only after delivery. If your frontend has outgrown its architecture, get in touch and we’ll scope it with you.