Skip to main content
Module Federation 2.0, maintained by the ByteDance Web Infra team and Zack Jackson, is the incumbent and a genuinely capable system. It ships a decoupled runtime, an mf-manifest.json format, first-class TypeScript type hints, a Chrome DevTools extension, runtime plugins, and Node SSR support — and it was announced in April 2024, with stable status reported by InfoQ in April 2026. If you need a batteries-included plugin with deep Webpack and Rspack integration, a large ecosystem, and automatic transitive sharing, Module Federation is a legitimate choice. knitkit makes a different bet: radical simplicity on platform primitives.

​
Feature comparison

Size figures above are pinned to named versions measured with the delta method. Re-verify these numbers against the actual release versions before publishing or citing them publicly.

​
Where MF’s worst bugs live — and why ours can’t

The ecosystem’s most common bug class is the dreaded “Invalid hook call… more than one copy of React” error. It originates from implicit and transitive sharing: Module Federation can silently share packages you didn’t explicitly declare, and the version negotiation that determines which copy wins happens deep inside the bundler’s share-scope mechanism — invisible to you unless you know exactly where to look. knitkit’s shared surface is explicit and inspectable. You declare every package you want shared in knit.config.json. The CLI emits each one as a standalone ESM asset from your installed version. The host and every remote import it through a single import-map entry — and the browser’s module cache guarantees exactly one instance per URL. There is no share scope to misconfigure, no transitive sharing to accidentally trigger, and nothing is shared silently. Open DevTools on any knitkit host and you can read the import map: one entry per package, one URL, one winner. This is debuggability by construction — the bug class is eliminated by the architecture, not papered over by configuration.

​
What knitkit deliberately gives up

knitkit is not trying to be Module Federation with a different logo. These are intentional trade-offs, not gaps to fill:
  • Automatic transitive sharing. You must declare the shared surface explicitly. This is precisely where Module Federation’s silent failures originate — knitkit treats mandatory explicitness as a feature, not a regression.
  • Extracting a dep from an already-inlined bundle. Externalization is mandatory before knitkit build runs. If your bundler has already inlined react into a chunk, you need one line of bundler config to externalize it first. This is typically a single external entry.
  • Cross-remote HMR. Live module replacement across remote and host requires bundler coupling, which knitkit deliberately refuses. Each remote uses its own dev server’s HMR. Use the @knitkit/overrides local-override widget to point any single remote at localhost while the rest of the system runs from deployed URLs.

​
When to use which

Use Module Federation 2.0 if you:
  • Need deep, ergonomic Webpack or Rspack plugin integration.
  • Want automatic transitive sharing and are comfortable owning the configuration required to make it reliable.
  • Need a large ecosystem of community plugins and prior art.
  • Require features like the Chrome DevTools extension or the MF runtime plugin API.
Use knitkit if you:
  • Want a small, standards-native primitive you can read and fully understand in an afternoon.
  • Need identical, predictable behavior across browser, Node SSR, and the edge with the same manifest.
  • Value a shared surface you can see and verify — no hidden share-scope resolution.
  • Care about shipping less JavaScript: ~3.5 KB brotli vs ~27 KB brotli for the federation runtime alone.