Unlocking Bundleless Frontend: Ant Group’s Cloud Phoenix Uses ES Modules for Low‑Code Asset Loading
Ant Group’s Cloud Phoenix platform demonstrates a Bundleless asset loading strategy that combines ES Modules, NPM imports, and fine‑grained tree‑shaking to deliver low‑code, on‑demand component delivery, addressing performance bottlenecks and redundancy in enterprise middle‑office applications while paving the way for future ES Module‑centric development.
Theme Introduction
Today’s talk focuses on three keywords: ESM (ES Module, the current browser standard), Bundleless (emphasizing less bundling), and low‑code (a hot front‑end topic that improves development efficiency through visual/configuration approaches, the direction of our “Cloud Phoenix” team).
Cloud Phoenix "Open" Asset System
Before designing a building system, the primary question is where components come from. Building a component library is costly; for example, a single Ant Design component requires at least two weeks of development and testing. Cloud Phoenix already has access to world‑class libraries such as Ant Design and AntV, allowing us to reuse them directly.
How to Acquire Components?
There are two conventional approaches: integrate the libraries into the platform and manage versions and bundling, or consume them dynamically through a specific component specification. Because business‑specific components cannot all be baked into the platform, a low‑code asset system must provide an open capability to decouple assets from the platform and connect them via standards.
NPM Import
We chose NPM import as the bridge for Cloud Phoenix’s asset system. After entering the NPM package name and version, the platform parses the exported React components, loads them, and makes them available on the visual canvas for property editing—essentially as smooth as npm install.
During NPM import, the package is dependency‑split and rebuilt, with the resulting assets uploaded to an Assets CDN. When a user edits a page, the system detects dependency changes, merges versions, and resolves the combined dependency graph.
At runtime, the merged dependencies are fetched via CDN combo in a single request, then handed to SystemJS for module instantiation.
Bundleless 1.0 Achievements
Full integration with the NPM ecosystem, providing abundant components and avoiding duplicate development.
Dependency reuse following SemVer version merging.
Package‑level on‑demand loading—only the needed packages are fetched.
Real‑time preview, rapid deployment, and debug support.
Next‑Generation Challenges
Despite supporting hundreds of middle‑office applications, we observed two main issues:
Performance bottlenecks: even with on‑demand loading, asset loading remains a runtime slowdown. Analysis of Ant Design shows that only about 40% of its 62 components are used on average, leading to roughly half of the bundle size being redundant.
Technical stagnation: our asset system still relies on technologies 5‑6 years old, which is insufficient for modern standards.
Opportunities and Challenges of ES Modules
Browser support (except IE11) is strong, and single‑module loading performance is 1.3‑1.5× faster than SystemJS. However, deep dependency trees cause request waterfalls, and ES Modules cannot use CDN combo directly.
V8’s 2018 guidance suggests ES Modules are suitable for small web apps (modules < 100, depth < 5). By analyzing Cloud Phoenix’s asset usage, we believe we can prune complexity to meet these thresholds and migrate to ES Modules in production.
Solution Design
Bundleless Granularity
The granularity of splitting determines module count, dependency‑tree complexity, and reuse. Fine granularity yields many small modules with high reuse and smaller total size; coarse granularity yields fewer, larger modules. Our tests show package‑level granularity balances request volume and production feasibility.
Export‑Level Dependency Analysis
We perform AST analysis on each NPM export to build an export‑level dependency graph, enabling true component‑level tree‑shaking. This handles CommonJS exports and Babel‑plugin‑import transformations.
Dependency Merging
Based on actual component consumption, we merge dependencies to produce a tree‑shaken graph. Strategies include collapsing isolated deep nodes and bundling common sub‑dependencies shared by multiple exports, reducing the total number of dependencies to under 100 and depth to under 5.
Importmap – The Last Mile
Browsers only understand relative paths for ES Modules, not bare specifiers like import React from 'react'. We adopt the standard importmap approach, allowing version updates by modifying a single map rather than rebuilding all dependent files.
Preload Optimization
Using modulepreload to pre‑fetch the deepest sub‑dependencies yields an additional 1.3‑1.5× load‑time improvement.
Future Vision
With ES Modules becoming the norm and tree‑shaking maturing, future low‑code and pro‑code platforms can rely on a unified ESM build pipeline to solve dependency reuse across isolated environments, eliminating the need for DSL conversions or micro‑frontend hacks.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Alipay Experience Technology
Exploring ultimate user experience and best engineering practices
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
