How icestark Solves Large‑Scale Frontend Challenges with a Micro‑Frontend Architecture

In mid‑2017 the ICE team received the "Alibaba Creator Platform" project, a product that provides creators with onboarding, account management, content management, publishing, fan operations, and data analysis. The system contains over 50 pages, required 3‑6 front‑end developers plus some back‑end engineers, and needed to support future third‑party integrations. Traditional single‑page‑application (SPA) solutions proved insufficient, so after a detailed technical evaluation the team built a custom solution called AppLoader, which splits the system into multiple applications (repositories) and manages their loading and routing.

After two years of internal use, the team open‑sourced the solution in early 2019 under the name icestark , aligning with the growing popularity of micro‑frontend concepts.

Technical Solution Comparison

The Creator Platform has two distinctive characteristics compared with ordinary products: a very large number of pages and frequent multi‑person, multi‑requirement parallel development, plus future third‑party integration needs. The team evaluated several mainstream approaches.

Single‑Page / Multi‑Page Applications

When code volume grows, build time becomes long and development/release efficiency drops.

Upgrading third‑party dependencies (e.g., React) impacts the whole system; many pages increase regression cost.

Collaboration on many concurrent requirements is cumbersome and requires heavy process overhead.

Iframe Embedding

Slow page loading, double scrollbars, overlay issues, layout centering problems, and navigation inconsistencies.

Each embedded app still needs its own domain and deployment, raising operational cost.

Because many iframe issues are hard to solve, the team abandoned this approach.

Packaging Framework Components

Different entry points remain; the system is still a collection of multiple apps despite a unified UI.

Each app still requires its own domain and deployment.

This method fits scenarios where multiple businesses share a common UI framework, but not when services are largely independent.

AppLoader vs. icestark

AppLoader was created before the term "micro‑frontend" existed. In 2019 the team upgraded the branding and open‑sourced it as icestark .

Architecture and Concepts

The overall design consists of three layers:

Framework Application (host or base app) – responsible for overall layout, registration, loading, rendering of micro‑apps, and management of micro‑modules.

Micro Application – a standalone SPA that can run independently or be registered to the framework app.

Micro Module – shared modules or third‑party components that are dynamically loaded; unlike regular components, they are fetched at runtime.

Micro‑apps and micro‑modules are separated because their usage scenarios and technical requirements differ: a micro‑app occupies a single route, while multiple micro‑modules may coexist and need sandbox isolation and shared‑dependency extraction.

Framework Application API

The API design follows react‑router semantics (application‑level routing). The framework app is currently React‑based, with a Vue version planned.

// src/app.js
import React from 'react';
import { AppRouter, AppRoute } from '@ice/stark';
export default class App extends React.Component {
  render() {
    return (
      <BasicLayout>
        <AppRouter>
          <AppRoute path="/seller" title="Seller" url={[
            '//unpkg.com/icestark-child-seller/build/js/index.js',
            '//unpkg.com/icestark-child-seller/build/css/index.css']
          ]} />
          <AppRoute path="/settings" title="Settings" entry="//unpkg.com/icestark-child-seller/build/index.html" />
          <AppRoute path="/" title="Common Page" render={() => (
            <ReactRouter>
              <Switch>
                <Route path="/home" component={Home} />
                <Route path="/about" component={About} />
              </Switch>
            </ReactRouter>
          )} />
        </AppRouter>
      </BasicLayout>
    );
  }
}

Micro‑App Loading

Micro‑apps are typical SPAs built with React, Vue, Angular, etc. They register lifecycle hooks provided by @ice/stark-app:

import React from 'react';
import ReactDOM from 'react-dom';
import { isInIcestark, getMountNode, registerAppEnter, registerAppLeave } from '@ice/stark-app';
import App from './App';
if (isInIcestark()) {
  registerAppEnter(() => {
    ReactDOM.render(<App />, getMountNode());
  });
  registerAppLeave(() => {
    ReactDOM.unmountComponentAtNode(getMountNode());
  });
} else {
  ReactDOM.render(<App />, document.getElementById('ice-container'));
}

Routing is handled by mapping each micro‑app to a base route (e.g., /seller). The framework intercepts history.pushState, history.replaceState, and listens to popstate to detect route changes, unload the previous micro‑app, and load the new one. Rendering is performed via getMountNode() to ensure the micro‑app mounts inside the framework layout.

Micro‑Module Loading

Micro‑modules address shared resources across apps (e.g., third‑party widgets). This capability is still under development; see the issue link at the end of the article.

Sandbox Isolation

icestark focuses on controlled third‑party scenarios, prioritizing a development experience consistent with traditional SPAs. For full third‑party isolation, a render + iframe fallback is available.

Script Isolation

Using a Proxy wrapper around window, each micro‑app receives an isolated global object, preventing pollution. This logic is packaged as @ice/sandbox and can be reused elsewhere.

Style Isolation

Framework apps should rename class prefixes of shared components via build tools.

Micro‑apps are encouraged to use CSS Modules to avoid global style leaks.

Existing Issues

Micro‑frontend introduces additional technical complexity; a senior engineer should oversee the integration.

Heavy reliance on the central framework increases change risk; micro‑apps should minimize dependencies on the host (e.g., React, APIs, UI components).

Business Scenarios and Value

For large systems, micro‑frontend brings:

Reduced collaboration cost by splitting domains into independent apps.

Improved stability—each app can be upgraded independently.

Technology flexibility—new apps can adopt newer stacks (e.g., Vue 3).

Third‑party enablement—external teams can develop micro‑apps following the standard.

Portal System

In smaller companies, many isolated mini‑systems can be unified via micro‑frontend, yielding lower deployment cost, shared login/auth logic, and centralized monitoring.

Business Adoption

icestark is already used in about 20 Alibaba internal platform systems, each containing 5‑10+ micro‑apps. Notable examples include:

Alibaba Creator Platform – 20+ sub‑apps, 5‑8 built by third‑party teams.

Alibaba Health – Xiniu Medical Cloud Hospital Information System.

Taobao Operations Workbench – a backend OS for operation staff, composed of micro‑apps.

Future

The framework is largely complete; upcoming work focuses on better permission management, analytics, and other business‑driven enhancements.

Related Links

icestark repository: https://github.com/ice-lab/icestark

icestark documentation: https://ice.work/docs/icestark/about

Sandbox solution: https://github.com/ice-lab/icestark/tree/master/packages/icestark-sandbox

Micro‑module discussion: https://github.com/ice-lab/icestark/issues/104