How to Load Vite Micro‑Frontends with ES Modules in icestark

Preface

Since Firefox 60 in May 2018, all major browsers have supported ES modules, allowing code to run without a build step.

With the emergence of ES‑module‑based build tools such as Vite and Snowpack, the frontend community entered a new wave of ES‑module adoption.

Problem Background

“All martial arts can be broken, only speed cannot—Bruce Lee”

Vite, Snowpack and similar tools bring several advantages over traditional bundlers:

Cold‑start time is extremely fast because no bundling is required.

Project size no longer limits hot‑update speed.

Traditional bundlers must rebuild the whole bundle when code changes, causing longer build times as the project grows. ES‑module‑based tools compile only the changed file, keeping the time complexity O(1).

Vite leverages native ES modules to dramatically improve developer experience. As the ecosystem (CDN services, Deno) and standards (import‑maps, import.meta) mature, the frontend is moving toward a no‑build paradigm.

In micro‑frontend scenarios, script packaging standards have been diverse (e.g., single‑SPA supports SystemJS, icestark supports UMD). The future will converge on the ES‑module standard, making ES‑module loading a strong user demand.

Loading a Vite Micro‑Frontend

Loading ES‑module Micro‑Apps

Vite outputs standard ES‑module script resources. The loading pattern is: <script src="index.js" type="module"></script> icestark requires the micro‑app to export lifecycle functions. Using a plain