How Rax Redefines Frontend Rendering for Faster, Lighter User Experiences

Rax’s Front‑End Evolution

Alibaba’s open‑source framework Rax has been continuously refined to deliver better user experiences, from Web and Weex to Node.js and FaaS. The 2020 Double 11 event served as a large‑scale testbed, showcasing Rax’s focus on lightweight, adaptive, and personalized rendering.

1. Lightweight Bundles

Reducing bundle size directly shortens JavaScript parsing and compilation time. On low‑end Android devices the initial JS bundle can take 300 ms or more, a significant portion of perceived latency. Rax 1.0 introduces Hooks, cuts core code from 57 KB to 17 KB, and produces smaller bundles without sacrificing functionality.

2. Adaptive Hydration Rendering

Rax’s hydration can adapt to mismatched DOM structures. Unlike React, which may re‑render or fail to adjust attribute differences, Rax repairs text, attribute, and node mismatches and removes obsolete nodes, ensuring correct rendering even when the server‑generated HTML differs from the client bundle.

3. Snapshot Rendering

Snapshot rendering stores a page’s state and replays it on the next visit, providing an instant first view. Combined with adaptive hydration, Rax updates the snapshot to the latest state without flashing, improving perceived speed.

4. Server‑Side Rendering (SSR)

Initial attempts to implement SSR in C++ suffered from inefficient type conversion, yielding slower performance than pure JavaScript. The final solution pre‑computes strings during compilation, delivering rendering speeds up to eight times faster than React and surpassing Alibaba’s legacy xtpl engine.

-----------compare renderToString----------</code>
<code>React(16.12.0)#renderToString x 1,664 ops/sec ±1.40% (84 runs sampled)</code>
<code>Rax(1.0.13)#renderToString x 13,411 ops/sec ±1.05% (85 runs sampled)</code>
<code>Preact(10.0.5)#renderToString x 1,237 ops/sec ±2.18% (84 runs sampled)</code>
<code>Xtpl(3.4.2)#renderFile x 11,335 ops/sec ±8.17% (69 runs sampled)</code>
<code>The benchmark was run on:</code>
<code>   PLATFORM: darwin 17.5.0</code>
<code>   CPU: Intel(R) Core(TM) i7-7660U CPU @ 2.50GHz</code>
<code>   SYSTEM MEMORY: 16GB</code>
<code>   NODE VERSION: v10.11.0

5. Native Side Rendering (NSR)

NSR mirrors SSR’s rendering logic but executes on the client, delivering SSR‑like performance without a server. Compared with traditional CSR, NSR reduces the time to first paint while keeping the workload on the device.

6. Personalized Rendering

Different devices and network conditions require different rendering strategies. For users on weak networks or low‑end hardware, NSR or SSR may be preferable, while high‑performance devices can use CSR. The goal for Double 11 2020 is to keep the first‑screen interactive time under 3 seconds for the majority of users and reduce the proportion experiencing delays beyond 7 seconds.