Inside Alibaba’s Cube: From Hybrid Web to a Custom Mobile Rendering Engine

Background

Alipay client dynamic technology has passed three stages. The first stage was a native + web hybrid model based on WebView. The second stage introduced entity components that map HTML and CSS to native components and forward events to JavaScript. The third stage combines entity components with partial rasterization, and Cube is the product of this stage.

Technology Selection & Evolution

Cube emerged around 2016‑2017, roughly a year after React Native. Its creation was driven by the need to make native pages dynamic, especially for frequent wallet redesigns. Observing RN and Flutter highlighted industry approaches to dynamic UI, but Cube chose an independent path.

Key consensus:

Independent development, full control. The team avoided RN or Flutter source code to keep the tech stack under its own control and reduce productization and maintenance costs.

Serve the business, limit technology. Focus on wallet‑specific needs, avoid over‑engineering, and prioritize business value over flashy demos.

Based on this, the technology choices are:

Use JavaScript as the logic language.

Adopt a subset of CSS as the UI description language.

Employ a mixed rendering mode of custom‑draw (text/img/div/scroller) and native components (input, animation, map, audio, video, …).

Alibaba’s front‑end experience led Cube to embrace JavaScript and CSS, using QuickJS as the default engine (instead of V8, which is heavier). A third‑party WebAssembly runtime (WAMR) is also integrated, supporting mixed JavaScript and AssemblyScript development.

Current Status

Cube supports two main business forms: Cube cards and Cube mini‑programs.

Cube cards add regional dynamic capabilities to native pages, improving iteration speed. Simple cards lack JavaScript and rely on expressions and v‑if/v‑show for DOM control, while complex cards include JavaScript for richer interactions. Over 100 billion page views have been recorded across various wallet tabs and secondary pages.

Cube cards primarily serve first‑ and second‑party wallet services; for third‑party developers, widget‑style mini‑programs are recommended. Efforts are underway to expose card capabilities to smaller financial institutions and internet companies.

Cube mini‑programs adopt the standard mini‑program stack (container, front‑end framework, rendering engine, script engine). Compared with the default UC engine, Cube offers advantages in package size, startup speed, list‑scroll smoothness, and memory usage, though its CSS support is limited. Since 2019, significant effort has been invested to enrich CSS capabilities, making Cube one of the most complete non‑browser rendering engines for CSS (supporting flex, inline, block, pseudo‑classes, z‑index, positioning, etc.).

Cube mini‑programs have also been explored on IoT devices and TV set‑top boxes, where they show notable performance benefits over traditional mini‑programs.

Technical Architecture

Cube consists of two major modules: CubeKit, which bridges the JavaScript engine and abstracts platform differences (also providing debugging tools), and CubeCore, a C++ implementation of the rendering core.

Mini‑programs support a tinyApp‑DSL subset, running on JScore/V8 on mobile and QuickJS on IoT. Cube cards use a simplified Vue‑based card‑DSL. Simple cards render by parsing an AST, while complex cards allow limited JavaScript logic driven by QuickJS to update the DOM.

On mobile, Cube and web mini‑programs share the same container code; on IoT, the team continues to integrate the container vertically with the platform.

Performance data for TV mini‑programs: package size 5.5 MB, memory consumption 32 MB, cold‑start 3‑4 seconds. Ongoing vertical integration aims to further improve these metrics.

Quality System

Testing alone cannot guarantee engine stability; hidden bugs may accumulate and cause sudden failures. Therefore, Cube built an automated sample‑execution framework called KITE, inspired by the browser WPT suite, to run daily automated checks on core capabilities.

Toolchain

Cube’s direct customers are internal developers. Early‑stage tooling—debuggers, preview containers, logging, low‑code platforms—is crucial. Over time, the toolchain has become as important as the engine itself, influencing adoption decisions and maintaining developer satisfaction.

Review & Future Plans

Over the past five years, Cube survived many challenges thanks to persistent investment from leadership and dedication from engineers. Future directions include:

Exploring deployment on IoT devices with 32 MB memory / 400 MHz CPUs.

Expanding Cube mini‑programs on large‑screen TV platforms and investigating commercial models.

Subsequent articles will dive deeper into the card stack, mini‑program stack, quality framework KITE, tool ACT, and performance optimizations.