如何看待阿里開源的Rax框架？

01-04

原文鏈接：Why Rax?
利益相關：原文作者，Rax 打雜工程師

Why Rax?

從 2017-01-12 在 Weex Conf 上宣布 Rax 開源，至今已過去一個月左右的時間，這段時間裡，Rax 拿到 2400+ 的 star, 我們深知這對一個開源產品來說是微不足道的，但是從中可以發現的是「前端或者 Weex 社區對於類 React 的技術方案是有很大需求的」。同時，結合近期 Github 上的相關 issue, 大抵上就有了這樣一篇完整介紹 Rax 的文章。

淘寶無線端的發展歷程

在前端這條道路上，淘寶 FED 一直以來的使命就是「用技術為體驗提供無限可能」，Rax 自然也是在追求體驗的道路上發展出來的。

從 2014 年開始，結合阿里雙十一雙十二的數據變化，無論從用戶訪問量還是最終成交量上都可以清晰的看到：「移動端已然是當下業務的主要陣地」，當業務重心向移動端偏移時，技術也在悄然發生變化，傳統而成熟的 PC 端技術方案儼然已經無法滿足移動端對體驗性能、開發效率等各個方面的要求，這也開啟了我們在無線端上的技術探索之路。

kimi

2014 年伊始，算是阿里無線業務起步的階段，那時候大家把無線頁面還稱為 H5, 諸如 Kissy, jQuery 之類的庫對於無線頁面來說尺寸太大、載入太慢，於是我們基於社區成熟的 Zepto 迅速打造了 kimi 這個核心庫，然後圍繞業務不斷完善 kimi 的組件生態以及包含工程化、性能檢測等一系列生態。這套生態伴隨著我們走過了將近兩年時間，至今仍可以在一些頁面上找到 kimi 的影子。

然而，kimi 始終是一個 web 端的解決方案，即便可以通過一些方案去調用 Native 的原生方法，也無法跨域無線端上 web 體驗不及 Native 體驗這樣一個既定事實。於是，如何能讓頁面達到 Native 的體驗成為我們的下一個探索點。

react-web

說起 Native 的體驗，最直觀的方案就是直接去寫 Native 代碼，然而 Native 的開發模式一直存在一些難以解決的問題：

成本與效率：iOS, Andriod, Web 三端需要不同的技術團隊各自開發一套，成本大，效率低
靈活性：受限於 AppStore 的審核機制，版本發布周期較長，難以滿足業務需求

所以，我們需要一套基於 web 的開發模式但可以產出 Native 頁面的解決方案，效率與體驗兼得。在這個思路下，阿里也有過一些嘗試，不過都沒有形成最終的解決方案，這裡就不再詳細講述了。直到 2015 年中期，Facebook 開源了 React Native(RN), 雖然初期只有 iOS 的版本，但絲毫不影響其對整個無線開發方案的巨大衝擊。RN 基本完美解決了需要編寫兩端代碼的問題，同時還有一個非常活躍完善的 React 社區，因此這個方案也得到了諸多開發者的青睞。

接著，我們也快速在手淘里嘗試了 RN 的方案，受限於 RN 的兼容性問題以及用戶可能在瀏覽器端打開頁面，因此整個頁面必須要有能力降級到 web 版本。這時候回想下 RN 的口號：learn once, write anywhere. 但這對於我們來說，或許還不夠，我們真正需要的是：write once, run everywhere.

因此我們開始探索如何讓 RN 的代碼運行在 web 端，這就是 react-web 方案。

Rax

2015 年雙十一，Weex 的方案開始逐步使用，經過這次試水，證明了這套方案未來的場景及可行性，接著 2016 年 Weex 開始進入快速發展的階段。但是使用 Weex 就意味著必須用 Vue 的語法，這對於整個團隊來說是一個不小的挑戰：PC 場景下的項目，小夥伴們普遍基於 React 開發，已經有了相當多的經驗與沉澱。如果無線的項目要採用一個不同方案（Vue）去做，強推未必會不奏效，但是小夥伴們大概會傷心吧。

於是我們嘗試將 React 與 Weex 結合起來，但是由於方案太過 hack 導致各種問題，遂無奈放棄。接著 Rax 的方案應運而生：「Rax 基於 React 的標準，支持在不同容器中渲染，當前最重要的容器即 Weex 和 Web」。

Rax 體系

Rax 與 React

React 是一種標準，Rax 是對該標準的一個實現。

社區里很多人關心 Rax 與 React 的優缺點以及相互取代的可能性，事實上，從上文的發展歷程就可以看出來，Rax 只是無線端的解決方案，與 React 並無衝突。事實上淘寶 PC 端的新項目，依然主要是基於 React，並且我們也有一套基於 React 的解決方案名為 ICE，通過一系列的工具幫助開發者提高效率，此處不再展開。

當然，Rax 跟 Preact 之類的方案也有本質區別，前者偏向於解決多端問題，後者偏向於解決性能問題，具體可參考下文「Rax 的特點」。

Rax 的特點

1. 設計上支持不同容器

Rax 在設計上抽象出 Driver 的概念，用來支持在不同容器中渲染，比如目前所支持的：Web, Weex, Nodejs. 基於 Driver 的概念，未來即使出現更多的容器（如 VR 等），Rax 也可以從容應對。Rax 在設計上盡量抹平各個端的差異性，這也使得開發者在差異性和兼容性方面再也不需要投入太多精力了。

詳細內容可參考 Rax Driver Spec.

2. 體積足夠小

如上文所說，Rax 是一個面向無線端的解決方案，因此自身的體積對於性能來講就顯得非常重要。Rax 壓縮 + gzip 後的體積是 8.0kb, 相比 React 的 43.7kb, 對於無線端友好了很多。

3. 支持返回多個同級節點

任何用過 React 的同學大概都踩過同一個坑：方法返回了多個同級節點導致報錯。在設計上 React 只能返回單個節點，因此頁面上或多或少會產生一些冗餘的節點，這在 PC 端並沒有太多問題，然而在無線 Android 端嵌套層級越多，應用的 crash 率會不斷提高，這一點在低端 Android 機上表現尤其明顯。因此 Rax 支持了返回多個同級節點的功能，如：

import {createElement, Component, render} from "rax"; class Test extends Component { render() { return [1, 2, 3].map((item) =&> { return &

{item}&; }); } }

這一特性可以有效減少頁面的嵌套層級，從而減少應用因嵌套層級過多而出現的 crash 問題.

4. 標準化

在上文里，我們不斷的提各個端的一致性，一致則必有規範可依，Rax 遵循 w3c 標準，比如在 weex 容器中已經可以直接調用 navigator, document, location, alert 等 w3c 的標準 API.

當然，受限於各個端的差異，標準化的道路還很長，「更標準化」這也是 Rax 未來的重要目標之一。

RAXUI

Rax 旨在解決多端一致的問題，這幫助我們無需關注各個端的差異性，實現「Write once, run everywhere」的願景。然而在前端開發領域，開發人員需要直面的還是 UI 體系，不同項目間夜以繼日的開發著功能類似的組件，想想就覺得頭疼，因此 Rax 在最基礎的元件 rax-components 之上實現了一套官方的 UI 組件，即 RAXUI.

RAXUI 是 RAX 上層的一套通用 UI 組件，幫助開發者快速完成模塊和頁面的開發。比如 picture 組件是對元件里的image 做了一層封裝，包含圖片優化、h5 懶載入等更多功能，tabheader 組件可以幫助開發者便捷的實現橫向滾動導航......RAXUI 不僅能降低業務的開發成本，同時為了保證產品質量，RAXUI 在兼容性、性能、設計規範等很多方面都有更多更完善的考慮。在不久的將來，這套 UI 體系也會逐漸向社區開放。

未來

Write once, run everywhere. 這是口號，亦是目標。Rax 未來會在更多的端上不斷探索，比如 VR/AR, 甚至之前微博上有同學提出的是否可以用 Rax 寫微信小程序，也是一個蠻有意思的想法。

對於開發者來說，當越來越多的端不斷出現在眼前時，我們應該如何應對？是通過不斷的踩坑來整理一份長長的 checklist, 然後做項目時一一對照？或者讓我們一起來探索 Rax?

Rax 團隊敬上。

如何看待阿里開源的Rax框架？

Why Rax?

淘寶無線端的發展歷程

Rax 體系

未來

相關鏈接