Architecture
Beyond Component Libraries: What Actually Makes a Micro-Frontend Worth Adopting
A decade of migrations reveals that most teams misunderstand what micro-frontends solve—and why rushing to frameworks before answering harder questions leads to failure.
InfoQ
Luca Mezzalira has spent the last five years at AWS watching teams struggle through the same micro-frontend mistakes: they copy existing monoliths, load everything at runtime, and pick a framework before they've even decided how to split the system. The real work, he finds, starts much earlier.
The Confusion Between Components and Micro-Frontends#
A common pitfall is treating micro-frontends as if they were just oversized components. A button in a design system is intentionally dumb—it accepts props, follows instructions from its parent container, and reuses code across many surfaces. That's reusability by design. Micro-frontends work the opposite way. They're coarse-grained, self-aware, and independent. A micro-frontend knows how to behave without being told; a component waits for instructions. The key difference: components optimize for consistency and shared code; micro-frontends optimize for team autonomy and independent deployment. The moment you prioritize reusability at all costs, you introduce coupling that defeats the purpose.
What Actually Drives the Migration#
Before selecting Single-SPA, Next.js multi-zone, Web Components, or Module Federation, teams need to answer a harder question: What problem are we trying to solve? Mezzalira has found that executives usually want one of four things:
- Teams' autonomy: Eliminating the dependency chains that prevent one team from shipping while waiting for another
- Organizational scalability: The ability to plug in a new team working on a new system area without slowing everyone else down
- Agility: Building systems flexible enough to respond when the market shifts overnight (as it did during the pandemic and again as AI reshapes business models)
- Fast feedback cycles: Shipping more often to gather user data and refine faster
None of these are technical requirements. They're organizational and business-driven. That's why the choice between monorepo and polyrepo matters more than it appears. Either decision shapes engineering culture and organizational structure, not just code placement. The framework you pick comes later—only after you've mapped what success looks like.
