Module federation
Slap yourself if
You think Module Federation is just code splitting across apps or believe it magically removes duplication without runtime cost.
Why this exists
Because teams adopt Module Federation to solve org-scale problems and accidentally introduce runtime coupling, version drift, and failure modes they never planned for.
Mental model
Module Federation is runtime dependency injection for JavaScript. You are deferring linking from build time to execution time — and paying for it in coordination, safety, and latency.
- Bundles are built with placeholders for remote modules.
- At runtime, a host resolves and loads remote containers over the network.
- Shared dependencies are negotiated based on version and scope rules.
- Execution proceeds only after remote code is fetched, initialized, and linked.
- Assuming shared dependencies are always deduplicated.
- Tight coupling between host and remote release cycles.
- Runtime failures due to missing or incompatible remotes.
- Treating federation as a performance optimization instead of an architectural trade.
Module Federation allows applications to load and share modules at runtime, trading build-time safety for runtime flexibility and organizational decoupling.
- Calls it micro-frontends without caveats.
- Ignores runtime version negotiation.
- Assumes no performance impact.
- Cannot explain remote initialization order.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.