摘要：與是一種標準，是對該標準的一個實現。因此支持了返回多個同級節點的功能，如這一特性可以有效減少頁面的嵌套層級，從而減少應用因嵌套層級過多而出現的問題。未來這是口號，亦是目標。

Rax is a universal JavaScript library with a largely React-compatible API. If you use React, you already know how to use Rax.

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

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

Rax 與 React
React 是一種標準，Rax 是對該標準的一個實現。Rax 只是無線端的解決方案，與 React 并無沖突。事實上淘寶 PC 端的新項目，依然主要是基于 React。當然，Rax 跟 Preact 之類的方案也有本質區別，前者偏向于解決多端問題，后者偏向于解決性能問題，具體可參考下文「Rax 的特點」。

Rax 的特點
1、設計上支持不同容器

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

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 未來的重要目標之一。

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

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

了解更多 Rax 相關內容，歡迎訪問 alibaba.github.io/rax

Rax 團隊敬上。

參考文章: http://taobaofed.org/blog/201...