Micro-Frontend Guide: Choosing qiankun vs Module Federation with Demos

What Micro-Frontends Solve

The core goal of micro-frontends is to let multiple independently developed and deployed frontend applications compose into a single page, sharing a common shell (navigation, sidebar, global state) while each retains its own tech stack, repository, and release cycle.

Typical pain points include:

Legacy Vue 2 monolith that needs gradual migration to React or Vue 3 without a full rewrite.

Multiple sub-teams owning distinct business domains (user center, orders, reports) that must integrate into one portal.

Growing monolithic bundle size; desire for independent builds and deployments per application.

Caution: Micro-frontends are not a silver bullet. They introduce complexity — inter-app communication, style conflicts, duplicate dependencies — that only pays off when the scenario truly matches.

Comparison: qiankun vs Module Federation

From an "integrate multiple applications" perspective, qiankun aligns with the intuitive micro-frontend model; from a "split components, share resources" angle, Module Federation offers more flexibility. Many teams sit between the two and pick à la carte.

Origin: qiankun (Alibaba, based on single-spa) vs Module Federation (Webpack 5 official).

Positioning: qiankun — application-level (shell + child apps); Module Federation — module-level (remote module loading).

Tech stacks: qiankun allows child apps and shell to use different stacks; Module Federation focuses on module reuse.

Onboarding: qiankun requires shell + child app conventions; Module Federation adds a plugin to each build.

Best fit: qiankun for multi-team large-scope business composition; Module Federation for shared components / on-demand loading.

qiankun Minimal Demo: Shell + Child Apps

Shell (Main App) Registers Child Apps

import { registerMicroApps, start } from 'qiankun'

const apps = [
  {
    name: 'app1',
    entry: '//localhost:8081',
    container: '#app1',
    activeRule: '/app1'
  },
  {
    name: 'app2',
    entry: '//localhost:8082',
    container: '#app2',
    activeRule: '/app2'
  }
]

registerMicroApps(apps)
start()

Shell page contains mount containers:

<div id="app1"></div>
<div id="app2"></div>

Child App Transformation: Expose Lifecycle Hooks

qiankun requires child apps to export bootstrap, mount, unmount. Example with Vue:

import { createApp } from 'vue'
import App from './App.vue'

let app = null
const mountApp = () => {
  app = createApp(App)
  app.mount('#root')
}

// Run standalone when not inside qiankun
if (!window.__POWERED_BY_QIANKUN__) {
  mountApp()
}

export async function bootstrap() { }
export async function mount(props) {
  mountApp()
}
export async function unmount() {
  app && app.$destroy?.() || app?.unmount()
  app = null
}

activeRule determines which child app activates based on URL routing — essentially "route-triggered loading".

Child apps must avoid global pollution and cleanly mount/unmount ; otherwise state leaks on route switches.

Inter-app communication: avoid globals; use props or a dedicated micro-frontend global store.

Webpack Module Federation Minimal Example

Share a common function/component, loading modules from another project at runtime.

Provider (Host) — Expose a Module

const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'appHost',
      exposes: {
        './myModule': './src/myModule'
      },
      shared: { vue: { singleton: true } }
    })
  ]
}

Consumer (Remote) — Import Remote Module

const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'appRemote',
      remotes: {
        appHost: 'appHost@http://localhost:xxxx/remoteEntry.js'
      }
    })
  ]
}

// Usage
const m = await import('appHost/myModule')
m.doSomething()

remoteEntry.js acts as a dynamic module manifest; the provider deploys it, the consumer fetches remote modules at runtime.

Vite + Module Federation requires @originjs/vite-plugin-federation; Webpack 5 has it built-in.

Difference from qiankun: Module Federation emphasizes shared dependencies/components , not full application shell management.

Five Practical Adoption Tips

Ask "Do we really need this?" If a single repo and well-modularized app suffice, don't add micro-frontend complexity — it can eat the benefits.

Start with a small slice. For qiankun, onboard one edge child app first, stabilize, then add more. For Module Federation, share one common component as a trial.

Communicate via contracts. Define props, events, global store fields upfront; prevent child apps from directly importing each other's internals.

Handle style conflicts and global pollution. Scope or prefix child app styles; use container DOM isolation + CSS prefixes when necessary.

Build on solid engineering foundations. Align shared dependencies (UI, utils, ESLint, CI) via monorepo practices, CI integration, and package management so remotely shared deps have a single source of truth.

Micro-frontends essentially map organizational boundaries to code boundaries. Getting the smallest closed loop running first is far safer than rolling out a full-blown solution upfront.