Native Federation - Deep Dive - Part 1/8 - The Mental Model, Why Native Federation Exists and What Changed in v4

Web developers often deploy micro-frontend systems that rely on webpack Module Federation, a model where a host application lazily loads code from remote sources at runtime. This mental model allows sharing of dependencies without shipping duplicate copies of code. However, the implementation was fraught with challenges, primarily due to webpack's runtime contract and tooling layer, which resulted in framework lock-in and migration complications.

Native Federation recognized these issues and decided to rebuild the model using web standards, specifically ECMA Script Modules and Import Maps, along with JSON manifests. This change enables genuine ES modules to be served directly to the browser, with shared dependencies resolved via import maps, rather than through a bundler's runtime.

This approach, while technically remarkable, allows for more flexibility and replaceability of the build tool, as the underlying contract doesn't depend on a specific bundler. The move to v4 of Native Federation marks a significant step in this direction, as it was restructured to be framework and bundler-agnostic, with its core, adapters, and orchestrator living under separate repositories.

This shift signifies a move towards a platform with published contracts between its layers, rather than a plugin with internal modules. This change not only addresses the limitations of the previous implementation but also signals a broader vision for where the Native Federation project and the dynamic module loading pattern are headed.