micro-app: a micro frontend that loads like a component

Micro front-ends approached as components

micro-app is a micro front-end framework launched by JD Retail, and its stated approach is to realize the micro front-end from component thinking: rendering is based on webcomponent-like technology, so a sub-application appears in the base application as a tag rather than as a routing arrangement or a lifecycle contract. The project bills itself as the lowest cost framework for accessing the micro front-end, and backs the claim with a feature set covering the standard problems of the genre, JS sandbox, style isolation, element isolation, preloading, resource address completion, a plugin system and data communication. Framework neutrality runs in both directions, any framework can serve as the base application and any type of micro application can be embedded, which positions it as glue between teams rather than a constraint on them.

Three steps on the base side

The getting-started flow for the container application is deliberately tiny. Install the package, import and start it, then use the element:

yarn add @micro-zoe/micro-app

// main.js
import microApp from '@micro-zoe/micro-app'

microApp.start()

<!-- my-page.vue -->
<template>
  <micro-app name='my-app' url='http://localhost:3000/'></micro-app>
</template>

Two attributes carry the whole integration, name as the app identifier and url as its address, and the example places the tag inside a Vue template only because Vue is what the documentation had at hand, the element being framework-blind. That a working micro frontend is three steps and one custom element is the entire product argument, and the README's FAQ reinforces it, describing access as easy and low invasive, requiring only a small amount of changed code.

Cross-origin is not optional

The sub-application side of the tutorial has exactly one requirement, and the FAQ answers the question of whether micro applications must support cross-domain with a single word, yes. The base application fetches the sub-application's resources from its own origin, so the sub must permit that. In development the documented fix is a header on the dev server:

devServer: {
  headers: {
    'Access-Control-Allow-Origin': '*',
  },
}

In production the documentation points at nginx configuration for the same effect. Stating the constraint this plainly up front is a kindness, because cross-origin failures surface as blank panels and confusing console errors hours later if they are discovered at all, whereas here it is step two of the tutorial and the first entry of the troubleshooting mindset.

CustomElements and Proxy draw the browser line

Compatibility is governed by two newer browser APIs, CustomElements and Proxy, and they are treated very differently. CustomElements can be polyfilled, and the FAQ links the webcomponents polyfill package for browsers missing it. Proxy cannot be polyfilled, in the FAQ's own words it is not compatible for the time being, so micro-app simply cannot run on browsers that lack it. The resulting support matrix is summarized as all desktop browsers except IE, and iOS 10+ with Android 5+ on mobile, with a Can I Use link provided for checking Proxy availability in detail. For most current projects this boundary is invisible, but for teams supporting older enterprise or regional browsers it is the first and hardest question, and the documentation deserves credit for drawing the line at Proxy rather than leaving users to discover it through sandbox failures.

Vite in, Next.js and Nuxt in

The build-tool and rendering questions get documented answers rather than shrugs. Vite is supported, with an adapt-vite section in the documentation covering the integration specifics, which matters because Vite's native ESM dev server behaves differently from webpack when fetched cross-origin. Server-side rendering is supported too, with dedicated sections for Next.js and Nuxt.js, the two frameworks teams actually reach for when they need SSR. The pattern across these answers is that the framework's neutrality claim is tested where it is hardest, bundlers and renderers are where micro-frontend integrations usually break, and the documentation maintains explicit positions on both rather than declaring support in the abstract and leaving the details to issue threads. The FAQ format is itself part of the teaching, each integration question closing with a documentation link a reader can act on immediately.

A dev directory that is a framework zoo

The repository's development scripts reveal how the neutrality claim is actually tested. Under dev/ live multiple base applications, main-react16, main-vue2 and main-vite, and a children directory containing react16, react17, vue2, vue3, vite2, vite4 and angular11, a cross-product playground where combinations of container and sub-application can be run against the framework source. The bootstrap script installs all of them serially, start:main-react16 and its siblings run a base alongside every child simultaneously while rollup rebuilds the framework in watch mode, and the whole arrangement means a pull request that breaks Vue 3 or Angular 11 integration has a chance of being caught before merge. Build output ships as a UMD bundle, an ESM module and TypeScript definitions, and commitlint plus a .claude directory for coding assistants round out the tooling. For contributors, DEVELOP.md and its Chinese edition enumerate the remaining commands beyond bootstrap and start.

Still shipping release candidates

Version status deserves a clear-eyed look. The current package is 1.0.0-rc.32, with rc.30 tagged 2026-04-20, rc.31 on 2026-06-09 and rc.32 on 2026-06-25, a long release-candidate series that has not yet closed into a final 1.0, and the repository was last pushed on 2026-09-21, so work continues while the label lingers. The project carries bilingual README and development documents, a Contact.md channeling community through WeChat, GitHub Discussions, Travis CI with Coveralls coverage, and the MIT license. Against qiankun, the other widely known Chinese micro-frontend framework, the difference is declaration style: qiankun integrates sub-apps through exported lifecycle functions, while micro-app integrates them through a custom element carrying a name and URL, and which reads better to a team is largely a matter of which shape their existing code already resembles.

Editorial conclusion

Choose micro-app when you want micro front-ends with the smallest possible integration footprint, a custom element with a name and URL on the base side and cross-origin headers on the sub side, and when your browser matrix excludes anything lacking Proxy. Choose qiankun if your organization already runs its lifecycle-export style of integration, since the two frameworks differ mainly in how sub-apps are declared. Verify first that every sub-application can serve cross-origin resources, that Vite or SSR support matches your stack via the documented adapters, and weigh the release-candidate maturity of the 1.0 line before standardizing on it.

Frequently asked questions

Official sources

1. jd-opensource/micro-app on GitHub
2. License: MIT
3. Project website
4. README
5. Releases