Micro-frontends apply the microservices idea to the UI: split a large app into pieces that different teams can develop, deploy, and operate independently. The promise is appealing — small autonomous teams that don’t step on each other in a half-million-line React monolith — but in 2023, after several years of real adoption, we have enough scars to talk about it honestly.
When It Makes Sense (And When It Doesn’t)
The clearest signal to consider micro-frontends is organisational, not technical. With a single frontend team, you don’t need them. Four or five teams contributing to the same SPA and blocking each other in the pipeline is where the conversation starts to make sense.
Cases where it usually pays off:
- Large applications with clearly separated functional domains (catalogue, checkout, user account).
- Companies with multiple product teams needing independent release cycles.
- Progressive migrations — wrapping a legacy app with modern pieces without rewriting everything.
Cases where it’s premature:
- Startups and small products where coordination happens in a Slack conversation.
- Teams that haven’t yet established stable internal conventions (you’ll multiply the disorder).
- When the real bottleneck is the backend or design, not frontend development.
The Main Patterns
Three approaches dominate in 2023:
Iframes (Yes, Still)
The simplest and most isolated option. Each micro-frontend lives in an iframe; communication via postMessage. It works but has known problems: SEO, navigation, accessibility, and the “app inside an app” feel. Useful for integrating third parties or legacy internal tools. Poor candidate for fluid user experiences.
Module Federation (Webpack 5)
Webpack 5 introduced Module Federation, letting an app dynamically load compiled modules from another app at runtime. It’s the most popular option for serious React/Vue projects since 2022. It allows sharing dependencies (single React across apps) and keeps the unified-SPA feel.
Cost: complex Webpack configuration, careful management of shared dependency versions, and debugging that requires patience. Version incompatibility is the number-one source of incidents.
Single-SPA and Orchestrators
Single-SPA acts as an application router, mounting and unmounting micro-frontends in response to the URL. Good for mixing frameworks (React + Vue + Angular on the same page), although that use case is rarer than it sounds — most end up standardising on one framework.
The Pitfalls Nobody Mentions in Talks
After several projects in production, the real problems that cost the most:
- CSS leakage. Global styles from one micro-frontend “leak” to others. Solutions: CSS-in-JS, CSS Modules, Shadow DOM. All have their price.
- Dependency versions. Three teams on three React versions = state corruption, bugs impossible to reproduce. You need strict governance or accept the cost of duplicated bundles.
- Shared state. Passing data between micro-frontends without coupling them is hard. Event bus, custom events, or shared services — none is elegant.
- Performance. Each micro-frontend brings its own bundle. Without well-configured shared dependencies, total weight can multiply 3-4×.
- End-to-end testing. Testing the complete integration requires additional infrastructure. Per-micro-frontend tests pass; the whole breaks.
- Visual design. Without a mature design system, each team drifts. The page looks stitched together.
Non-negotiable Prerequisites
If you decide to move forward, these must exist beforehand:
- Robust design system with versioned components (ideally as published npm packages).
- Clear and enforced versioning conventions for shared dependencies.
- Integration pipeline testing the full composition, not just each piece.
- Unified observability — errors and metrics must correlate at the page level, not micro-frontend.
- Dedicated platform team maintaining the orchestrator and resolving cross-cutting issues.
Without these, micro-frontends multiply problems instead of solving them.
Cheaper Alternatives
Before jumping to the full pattern, evaluate intermediate options:
- Well-structured monorepo (Nx, Turborepo) with independent builds but unified deploy.
- Component packages published as internal libraries, consumed by a single SPA.
- Bounded contexts in code without separating deploy — logical boundaries, not physical ones.
These options give much of the organisational benefit without the operational cost.
Conclusion
Micro-frontends are a legitimate tool for large organisations with real frontend coordination problems. They aren’t an architectural improvement per se — they’re a transfer of complexity from the organisation to the runtime. That transfer pays off only when human-coordination costs exceed added technical costs.
If your first thought reading this was “this sounds complicated”, you probably don’t need them. Follow us on jacar.es for more on pragmatic frontend architecture.
