弗申：跨端框架的标准化研发模式

前端早早聊大会，与掘金联合举办。加 codingdreamer 进大会技术群，赢在新的起跑线。前端

第二十八届|前端 WebGL 专场，2021 年要不要押宝 WebGL 弯道超车，6-26 全天直播，9 位讲师(阿里云/蚂蚁/美团/小米等)，报名上车👉 )：react

正文以下

本文是第十七届 - 前端早早聊框架专场，也是早早聊第 119 场，来自淘系 - 弗申的分享web

开场介绍

你们好，我是来自阿里巴巴淘系技术部前端架构团队的弗申，今天我给你们分享的主题是如何实现跨端框架的标准化研发模式。算法

前端发展到如今，工程架构日趋复杂，业务须要投放到的容器也不尽相同，那么你们在不一样的业务领域可能会有本身不一样的业务诉求，在大背景下怎么去打造一个标准化的研发模式，以及一个同基础通用的跨端研发框架，这件事情变得更加剧要。npm

由于技术体系的发展决定了业务架构的鲁棒性，因此接下来我会围绕阿里巴巴集团使用面最广的渐进式 React 的框架 Rax，来给你们分享一下咱们在框架设计方面的一些思考，以及在此次分享过程当中会从一些比较小的点，着手分析业务中是真实会遇到的问题，而后讲解咱们是怎么去解决以及思考的。json

提纲

咱们来先简单看一下此次分享的提纲，主要是四个部分，重点是前面两个部分。redux

为何咱们须要一个跨端方案
跨端方案的设计思路
总结
其它

在设计框架的时候，咱们须要用到三段式思惟方式来完成设计，就是 Why、What、How。小程序

为何须要跨端方案

产生缘由

Rax 的跨端方案诞生的时间大概是在2015年，容器在不断的发生变化。由于当时有 WebView，而后有 ReactNative，还有 Weex。对咱们当时社区有了 React Native 的状况下，为何咱们要有 Rax 呢？后端

首先第一个是当时咱们阿里巴巴集团的前端大部分的技术栈，因为咱们当时是 Allin 无线，因此你们的技术栈仍是在 React 那边，所以在集团有 Weex 的状况下，咱们须要让开发者可以使用 React 来开发 Weex，而且同时咱们的业务须要投放到 Web，那么咱们跨端方向的一个大背景就是容器在不断发生变化。

第二个就是一次编写，须要多端投放的业务诉求。

第三个就是前端技术生态比较丰富，咱们但愿可以尽量的运用前端生态技术来解决一些跨端的问题。

诞生背景

Rax 诞生的背景就是 React 加上 Weex，即 Rax 是一个渐进式的 React 框架。在社区有了 React Native 的状况下，为何须要 Rax ？Rax 解决了哪些问题？React Native 首先在那个时代背景下是无法支持 Web 的业务场景的。发展到如今 React 也有本身的 React Reconcile 的概念，能够基于它去作一些多端的事情。可是在当时那个时候是没有的，然而咱们的业务又有须要投放到 Web 的场景，这是一个强诉求。

第二点是 React Native 相似方案 Weex 的诞生，可是 Weex 当时是 DSL 是 hack 了一份 Vue 对与咱们的 PC React 为主的技术栈是不匹配的。

第三个是咱们尝试将 React 和 Weex 直接相结合的时候，发现有不少问题，包括一些性能上的问题。实际上你们对 React 是比较了解的，其实能够看到 react-dom 这个包，它在 gzip 以后，其实体积仍是比较大的。

解决问题

Rax 解决了什么问题， Rax 主要核心解决了下面三个问题。

跨端：Rax 跨端跨了哪些端：Web、Flutter、小程序、Weex。
轻量：咱们的核心库是足够轻量的，不管是从核心库的角度，仍是从业务工程角度，咱们的核心都是但愿在无线场景下，业务的代码可以足够轻量。由于在一些弱网条件下，或者说一些低端机上面，咱们须要可以让业务方 JS 的 Bundle 体积更小。
开箱即用：开箱即用的研发框架，其中包含了最佳实践，不管是从工程的上手难易度，仍是从功能的丰富程度这些角度上面来讲，相比于社区而言都是先进的方案。咱们但愿可以给到用户的就是咱们认为最好的解决方案。

使用状况

由于这一切的缘由，因此诞生了 Rax。因此在目前为止，由于 Rax 发展了到今年已经大概是第5年了。 Rax 已经普遍的应用在阿里巴巴集团的各个场景，包括历年的双11，覆盖的 BU 有淘系、飞猪、优酷、阿里巴巴等等。

跨端方案的设计思路

接下来我给你们分享一下咱们跨端框架的设计思路，但愿可以让你们在作业务技术选型的时候，或者说是在架构设计的时候，给你们带来一些帮助和启发。

总体介绍

咱们先来看一下框架体系的概览。首先底层咱们的 DSL 的标准是遵循 React 的，Rax DSL 再加上一个 JSX Plus 的规范，你们对 JSX Plus 可能不够了解，给你们简单介绍一下：JSX Plus 实际上就是可以在 JSX 上面去用一些简单的指令，好比说像 Vue 里面的 v-if，或者说 v-for 经过指令来作一些更加简便的操做。

往上面就是咱们的工程体系，工程体系的最底层是 Build Scripts，这个是基于“阿里巴巴前端委员会”共建的一套工程体系底层能力，可让开发者经过插件的方式扩展 Webpack 配置。再往上是 Rax-App 研发框架，这套研发框架是基于Build Scripts 去设计的，其中包含了丰富的运行时功能，以及开箱即用的工程配置能力，最终可以让你们的代码实现一码多端，也就是一次编写就能够跑在多个容器上面。更上层是咱们的基础生态体系，包括跨端基础组件，以及跨端 API。往上最后一层就是生态体系，包括组件库等等。

咱们但愿这一整套体系给到开发者的是：开发者不用去关心底层容器是什么，只须要使用 Rax 提供的 DSL ，包括咱们提供的工程，以及多端体验一致的一些生态体系、组件、 API 等等，就能够运行到 Rax 支持的全部容器当中。好比说 Web 、小程序，这里小程序包括微信小程序、阿里小程序、字节跳动小程序等等。还有 Flutter ，基于 Kraken 方案的一个 Flutter 的方案。而后还有 Weex 等等。

DSL 设计

接下来我给你们介绍一下咱们的 DSL 设计。

Rax DSL 自己是遵循 React 的标准的，也就是说开发者彻底能够用熟悉的 JSX 语法来开发业务，而后没有任何的上手成本。固然和 React 相似，Rax 也是一样是基于 VDOM 的，为何选择 VDOM ？有些同窗可能会说 VDOM 树能够减小操做真实 VDOM 的频率，从而提高性能。其实事实并不是彻底是这个样子的，由于 VDOM 带来的性能优点历来不是最大的，在现代浏览器中直接操做真实 DOM 效率或者说是性能，可能比 VDOM 的效果更好，性能更高。

那么咱们为何选择为 VDOM 呢？VDOM 给咱们带来了主要是有两方面的收益：

标准化数据结构：咱们能够经过一个树状的 JSON 格式去描述咱们的整个 UI 视图，即 UI = fn(state) 。
与容器渲染解耦：前端业务代码能够和容器解耦，目前咱们将真实操做 DOM 视图的操做，经过 VDOM 作了一层隔离，也就是说业务自己不须要过多的接触到容器真实渲染的逻辑，从而咱们能够帮助业务达到跨端的这么一个目的。

接下来给你们介绍一下咱们基于 VDOM 怎么去作一个跟容器解耦的事情。咱们是基于 Driver 的概念，站在今天这个角度来说的话，你们可能比较熟悉的一个概念是 React 中的 reconciler。其实这种方案和理念， Rax 比 React 提出的要更早一些。也就是说咱们经过 Driver 实现的这些让你们乍一看很像 DOM API 的函数，可以抹平对应容器的渲染能力。好比说 getElementById 这个方法，在 Rax DSL 里面，由于咱们在 Rax 核心库里面至关因而直接去调用的 Driver.getElementById 方法，因此 Rax DSL 自己是不关心 getElementById 是怎么实现的，咱们能够针对特定的容器来实现这个方法，从而达到跨端的一个目的。

研发框架

咱们的研发框架主要分为三个部分：第一部分，框架运行时：它提供了整个 APP 级别的就是应用级别的生命周期，包括

运行时的 API
可选的状态管理
路由方案

第二部分，工程构建能力

开箱即用的配置：咱们提供了一个开箱即用的工程配置，也就是说能够经过简单的开关配置就能够达到你想要的能力，后面会详细描述。
一码多端：经过咱们的工程构建能够一次编写，而后产出多端的代码，你能够直接把多端的代码部署到各个容器上面，而后直接跑就 ok 了。

第三部分，也是比较重要的一部分，就是咱们的高度插件化的能力。

扩展工程能力：可能社区里面见的比较多，咱们能够经过好比说相似 webpack-chain 的方式去修改 Webpack 配置，而后一层一层的叠加，用插件的方式作叠加，咱们工程拿到最终的一个 Webpack 的 Config，最后拿回去打包。
扩展运行时能力：跟社区方案有所不一样的扩展运行时能力。可能跟社区里面的 Next 的方案比较接近。固然 Next 的方案可能它没有对外暴露这个能力，也就是说能够经过咱们的插件，即 Rax APP 的插件，去给 Rax App 的核心包直接去添加一些 API。

这样的一种扩展运行时能力带来的一种收益是什么？假如说你的业务须要一个跨端的能力，那么你能够选择 Rax APP 研发框架。当你的业务到了一个深水区，好比说是互动领域，你有本身的一些垂直的 API 须要去注入或者是有本身的品牌，你能够基于咱们的 Rax APP，再去作一个更上层的框架，而后在上层框架里面去注入。以互动领域为例，能够注入互动的一些运行时的 API ，例如：import xxx from 框架名，同时你还享有 Rax APP 提供的一些基础的运行时API。

下面给你们来介绍一下咱们框架运行时，在此以前咱们先看一下整个研发框架的概览。咱们的整个设计思路：

首先是下面的基础能力：

经过提供可扩展的 CLI 能力。
无关 DSL 的应用级 API：第二个是无关 DSL 的应用级 API 。无关 DSL 即不管你是用的 React 仍是 Rax 仍是 Vue 等等，只要你暴露出来了一些跟渲染相关的 API，好比说 createElement 这些能力，咱们就能够帮你去包装一层一个应用级的 API 。举个例子，好比说 history，好比说一些生命周期，包括 PageShow 这个事件。
Web 运行时容器：第三个是 Web 运行时的容器，你们若是开发太小程序能够比较清楚，小程序实际上是一个完整的APP 的概念。那么如何将小程序完美的降级到咱们的一个 Web 应用，由于咱们有一些多渠道投放的场景，咱们提供了一套方案，可让你把小程序的业务逻辑彻底去降级到 Web 应用。
通用的路由能力

再往上层是咱们的框架核心：也就一个是工程构建中台，我大概讲一下里面包含了各类好比说 CLI 注册一些参数，你能够经过 --https 去开启 https 的一些调试能力，好比说是状态管理这些能力都是经过构建中台去包装的。

再往上层是渲染器：其中包括小程序的渲染器，例如更新小程序的视图。第二个是 Rax 应用的渲染器。第三个是 React应用的渲染器。能够在底层经过 Rax 或者是 React 的 setState 操做来更新视图。

更上层的是容器：咱们支持 Web、小程序、Weex 、Kraken ，其中 Kraken 是 Flutter 的方案。

再往上层是核心框架：咱们这套整个下层的体系支持了 icejs（中后台），还有一个是 Rax APP 无线跨端。

更往上层的业务框架：已经有不少团队开始基于咱们的框架去作他们本身的研发框架。好比说阿里云团队，政务钉钉或者是阿里体育团队。

继续讲咱们的框架运行时。

我会从后面几个比较小的点来着手分析，经过框架运行时的一些能力，咱们解决了怎样的问题。

首先第一部分是生命周期。若是你们接触 React 多的话，可能对 componentWillMount、componentDidMount 这些组件的实例的生命周期比较熟悉。完整的生命周期，更多的指的是什么？更多指的是一个应用的生命周期。若是你们开发太小程序可能比较清楚，就是小程序的一些生命周期。

完整的生命周期能够作哪些事情？

埋点：好比说在页面切换过来的时候，我须要上报一个曝光埋点。
监控：好比说一些页面报错怎么收集，假设咱们有本身的监控系统，怎么去看咱们线上业务存在哪些问题。
响应式的交互：好比从 a 页面切到 b 页面，假如 b 页面去作了相似登录的操做，再返回到 a 页面的时候，咱们须要有个 a 页面的生命周期来实现例如权限的一些视图变化，或是状态的切换等等。咱们团队如今是提供了一套面向多终端框架的解决方案，但愿可让用户在开发中后台、PC、无线等多端应用时的开发体验是一致的，这样能够减小开发团队成员的上手成本。
清理定时器：避免一些内存泄漏或者不必的事件回调。
获取启动参数：好比说在小程序里面，须要在应用启动阶段，如 onLaunch 阶段去获取一些启动参数等等。

因此基于上面这些需求，以及一些业务上的真实痛点，咱们作了一个多端体验一致的生命周期，主要分为两部分：

APP 的生命周期：包括应用的启动 onLaunch 事件，应用的报错 onError 事件，应用的 onShow 事件，应用的 onHide 事件。将来咱们可能会加入针对 TabBar 点击的事件，如在点击 TabBar 时，须要作一些曝光埋点的能力，会针对 TabBar 的操做暴露出相关的生命周期。
页面的生命周期：usePageShow 的 Hooks，usePageHide 的 Hooks，onShow，onHide 等事件。

这里同窗会问说为何 usePageShow 、usePageHide 这里称为 Hooks，而 onShow，onHide 称为事件。这是由于在社区里面咱们看到的常见的 useXXX，其实就是 API 的调用，并非真正的 Hooks，也就是说这种 API 的调用方式跟 Hooks 自己并无关系。咱们这里的 usePageShow 实际上是真正的 Hooks，它跟 onShow 不一样之处在于，ousePageShow 的触发时机是在组件渲染完成以后，而 onShow 是在组件示例初始化的时候，也就是页面刚进来的时候，就会触发这个 onShow 事件。

咱们还提供了基于小程序的若干小程序独有的声明周期。若是有接触太小程序的同窗应该知道，诸如页面触底的一些事件。不管是在 Weex，仍是在 Kraken ，仍是在小程序，或是在 Web 等等业务形态上，咱们的方案表现都是彻底一致的，包括触发时机和触发顺序，这样可以让你的业务逻辑在开发时保持彻底一致。usePageShow 是在组件渲染完成以后，onShow 是在组件实例化的时候，也就是页面刚进入时。

接着我想介绍的这个是咱们的生命周期的一个演示代码。左边是应用入口的演示，在应用入口中注册本身的生命周期，而后右边是页面的演示 usePageShow 和 usePageHide，你能够尝试这样去作。你们能够简单看一下。

接下来主要是给你们介绍的是咱们的状态管理，其实飞冰这个产品也是属于咱们团队的，咱们核心能力也是基于飞冰 ICE Store 提供的状态管理的能力。咱们但愿可以把状态管理这件事情作得更加简单，更加符合业务使用的直觉，而不须要本身去包裹 Provider 或者是去理解更多的概念，你只须要用一些最基础的能力就能够完成状态管理。

首先是建立 store，你能够在 src 里面新建一个 store.ts 的文件，你能够去建立 state 、 reducers 、effects。分别对应 redux 里面的一些概念，即 state、 reducers 、还有会产生反作用的一些方法。在页面里面能够去消费这些全局的状态，能够直接去 import store 就是 APP 的 store ，从根路由引入。

而后经过 useModel 的方法拿到 state 的状态，经过 APP 上的 dispatchers 去触发一些视图上的更新，就能够很轻松的作到状态管理的 0 成本上手。只须要简单的看一下示例代码，就能够彻底涵盖到无线端场景的大部分状态管理的诉求。固然因为咱们提供了内置的状态管理的能力，包括一些注入的方法。这样可能致使咱们的包体积变大，但咱们但愿在无线端给到你们的方案是足够轻量的，因此在一些无线端比较简单的页面中，可能业务没有必要去用到状态管理，也不建议你们在无线端去大量的使用状态管理。

由于无线端咱们尽量的把事情作简单，作的更轻量，因此咱们提供了一种方式，就是在咱们的配置文件里面，就是 build.json 里手动关闭状态管理。能够用很简单的一个开关，设置 store 为 false ，就能够关掉状态管理。根据咱们关闭 store 先后的打包文件的体积对比，在打开 gzip 压缩的以后，关掉状态管理，咱们的代码体积能够缩小大概 20KB ，在一个无线端场景 20KB 其实能够算是优化中的一个比较重要的指标。

关于路由方案，咱们采用的是标准协议约定式路由，在 app.json 里面配置路由。以 home 页面为例，设置 path 、source（页面来源），同时给 home 页面配置一个 title，能够用这种方式建立页面。

还能够对 tabBar 进行配置，利用刚才提到的协议配置，能够很容易的在应用中配置 tabBar，因为咱们有一套相对完美的降级到 Web 应用的方案，因此这个 tabBar 的配置能力不只仅做用于小程序，也能够在 Web 应用中实现对应的 tabBar 功能。

路由操做及数据获取，经过 Rax App 中引入 history 、getSearchParams 就能够去很轻松的拿到咱们须要的当前页面的history 相关数据。在 react-router 中，也提供了相似的 useHistory，useLocation 这样的API，其底层是利用了 React 的 useContext 的能力，使用了像 hooks 相似的命名，但其实它们与命名并无直接关系，因此在 Rax App 中咱们把它设计成为直接能够获取，并进行操做。相似的 getSearchParams 也是替换了原来的 hooks 写法。

从架构设计的角度来讲，history 的设计思路是什么呢？因为咱们要适配多端，因此咱们须要支持 Web、Weex 以及 Kraken。咱们使用的是社区中的一个 history 包提供的能力。可是因为小程序自己没有 history 的概念，因此咱们模拟了 mini-app 本身去封装实现了一套 history 的 API 暴露给用户使用。这样能够帮助用户向用其余端同样在小程序中调用诸如 history.push、history.replace 等等方法。对开发者而言，只须要理解一个 history 概念就好。

工程构建

在实际开发过程当中，经常遇到如下的问题：

在为本地 https 调试困扰？
如何一键开启依赖分析？
怎么快速添加 babel 插件？

这些问题在 Rax App 中都变得很容易。好比经过 npm start -- --https 就能够开启本地的 https 调试，经过 npm start -- --analyzer 就能够一键开启依赖分析，并不须要额外的引入社区的插件。添加 babel 插件，只须要在配置中添加 babelPlugins 对应的插件便可，再也不须要去社区里找一堆须要引入的插件。

其余的一些配置，好比能够经过简单的配置 minify 关闭压缩，这在开发环境中经常用到。经过配置 proxy 便可将 API 请求代理到本地，以此来解决跨域问题。一样的环境变量也能够再也不依赖 process.env 这种方式，只须要在 define 中配置对应的变量便可注入业务中须要的环境变量。

一码多端能力，经过以下图所示在配置文件中写入对应的 targets 端，就能够一次命令同时开启多个端的业务构建，如 Web、Weex、Kraken、小程序等等。同时也支持 Web 中的 SSR，MPA 的特殊需求。

针对小程序，也有小程序独有的配置，包括针对微信小程序或者阿里小程序的比较独特的一些配置。同时后面还会跟你们说到一个小程序的特有 runtimeDependencies 的配置项。

代码体积，在一码多端的场景下，代码体积的大小是一个很重要的性能指标。Rax App 中是经过特定的 Babel 插件 rax-platform-loader 来判断不一样的端场景，并只保留对应的端场景下的代码，从而控制代码体积。

如今咱们介绍刚才卖的关子——小程序的实现部分。咱们小程序方案主要是基于双引擎来驱动的一个完整的小程序开发体系。以此来知足开发者既要高性能，同时也要代码的灵活度的需求。

编译时引擎，好比像 Taro (应该是 Taro 1.x、Taro 2.x 的版本）更多的是基于编译时的引擎，将 AST 语法树在编译打包时就进行解析，以保证可以 1:1 的尽量还原到小程序的 DSL ，并能正常运行。

运行时引擎，实现起来并不复杂，本质上就是将 VDOM 树经过小程序的操做 setData ，而后去遍历递归，最终渲染到模板上。固然这其中涉及到不少渲染时的优化，好比如何避免频繁的渲染操做，如何可以支持不一样的小程序，由于不一样平台的小程序底层实现的方式也是有所差别的，所以优化方式也会有所区别。

如图中所示，Rax App 实际上是同时支持了编译时引擎和运行时引擎两种模式。

小程序编译时的引擎，是经过对 AST 树的解析，解析用户的一些条件的代码如 map 的 list 循环，在编译时会把它和小程序作吻合解析，识别出 map 循环，并将它转化成小程序的 wx-for 等语法。整个编译时的引擎，主要是一个洋葱式的模型。若是了解过 koa 框架，应该比较容易理解洋葱式的模型是什么概念。每个文件进来以后，它会被解析成 AST 树，再出去的时候，咱们会作一些 AST 的修改，再转成代码文件，最后产出小程序的代码。

运行时垫片，完整的模拟了 React / Rax 的核心 API。即在编译时里提到的 useEffect 其实和 React / Rax 的 useEffect 彻底不一样，是另外一套实现。从下图中能够看出，运行时垫片实际上是将小程序实例与 Rax 组件实例进行了相互绑定的操做。即当 Rax 组件实例更新，会反馈到小程序实例进行改变；而小程序实例的建立、销毁、更新都会通知到 Rax 组件实例。

在此之上，还实现了 Rax 的一些核心 API，如 Hooks、Component、Event、Lifecycle 等等。

运行时方案的背景，弥补编译时方案不足

不存在语法限制
运行真正的 Rax，可以快速支持新特性
基于标准的 Webpack 工程，具备完整的工程插件配置能力

运行时方案的特色，用性能换取完整语法支持的诉求

部分小程序能够接受部分运行时方案性能体验
部分小程序 UI 较为简单，运行时方案性能与原生差距不大

基于 Rax 体系，如何实现小程序运行时这套方案？

实现小程序运行时的这套方案，须要了解以前提到的 dirver 的概念，在 Web 和 Weex 的应用端会模拟操做 DOM 的 API。在小程序端，实际上是经过 worker 线程调用并计算须要渲染的 DOM ，传递给 render 线程，而后经过小程序的 setData （微信小程序）/ $spliceData （阿里小程序）进行视图渲染。

在开发中，每每咱们有各类各样的要求：好比开发者但愿可以拥有运行时的能力，同时又想拥有使用小程序原生组件的能力；想使用小程序编译时的组件，想节省渲染时的节点数，又想在 worker 和 render 之间传递更大的 JSON 数据；想提升渲染效率，又想让工程师可以使用咱们已有的方案体系，组件体系等等。

针对上述的这些要求，在社区里，比较而言，Rax App 实际上是更符合这类需求的综合类的解决方案。

下图示例中，向你们说明了如何作到小程序的双引擎混用。其中左边为双引擎混用的工程目录示例，右边为使用方法示例。

高度插件化

插件化包括：运行时插件和工程插件。工程插件是基于 build scripts 实现。框架运行时插件能够经过本身开发一个插件，而后在 runtime.tsx 的文件，利用框架暴露的一些 API 在业务项目中使用的 Rax App 核心包注入运行时的能力。当开发者使用时，能够直接从 Rax App 中导出已经注入的运行时能力。

下图示例了如何开发和使用插件的示例。

Rax 的框架架构图，主要包括 2 个部分，框架中台和框架品牌。例如 rax-app 和 ice.js 其实都是基于框架中台实现了，这也意味着开发者能够根据本身的需求去自定义的封装出适用于自身业务的框架，甚至也能够将本身定制化开发的框架开源，回馈社区。

多端组件与 API

简单列举了框架提供的常见的一些 API ，详细的能够去官方文档中进行查阅。

下图示例了框架为用户封装的业务组件和基础组件的示例，详细的能够去官方文档中进行查阅。

总结

Rax 是什么

Rax 的使命，是让多端开发简单而美好。 Rax 的愿景，基于前端生态打通多端体系。

咱们但愿可以融合丰富的前端生态，包括 npm 以及前端其余很美好的东西，咱们但愿可以把他们引入到多端体系中。而不但愿用户因为今天有了 Flutter，须要去学习 Dart，有了另一个框架，就须要学习另一门语言，或者是另一个生态体系。

咱们就但愿前端可以用本身的生态体系来作各个平台的渲染。关于渲染这件事情，咱们但愿可以让它变得更简单，入门更加容易。

为何选择 Rax App

为何选择 Rax APP？ Rax主要是有6个点：

面向的多终端应用开发
丰富的框架运行时 API
开箱即用的工程配置
最佳实践合集
高度扩展性
通过充分的业务验证

高度可扩展性，即用户能够无限的扩展本身的需求。

通过充分的业务验证，是由于咱们有一个可靠的团队去维护它，保证它的稳定性。你们若是用过飞冰应该知道，飞冰已经运行维护好几年了，一样的 Rax 也是运行维护好几年了。同时阿里巴巴集团内也有大量的业务去验证这套技术方案。

关于团队技术选型方面的建议

团队作技术选型，能够分为 6 个部分：

开发体验
代码可维护性
智能化辅助工具
多场景支撑
代码可拓展性
可用生态

代码可维护性，一个更小的团队，好比说 3~~5 我的 5~~10 我的的团队，要去开发一个业务代码，可维护性的迫切程度是至关高的。Rax App 提供了跟 icejs 同样的一个 ESLint 标准，或者说是一个基于 iceworks 的代码健康检查插件，包括智能化辅助工具，可让你很好的去管理你的项目，可以让你的项目的代码健壮度更高，可以有更大更高的稳定性。

多场景的支撑，在业务的场景不少的状况下，在作技术选型的时候，不能只考虑当下，须要考虑将来 1 年或者是 3~5 年以后你所选择的框架如何适应业务，而不是成为一个历史包袱。咱们但愿在业务中作技术选型的时候，不管是选择了 Rax 仍是飞冰这样的技术方案，都可以对你的多业务场景提供可持续的维护性，编写高质量的代码。

业务可扩展性，当你今天在完成一个 A 需求时，可以为明天的 B 需求作好铺垫，提早作好对应的考虑。

可用生态，Rax 选择 React 做为标准的缘由，以及为何是一个 React 的渐进式框架？是由于 React 生态是足够的丰富的。咱们但愿可以有更多的生态能够直接在 Rax 中使用。

推荐与团队介绍

团队介绍

向你们展现一下咱们今年双 11 的合照。这个就是咱们的团队，看上去仍是比较大的。

最后的就是招人环节了，咱们主要负责渲染这一部分，咱们团队还有作 Node 架构相关的工做，因此咱们要 C++ 开发、客户端开发、前端开发、也要服务端开发。其实不管你的技术栈是什么都无所谓，咱们更关心的是你的学习能力，对业务的深度理解，以及对当下技术架构设计的想法。

如下是咱们团队的官网、专栏、开源仓库及我我的的信息，欢迎你们与咱们交流，或者也能够直接联系我。

不管是技术交流也好，或是对咱们团队感兴趣也好，均可以经过邮件（fushen.jzw@alibaba-inc.com）或是微信(加 codingdreamer 推名片)的方式联系我。

别忘了第二十八届|前端 WebGL 专场，2021 年要不要押宝 WebGL 弯道超车，6-26 全天直播，9 位讲师(阿里云/蚂蚁/美团/小米等)，点我上车👉 (报名地址)：

全部往期都有全程录播，能够购买年票一次性解锁所有

👉更多活动

点赞，评论，求 Mark。