qiankun 3.0 ships as a release candidate while latest stays on 2.x

The release channel is the first thing to understand

There is a warning box above the feature list and it is about versions, not features. It states that qiankun 3.0 is under active development and points at a roadmap discussion, and that anyone who wants the 2.x line should use its own documentation domain, which is a separate site from the current documentation. The gap is visible in the tags themselves. The newest 2.x release is 2.10.16 from November 2023, and the newest tag overall is a 3.0.0 release candidate from August 2026, so the stable 2.x channel has not had a release since November 2023 while 3.x is still in release candidates. The note in the getting started section is explicit about the consequence: version 3 ships under a prerelease tag while latest still points at 2.x, so installing it means asking for the prerelease tag by hand. A plain install gives you the old major version.

npm i qiankun@rc

There is also an agent skill, installed with its own command, which scaffolds a host or a micro app wired up correctly.

The feature list is a list of isolation problems, one by one

The motivation section frames the project as an extraction rather than an invention: it was built inside a company whose distributed teams had turned web development into chaos, and after solving the problems it was released as a minimal viable framework, later becoming the base of hundreds of internal applications. The problems are listed as questions, and the feature list answers them in the same order. How do micro apps publish static resources is answered by the HTML entry, where you point at a URL instead of an asset manifest and the entry is streamed into the live document as it arrives, so rendering starts before the download finishes. What about performance and public dependencies is answered by automatic preloading, which discovers and preloads scripts and stylesheets while the HTML entry streams; the older prefetchApps API is kept only for backward compatibility and is deprecated. Isolation in development and deployment is answered by the framework handling integration for you.

The sandbox is a Proxy membrane, and it is on by default

The JavaScript sandbox is the feature the rest of the framework exists to support. Every micro app runs against a Proxy-membrane view of the window and document objects, so globals, timers, event listeners and dynamically added DOM nodes stay inside the app. Two details matter more than the mechanism. The first is that it is on by default, so isolation is the default behaviour rather than something you remember to switch on. The second is reclamation: what the sandbox contains is released when the app unmounts, which is what stops a long-lived host page from accumulating listeners and timers from applications the user has navigated away from. The same sandbox is also published as a standalone package that can isolate global writes and manage common side effects of trusted third-party scripts with no micro-frontend framework attached, which makes it usable as a general containment tool.

Style isolation is opt-in and built on a CSS at-rule

Style isolation works differently from the JavaScript sandbox in one important respect: it is opt-in. When it is enabled it is built on the CSS scope at-rule, and the description is specific that it includes external stylesheets. The two things it claims not to require are worth noting because they were the usual costs of this approach: your CSS does not have to be rewritten, and you do not pay the tax of Shadow DOM. For a team that already has a design system with global class names, that is the difference between a feature you can adopt and one you cannot, since rewriting every stylesheet to namespace its selectors is the step that kills most isolation efforts. The tradeoff is that you now depend on a browser feature for this behaviour, so the isolation guarantees you get are only as good as the scope support in the browsers your users run.

Native ESM changes what a micro app can be built with

The ESM support is the feature that moves the project beyond the older generation of micro-frontend tooling. Micro apps written as module scripts execute as real modules rather than being pulled out of their build as a single library bundle, and they are routed through the same membrane with import maps injected at runtime. Three things follow from that. Dynamic import works, which is what makes lazy loading at the route level possible in a way that is hard to fake. A Vite dev server works, so a micro app can be served by its own dev server while the host runs elsewhere, rather than requiring a production build in the loop. And the cost moves: because the entry is a real module, the bundler has to cooperate, which is why the project ships a plugin for both webpack 4 and 5 and for Vite that marks the entry script and fixes the output library.

Three exported functions are the entire contract

A micro app has to export three lifecycle functions, and that is the whole requirement:

export async function bootstrap() {}

export async function mount(props: { container: HTMLElement }) {
  root = render(props.container);
}

export async function unmount() {
  root.unmount();
}

There is a bootstrap step, a mount step that receives properties including the container element, and an unmount step that tears down whatever the mount created. The host side has two orchestration models to choose from. The imperative one loads a single app into a container and returns a handle you keep, because you need that handle later to unmount it when the part of the page goes away. The route-driven one registers a set of apps and starts them, for the case where a micro app's activation is fully determined by the URL. The examples add a fourth implicit step worth knowing: when the host passes a changed property down, the micro app re-renders through an update lifecycle rather than being remounted, which is how a language switch avoids destroying and rebuilding the application.

The examples are built as a laboratory, and every benchmark rebuilds first

The example site is not a gallery of screenshots. Two host shells, one React and one Vue, mount the same four micro apps with the JavaScript sandbox and style isolation switched on, plus a standalone sandbox lab. Every app carries an isolation lab that demonstrates what the sandbox actually contains: globals, leaked timers and injected styles, so you can see the guarantees being made rather than take them on trust. Running them locally needs a clone, pnpm install and one script that builds the workspace packages and starts every app in parallel, with the React shell on one port and the Vue shell on another. The toolchain floor in the manifest is Node 22.15 or a newer 24. Then there is the benchmark layer: more than a dozen named scripts covering a baseline, a comparison, isolation, streaming, smoke and ecosystem runs, and every one of them begins by building the packages first, so a benchmark run always measures current output rather than a stale build.

Editorial conclusion

qiankun fits an organisation running several independently deployed applications in one page, where the hard part is containment rather than layout, and where each team keeps its own framework and build tool. It does not fit a team that wants one release channel: the 2.x line's last release was in November 2023 while 3.0 has been a release candidate since at least August 2026, so you are choosing between a stable old major and a long prerelease. Before you commit, check the bundler configuration your stack needs in the quick start, and decide whether you want the sandbox on by default. The licence is MIT and the default branch is named next.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. umijs/qiankun on GitHub