Why We Need Mini Programs, Micro‑Frontends, and Module Loading: A Technical Reflection

1. Mini Programs

Foreign colleagues often ask why mini programs are needed; the author explains that mini programs offer a convenient, app‑like experience within a large platform, providing reliability, security, immersion, and smooth transitions that traditional web pages lack.

Every industry has a "silver seat"; once you sit on it, everything you do feels right.

The author recounts a French colleague struggling with Chinese documentation and asks the fundamental question: "Why do we need mini programs?" He notes that while other technical solutions exist, mini programs create a low‑cost ecosystem that captures traffic and user mindshare, acting as a bridge between web and native apps.

New User Experience Mindset

Reliability: standardized constraints make mini programs feel more trustworthy than scattered web links.

Security: immersive UI without loading bars gives the impression of a local app.

Immersion: design choices reinforce the perception of an app rather than a webpage.

Smoothness: native‑like container rendering provides fluid view transitions.

These advantages can be replicated in high‑quality web apps, but mini programs lower the entry barrier and shape user expectations, creating a distinct "mindset" that benefits platform owners.

2. Micro‑Frontends

Technologies such as qiankun, wujie, and single‑spa have become popular, yet the author asks why we need micro‑frontends at all.

Micro‑frontends focus on project management rather than user experience.

They do not solve optimization or standardization problems inherently.

They are often a rescue for poorly designed SPA projects.

Silver bullet ("silver bullet") refers to an overly effective solution that is rarely realistic.

The author argues that many teams adopt micro‑frontends without understanding the underlying issues, leading to fragmented codebases, global variable clashes, and style pollution. Proper project ownership, clear responsibilities, and thoughtful architecture are more important than blindly applying micro‑frontend patterns.

Divide and Conquer

In a healthy project, the number of core maintainers should not exceed three, and each sub‑application should have a clear owner.

Micro‑frontends can help isolate navigation, environment variables, themes, monitoring, and analytics, but they also introduce sandboxing and communication complexities.

Experience Differences

For B‑side systems, the perceived benefits of SPA—smooth navigation and offline support—can often be achieved with well‑optimized multi‑page applications (MPA) that keep first‑contentful‑paint under 500 ms.

Browser optimizations already handle many performance aspects, and relying on SPA as a silver bullet can lead to unnecessary complexity.

3. Module Loading

Since the advent of Sea.js, module loading has been a core concern for front‑end developers. Modern bundlers like Webpack and Vite compile imports into self‑executing bundles, but the underlying need for dynamic module loading remains.

Typical usage:

import * from *

In low‑code platforms or event‑driven marketing sites, exposing module props to non‑technical users enables flexible composition.

Native ES modules ( <script type="module"> ) are now widely supported, though compatibility issues (e.g., import.meta on iOS 12) still exist.

Ultimately, the evolution from custom loaders to native module support reflects the maturation of front‑end infrastructure.

Conclusion

The author reflects on why Chinese developers strive for their own operating systems and standards, emphasizing the need for indigenous core technologies to shape the future rather than merely adapting to external constraints.

Hope that future technologists no longer chase the "Write Once, Run Everywhere" dream.