|
| 1 | +# MF 2.0 Stable Release: Balancing Developer Productivity and Extreme Performance |
| 2 | + |
| 3 | +One year ago, we open-sourced Module Federation 2.0 ([MF 2.0](https://module-federation.io/en/blog/announcement.html)), and since then we have received a wealth of valuable feedback and suggestions from the community. We believe that a modern frontend framework must not only improve collaborative development efficiency, but also provide a core engine that enables extreme performance. With this in mind, we have spent the past year deeply refining MF 2.0 and expanding its capabilities. |
| 4 | + |
| 5 | +Today, we are pleased to announce that **MF 2.0 is now officially stable**. The stable release delivers powerful performance optimizations, covers a broader range of deployment scenarios, and significantly improves the developer experience. |
| 6 | + |
| 7 | +## End-to-End Performance Optimization System |
| 8 | +MF 2.0 systematically restructures the performance pipeline of micro-frontend applications across four stages: **build, asset loading, rendering, and data fetching**. |
| 9 | + |
| 10 | +These capabilities do not exist in isolation; they work together to form an end-to-end performance optimization system tailored for module federation scenarios. |
| 11 | + |
| 12 | +**All capabilities support incremental adoption**. You can enable them gradually as needed without performing a big-bang rewrite of your current architecture, and without compromising the stability of existing systems. |
| 13 | + |
| 14 | +### Tree Shaking for Shared Dependencies |
| 15 | +Traditional shared dependencies avoid duplicate loading, but to ensure completeness, shared libraries are often **bundled and exposed as whole packages**. Even if you only use a small portion, you still have to load the entire library, which causes bundle sizes to grow continuously. |
| 16 | + |
| 17 | +In **MF 2.0**, this problem is addressed: |
| 18 | + |
| 19 | +**Shared dependencies now support tree shaking.** |
| 20 | + |
| 21 | +By simply enabling `treeShaking`, MF can perform on-demand pruning of shared dependencies without sacrificing the dynamic nature of module federation. It retains only the modules that are actually likely to be used, significantly reducing the size of shared bundles while remaining fully compatible with existing projects. |
| 22 | + |
| 23 | + |
| 24 | + |
| 25 | +MF 2.0 provides two modes to fit different scenarios: |
| 26 | + |
| 27 | +- **runtime-infer**: Zero external dependencies and ready to use out of the box. At runtime, MF first attempts to reuse already-loaded tree-shaken shared bundles; if their capabilities are insufficient, it automatically falls back to loading the full dependency to ensure functional completeness. You can improve reuse effectiveness with `usedExports`. |
| 28 | + |
| 29 | +- **server-calc**: A mode where the server or CI system analyzes dependency usage across multiple applications and produces a globally optimal shared-pruning result, suitable for large systems. |
| 30 | + |
| 31 | +A **visual analysis dashboard** is also provided, making it easy to see how shared dependencies are used and what bundle size savings they deliver. |
| 32 | + |
| 33 | +For a large component library like **Ant Design**, when an application only uses the Badge, Button, and List components, the shared bundle size is about **1404.2 KB** without shared-dependency tree shaking. After enabling tree shaking, the actual loaded size drops to **344.0 KB**, reducing unnecessary code by approximately **75.5%**. |
| 34 | + |
| 35 | + |
| 36 | + |
| 37 | + |
| 38 | + |
| 39 | +### Server-Side Rendering (SSR) |
| 40 | +SSR generates full HTML on the server and returns it directly to the browser, so pages can render without waiting for client-side hydration. This dramatically improves **first-screen performance** and **SEO**. For medium-to-large web applications, SSR has effectively become a standard capability. |
| 41 | + |
| 42 | +However, in micro-frontend architectures, SSR has historically been difficult to implement. Early MF versions did not cover this capability, forcing developers to choose between **architectural flexibility** and **performance benefits**. |
| 43 | + |
| 44 | +In **MF 2.0**, this trade-off is eliminated. |
| 45 | + |
| 46 | +You can use **MF SSR** directly within **{ props.framework || 'Modern.js' }**, giving micro-frontend applications high-performance SSR capabilities as well. |
| 47 | + |
| 48 | +{ props.ssr || '' } |
| 49 | + |
| 50 | +### Isomorphic Data Prefetching |
| 51 | +MF 2.0 introduces a new **isomorphic data fetching solution** that supports both **SSR and CSR** scenarios. It provides built-in **`prefetch`** and **`cache`** APIs for unified data prefetching and cache management, ensuring stable and predictable performance across different rendering modes. |
| 52 | + |
| 53 | +By leveraging preloading and caching, pages can prepare critical data before rendering, preventing repeated requests and waterfall loading, which significantly improves both initial load and interactive responsiveness. |
| 54 | + |
| 55 | +{ props.dataSolution || '' } |
| 56 | + |
| 57 | + |
| 58 | +{ props.serverPreload || '' } |
| 59 | + |
| 60 | + |
| 61 | +### Rust-Powered Capabilities |
| 62 | +In large projects, **manifest generation** often becomes a performance bottleneck during the build phase. MF 2.0 moves this core capability to a **Rust implementation**, taking advantage of Rust’s high performance and memory safety to substantially reduce the time required to generate manifests. |
| 63 | + |
| 64 | +At the same time, **AsyncStartUp** has also been rewritten in Rust. You no longer need to configure asynchronous entry points to get equivalent capabilities, and related first-screen performance risks are effectively eliminated, making the application startup path simpler, more stable, and more efficient. |
| 65 | + |
| 66 | +{ props.deploy || '' } |
| 67 | + |
| 68 | +## More Powerful Debugging System |
| 69 | +MF 2.0 builds a comprehensive debugging system around **observability and debuggability**. It makes shared dependencies, module relationships, and potential side effects **visible, traceable, and detectable in advance**, greatly reducing uncertainty when developing and integrating dynamic applications. |
| 70 | + |
| 71 | +### Side Effect Scanner |
| 72 | +Before consuming a remote module, teams often need to assess whether it pollutes global variables, registers event listeners, or affects style scopes—uncertainties that significantly increase the cost of adopting micro-frontends. |
| 73 | + |
| 74 | +MF 2.0 provides a **Side Effect Scanner** that statically analyzes build outputs and identifies the following side effects: |
| 75 | + |
| 76 | +- Global variables |
| 77 | +- Event listeners |
| 78 | +- CSS selector impact scope |
| 79 | + |
| 80 | +The accompanying **CLI tool** can automatically perform scans and output results, allowing consumers to understand the risks before integration and thereby significantly lower the cost of onboarding federated modules. |
| 81 | + |
| 82 | +### Chrome Extension for Dependency Visualization |
| 83 | +We have fully upgraded the existing Chrome extension with a new UI and stronger debugging capabilities, making the runtime state of module federation **visible, queryable, and verifiable**. |
| 84 | + |
| 85 | +- **Smart sidebar sync** |
| 86 | +The panel automatically follows the current page without manual refresh or reconnection, providing a smoother debugging experience. |
| 87 | + |
| 88 | + |
| 89 | +- **Shared dependency visualization** |
| 90 | +The new **Shared** panel clearly shows shared dependency loading on the current page, for example: |
| 91 | + - Whether React is successfully shared |
| 92 | + - Which shared version is actually in use |
| 93 | + - Whether your sharing strategy is working as expected |
| 94 | + |
| 95 | + |
| 96 | +- **Fast dependency graph navigation** |
| 97 | +You can search for any module in the dependency graph, and see its upstream and downstream relations in a clear hierarchy, making complex dependencies easy to reason about. |
| 98 | + |
| 99 | + |
| 100 | + |
| 101 | +- **Data trimming mode** |
| 102 | +When there are many modules, you can enable trimming mode to reduce the size of proxy data and avoid injection failures caused by localStorage limits. |
| 103 | +*Trimmed data only affects preloading analysis, not actual behavior, so it is safe to enable.* |
| 104 | + |
| 105 | + |
| 106 | +## Richer Ecosystem |
| 107 | + |
| 108 | +MF now supports the major **bundlers, application frameworks, and UI stacks**, and can run reliably across different technical ecosystems, helping teams introduce module federation without changing their existing technology choices. |
| 109 | + |
| 110 | +- **Bundler**: Webpack / Rspack / Rollup / Rolldown |
| 111 | + |
| 112 | +- **Build Tool**: Rsbuild / Vite / Metro |
| 113 | + |
| 114 | +- **Framework/Tool**: Modern.js / Next.js / Rspress / Rslib / Storybook |
| 115 | + |
| 116 | +- **UI Library**: React / Vue / React Native |
| 117 | + |
| 118 | + |
| 119 | + |
| 120 | +On top of this, MF 2.0 extends module federation capabilities into more critical development and delivery scenarios: |
| 121 | + |
| 122 | +### Node.js |
| 123 | +Module federation can now be used directly in the **Node.js runtime**, so remote modules can be consumed not only by the browser but also by **SSR, BFF, and Node service layers**, enabling a unified delivery model for modules across frontend and backend. |
| 124 | + |
| 125 | +### Rspress Documentation Splitting |
| 126 | +In **Rspress**, MF supports splitting and loading remote modules by document or route, allowing large documentation sites to be **decomposed and released independently via module federation**, which is ideal for multi-team documentation and knowledge platforms. |
| 127 | + |
| 128 | +### Rstest |
| 129 | +Within the **Rstest** testing system, module federation can load remote modules in a real runtime manner, enabling micro-frontend and MF applications to perform **integration tests and end-to-end tests that closely mirror production**, avoiding the gap between tests and real runtime behavior. |
| 130 | + |
| 131 | +## Changes |
| 132 | +### Version Changes (Minor Changes) |
| 133 | +We prioritize **stability and compatibility**, so this upgrade contains no breaking changes and only introduces a few minor updates. The key changes are: |
| 134 | + |
| 135 | +### Minor Changes |
| 136 | + |
| 137 | +- The default value of `library.type` is changed from `var` to `global`. |
| 138 | +- `runtimePlugins` now support configuration parameters. |
| 139 | + |
| 140 | +## What's Next? |
| 141 | +### React Server Components |
| 142 | +React Server Components (RSC) represent a revolutionary step forward in the React ecosystem. Compared to MF x SSR, the combination of MF x RSC can deliver even better performance (with much smaller bundles) and safer data handling. We have already validated this approach in basic demos and will provide stronger support and integration in Modern.js. |
| 143 | + |
| 144 | +### AI-friendly Design |
| 145 | +We are gradually enriching MF with **the contextual information and metadata required for AI to use components and modules**, including capability boundaries, usage constraints, runtime environments, and dependency relationships. We also plan to introduce **quantitative scoring and confidence mechanisms** so that component assets can be understood, evaluated, and selected by AI. |
| 146 | + |
| 147 | +{ props.aiFriendly || '' } |
| 148 | + |
| 149 | +{ props.next || '' } |
0 commit comments