How does Vite's module federation approach, such as the @originjs/vite-plugin-federation or the @module-federation/vite plugin, differ mechanically from Webpack Module Federation, and in what situations would you avoid runtime module federation altogether in favor of build-time integration?

## Two different loading mechanisms Vite's ecosystem approaches module federation with a fundamentally different loading mechanism than Webpack's, even though the two are trying to solve the same problem, because Vite is built around native browser ES modules rather than Webpack's own module runtime and chunk format. **Webpack Module Federation**, as covered by the mechanism questions above, works through a custom container protocol: a remote emits a bespoke `remoteEntry.js` that registers a get/init API on the global scope, and Webpack's own runtime, meaning its module resolution, chunk-loading machinery, and internal require implementation, mediates every cross-application import. This runtime is what lets Webpack do sophisticated shared-dependency negotiation, deduplicating a `singleton: true` React across independently built bundles by intercepting every module request through its own resolver. **Vite**, by contrast, ships development builds as literal native ES modules the browser loads directly via script type=module and import, with no bundler runtime mediating module resolution during dev — Vite's dev server just serves transformed files on demand, relying on the browser's own native module graph and caching. For production, Vite does bundle via Rollup, but the ecosystem's federation plugins take one of two approaches. ## Emulation versus the real spec | Plugin | Approach | |---|---| | `@originjs/vite-plugin-federation` | emulates Webpack's container protocol on top of Vite and Rollup output, generating a similar remoteEntry-style manifest and exposing a compatible-ish runtime, trading off some correctness edge cases, since its shared-dependency negotiation is a reimplementation rather than Webpack's actual algorithm and has historically had rough edges with certain singleton scenarios, for the ability to reuse the same mental model and host and remote config shape teams already know from Webpack | | `@module-federation/vite` | the newer, more actively maintained plugin, part of the broader Module Federation project's own multi-bundler runtime effort, instead implements the actual Module Federation runtime specification as a bundler-agnostic layer, so a Vite-built remote and a Webpack-built host, or vice versa, can genuinely interoperate through the same get and init container contract, rather than each bundler shipping its own incompatible emulation | ## What a team feels day to day The practical difference a team feels day to day is mostly about dev-server behavior and manifest shape: - Vite-federated setups tend to produce a lighter-weight, more transparent output, closer to plain ES module `import()` calls with a small runtime shim, and benefit from Vite's fast HMR-driven dev loop even for federated modules in local development. - whereas Webpack's container protocol is a heavier, more opaque abstraction but has the deepest ecosystem support, the most production track record, and mature tooling built specifically around it. Teams choosing between the emulation-style plugin and the spec-implementation plugin are effectively trading maturity and community size against the correctness guarantee of speaking the real, shared protocol; a team already fully committed to Webpack on the host side has a strong reason to prefer whichever Vite-side plugin implements the actual spec if genuine cross-bundler interop is a hard requirement, rather than betting on an emulation staying compatible as Webpack's own implementation evolves. ## When to skip runtime federation entirely Situations where you would avoid runtime module federation altogether, regardless of bundler, and prefer build-time integration instead center on cases where the coordination cost federation is designed to remove isn't actually present, or where its costs outweigh its benefits. - If all the micro-frontends are owned by one team or one release train anyway, a **monorepo with build-time package imports**, via a tool like Nx, Turborepo, or plain workspace packages, gives strictly better guarantees for free: full type-checking across the boundary, a single dependency-version resolution with no runtime negotiation risk, dead-code elimination and tree-shaking across the whole app instead of per-remote, and no risk of a live CDN outage breaking a page that could have simply been rebuilt together. - **Build-time integration** is also strictly preferable when the composed application has hard performance or reliability requirements that a network-fetched-at-runtime dependency can't meet — a checkout flow's core payment form, for instance, is a common example of something teams deliberately keep out of runtime federation, preferring to vendor or directly import it, precisely because the failure modes covered earlier, such as a remote's CDN having a bad five minutes, are unacceptable on that specific path. ## The rule of thumb As a rule of thumb: reach for runtime Module Federation, on whichever bundler, when the organizational boundary of separate teams, separate release cadences, and separate deploy pipelines is real and valuable to preserve; reach for a monorepo or a vendored package when it isn't, because federation's operational cost buys you nothing if there's no actual independence being preserved on the other side of it.