From Iceworks 1.0 to 4.0: Lessons in Building a Scalable Frontend IDE

Iceworks, first released in March 2018, began as a material‑based GUI desktop client aimed at lowering the front‑end development threshold by shielding developers from complex project environments.

Iceworks 1.0 & 2.0

Timeframe: 2018.3 ~ 2019.4

Version 2.0 pursued two core ideas: boosting efficiency through material reuse and simplifying the engineering workflow via a GUI, resulting in a workflow that spans project initialization, page building with blocks, visual debugging, Git version control, and CDN deployment.

The main functional points are illustrated below:

Because the product is "material‑based," materials dominate the UI, while engineering operations are placed prominently with built‑in npm and Node support.

Data collection was limited to DAU and sparse operation counts, insufficient for thorough product analysis. Reported usage statistics include:

Daily active users exceed 800 and remain stable.

Average users launch Iceworks twice per day, with one in five exiting the same day, indicating low overall usage duration.

Nearly half of users create projects via templates, over half use blocks to build pages, and the most used feature is starting debugging.

Technically, Iceworks 2.0 uses an Electron‑based architecture: the renderer loads a front‑end app built with ICE 1.0, while the main process is a custom Node application handling file operations and npm commands, communicating via Electron IPC.

Key front‑end modules include:

Library : utilities such as FileSystem, GitTools, and ProjectScripts.

View : a React view layer with reusable components and plugin‑style project panels.

Store : MobX‑based stores for global and local state, interacting with Library and the main process.

Node modules are organized as:

Base : common services like Logger, DataCollector, and Storage.

Sessions : shell command execution via node‑pty, managed by a Session Manager.

Scaffolder : GUI‑to‑code capabilities for creating pages, routes, menus, etc.

Services : APIs exposed to the front‑end.

Problems in Iceworks 2.0

Product : Low user dependency, limited to project initialization and debugging; stability issues reflected by numerous undefined error logs; heavy reliance on user feedback.

Technical : Unclear module responsibilities, tangled calls, accumulated hack code, missing CI, monitoring, and logging, leading to long feature iteration cycles (2‑3 weeks), half‑day release processes, and difficulty reproducing issues.

The team also lacked deep expertise in npm execution, node‑pty, and electron‑builder, relying on ad‑hoc problem solving.

Iceworks 3.0: "Reversing Chaos" with Visual Assistance

Timeframe: 2019.4 ~ 2019.10

To end product chaos, reduce technical debt, and build team capability, Iceworks 3.0 was launched around April 2019 with goals of simplicity, friendliness, stability, maintainability, and extensibility.

What Did 3.0 Add?

The workbench was reorganized into four sections: project development, engineering chain, material management, and personalized settings. Core principles:

Efficiency is the primary goal, focusing on the coding phase which consumes ~80% of development time.

Engineering tools are secondary, used less frequently.

Materials remain central but are now consolidated into a dedicated module.

Red parts indicate new features; strikethrough indicates removed features.

Key additions:

Visual configuration : GUI for routing, menu, and build settings.

Multiple themes : Light and dark modes.

Multi‑language support for future internationalization.

Key removals:

High‑error, high‑maintenance features like the terminal (replaced by GUI interactions).

Low‑usage features such as custom templates and block‑based page building (usage stats shown below).

The new architecture is Web‑based, similar to VSCode and Theia, enabling seamless adaptation across CLI tools, desktop clients, and online versions.

A lightweight state‑management solution called icestore was introduced for the front‑end.

The server side uses Midway with three routes handling project operations, material management, and personalized settings, providing file manipulation and shell command execution.

An Adapter layer abstracts module operations (e.g., routing, menu, page) into a standardized API, allowing easy extension to other project types (CRA, Vue) and improving architectural extensibility.

Further details on the Adapter pattern will be covered in a dedicated article.

Data collection was enhanced by aggregating user actions per domain (project/engine/material/settings) and module (Git/Menu/Page), enabling comprehensive usage analytics for future product decisions.

Logging improvements include a front‑end Logger that uses ARMS for error collection and a server‑side egg‑logger that forwards logs to SLS for continuous analysis.

Impact of Iceworks 3.0

Key metrics after release:

30% of users migrated to CLI usage, with daily installations stabilizing around 40.

Average page creation increased by 24% and template usage by 45% compared to 2.0.

Nearly all users now use the menu‑creation feature daily; one in two uses route creation; 20% adopted the dark theme.

Adapter support achieved 100% compatibility with both new and legacy ICE projects.

Technical gains include a 37% reduction in code size while retaining 90% of 2.0 functionality, 65.54% test line coverage for the Adapter layer, a 51% increase in effective error‑log coverage, and release time cut from half a day to 30 minutes, effectively relieving technical debt.

Iceworks 4.0: "Seeking Breakthrough" with an Integrated Development Workbench

Timeframe: 2019.10 ~

Why Build Iceworks 4.0?

Three main challenges emerged after 3.0:

How to handle the desktop client version of Iceworks 2.0.

How to achieve breakthrough efficiency and lower the entry barrier for enterprise‑level development.

How to better serve Taobao’s internal backend development.

Simply wrapping 3.0 in an Electron shell was deemed unnecessary because the tool’s auxiliary nature does not justify a dedicated desktop client.

For the second challenge, options like VSCode plugins, Sublime plugins, or browser extensions were considered insufficient for an enterprise‑grade, integrated development workflow; a web‑based IDE aligned with the trend toward serverless, cloud‑native development.

The third challenge highlighted the shift of Taobao’s backend development to an online product‑research platform, requiring cloud‑centric tooling.

Consequently, the Iceworks IDE concept was born: a web‑based IDE that can produce both desktop and online versions, offering standardized enterprise development processes, visual low‑code/pro‑code integration, and a plug‑in architecture.

IDE Direction and Features

Red parts indicate new features; strikethrough indicates removed features.

Planned capabilities include:

Visual development based on materials : insert components or blocks directly, configure properties and styles via GUI, and create custom material sources.

Drag‑and‑drop assisted coding : fully visual page construction, mixed source‑code and visual editing, and layout adjustments in preview mode.

Visual configuration of framework, engineering, state management, and data sources.

These functions will be delivered incrementally as PoCs.

Technical Implementation of the IDE

The 4.0 architecture builds on Alibaba’s IDE Framework, encapsulating local IDE integration, reusing Iceworks 3.0’s adaptation layer as plug‑ins, and producing a desktop client.

A detailed article on the 4.0 technical architecture will be published later.

Release Timeline

Iceworks IDE is still in internal incubation, currently piloted in Taobao’s internal platform. An external release is planned for mid‑December, with early focus on user retention and later emphasis on measuring productivity gains.

Conclusion

Changing entrenched practices is risky, but staying static prevents breakthroughs; the team continues to experiment boldly while validating ideas carefully.

All Iceworks source code and discussions are available on the GitHub repository.

Iceworks 2.0 PRs: dependency management, code style, documentation, logging, etc.

Iceworks 3.0 PRs: project operation standardization, Adapter pattern, data collection, log monitoring, front‑end logging, server unit tests.

Iceworks 4.0 will also be open‑sourced at an appropriate time.

Cover image credit: "Sunset in Sabah"