Taro: 对于 taro、nerv 的看法

Created on 25 Jul 2019 · 10Comments · Source: NervJS/taro

对于 nerv 的看法

为什么我们还需要一个-React-like-框架这篇文章中（最后更新于 2017年10月5日）讲了为什么不采用 react 的三个原因：

IE 8 兼容性
react 体积问题
性能问题

然后和社区 preact（体积小）、inferno（性能好）比较，决定自研 react-like 框架 nerv，其中讲了 nerv 的优点：

无缝对接 React 和其繁荣的生态。Nerv 的 API 和 React 完全一致，不需要一个类似于 nerv-compat 的东西来保证兼容性，只要在 webpack 稍微设置一下就能替换老项目的 React 依赖
超高的性能
超小的体积
良好的浏览器兼容性

react 从 2017年9月7日发布 v16.0.0-rc.2 以来（2019年7月24日），已经更新到 v16.9.0-alpha.0，其中不但增加了一系列的 API，底层也进行了重构。nerv 其实已经无法兑现 无缝对接 React 生态 的口号，我们也没有一个统一的文档查看 nerv 和 react 的差异，据目前粗略的黑盒踩坑过程中，发现了一些：

不支持 Fragment
不支持 Lazy、Suspense
不支持社区常用的包：react-router@5、react-loadable
接入 UI 组件库 ant-design 异常（试了下 Form 组件）

在使用 react 社区的包过程中，按目前状况来看，很可能时不时会踩到坑，而且这里面的问题使用者很难去自行处理，它既要求使用者非常熟悉 react 的底层，还要非常熟悉 nerv 的底层，并且熟知 react 和 nerv 之间的差异。

随着 react 不断发展，担心的是这种差异只会越来越大，直到失控。

nerv 中剩余三个优点：

超高的性能：脱离场景、需求来说性能其实意义性并不大，react 本身性能也完全经得起考验，并提供了优化的手段。如果说 react 业务遇到了性能瓶颈，切换成 nerv 后解决了性能问题，这才有实际的意义。另外兼容 IE8，大部分项目稍微上点规模，在 IE8 上跑起来都不可能具有良好的性能体验
超小的体积：react+react-dom gzip 后体积也控制在 35kb 以内（https://reactjs.org/blog/2017/09/26/react-v16.0.html#reduced-file-size），相对于 nerv 8kb 来说也完全能够被绝大多数项目接受，合理使用缓存，离线能力，以及拆包等手段，这点体积是完全可以忽略的。即便没有这些优化手段，对于大部分项目来说，这点体积增量也是可以忽略的，且不说 polyfill、未打包优化前的 moment、lodash 等，都轻易超过了这个体积
良好的浏览器兼容性：IE8 的兼容性在和京东对位的淘宝、天猫早几年就不再支持。我们项目也面向政府、学校项目（上百个），原先也是要求兼容 IE8，但从数据分析，并没有想象中所谓的IE8浏览器占有率如何（不到 1%），拿数据说话，并努力去推动公司去IE8兼容性，是更有意义也更节约公司成本的行为。而且 react 生态中很多流行包都不支持 IE8，nerv 谈何无缝对接 react 生态。

同样的事情也发生在 anu 上（anu 还对 nerv 性能和兼容性持怀疑态度：没有case证明其兼容IE8，性能指标也很可疑），不可否认做这样的一系列工具可以提升、积累技术水平，也确实体现了框架开发者高超的能力，也契合于两年前的一些情况：react 版权问题、当时IE8 浏览器占有率情况。时至今日，这两个都不再是问题。

从上面来看，我对 nerv 的未来是持悲观态度的，目前来看它没有跟随 react 的发展，无法无缝对接 react 生态，在 IE8 兼容性要求下，这点更不可能实现，它们是矛盾的，nerv 的应用场景也会越走越窄。

对于 taro 的看法

关注到 nerv 其实是源自希望通过 react 来编写多端代码，通过 taro 了解到 nerv，但发现其 DSL 是 nerv，而非 react。

taro 是面向多端开发的，但这里的多端是不包括 IE8 的，所以我对 taro 选型 nerv 而不是 react 持有疑惑性。兼容性上选型说不通，体积、性能上面也提到过，它还没有关键到影响选型的情况。

react 本身作为 DSL，在受制于小程序的情况下，有限制性使用（作为 react 功能子集）可能是一条更合适的路子，阿里的实验性项目 remax 正在进行这样的实验。

直接使用 react 在社区中显然比 nerv 更有吸引力，对于 taro 来说，也可以更专注于如何进行对应多端转换和编译工作，避免一直在实现兼容 react 及其生态上的过多投入。

而对于 taro-ui，一款基于 Taro 框架开发的多端 UI 组件库。既然是 UI 组件库，那么它的结果产物就应该仅仅是组件库。构建得到的组件库，例如小程序组件能够单独在小程序上使用，H5 组件库能够独立在H5的项目中使用，而不需要耦合脚手架相关的内容，那太重了。

因此 UI 组件库应该是独立的，它将会有更广大的市场。

对于开发者来说，可以直接使用构建工具，这是 taro 的核心。

在此核心上，提供的多端脚手架，可以开发多端业务项目。其中，如果 rn 现在不具备生产能力，可以不用提供这部分的能力，等后续这个能力完善了再对外。

而 UI 组件库可以单独使用对于开发者来说也是一个巨大的吸引力，学习成本更低，适用面更广，而且广得多。

我对 taro、taro-ui、nerv 的使用仅停留在粗浅的层面，上述是我的一些思考，可能存在一些偏差。taro 在 react 开发多端小程序项目上走的靠前，但成熟度相对于 uni-app 来说还略显逊色。希望 taro 能够在技术高度上看的更远，格局胸怀上做的更大，未来的路也走的更远，并越走越好

Source

caolvchong

👍15 🎉5 👀2 🚀1 👎1

Most helpful comment

关于 Nerv

时至今日，即便作为 Nerv 的开发者，我也不得不说所有 React-like 框架已经死了。React Core Team 推陈出新的速度极快，社区跟进的速度也极快，一旦有一个新的 API 第三方库/组件用上新特性，React-like 框架没跟上就会发生不兼容的情况；还有许多第三方库/组件甚至会直接访问组件/vdom 的内部数据结构，如果 React-like 框架内部实现的数据结构和 React 不一致也会出现不兼容的情况。也就是说，需要真的兼容完全 React 需要满足两个条件：

框架本身投入巨大的精力投入开发，接入 React 新 API；
社区使用足够广泛，踩遍各种第三方库/组件的内部实现细节；

显然，没有一个 React-like 框架能满足以上两个需求，即便要满足一个也是奢望。但在我看来，不仅仅是所有 React-like 框架死了，所有 React/Vue/Angular 之外的 JavaScript-Based Web 前端框架都死了，前端框架的故事已经基本结束了。以后基本不会有一个不走三大框架的 DSL 的前端框架能成为开发者的新欢。

从这个角度来说，Nerv 比起其它一起和旧时代陪葬的前端框架们来说，还没有死透。不管是对于 Taro 社区来说，还是我们内部业务来说，Nerv 可以快速响应社区或者业务的需求，及时地做出适应 Taro 或业务的改变。——能做到这两点，它就就再活一阵子。

至于某前辈的质疑，性能方面 Nerv 仓库本身也有 benchmark，另外你还可以可以看第三方评测的 js-framework-benchmark(github, blog)。兼容性方面你只要看京东 PC 首页就行了：如果真的不兼容 IE8，产品测试运营采销不得拿刀砍死我们？

说到这里我不得不谈一个题外话，拥有自己独立思考的能力是软件开发工程师的基本素质。即便不谈技术之外的倾向，一个开源软件的好坏是有着清晰的指标可以衡量的：代码的质量；实际的表现；软件工程管理；Issue/PR 和社区管理等等因素。只要你稍微花点时间用点心就能判别好坏。

Taro

关于 Taro 的架构设计问题，我在讨论一下 Taro 的架构，小程序端和 nerv 为什么不用同一套 core? 已经回答过了，就不再赘述。

你对 Taro UI 的想法很好，但维护一套组件库所需的人力比想象得还要大得多。良好设计和功能齐全的组件库对于框架的发展固然十分重要，但比这更重要的是：我们能不能让社区发展更多的组件库？能不能复用已有的、久经考验的组件库？我觉得回答这两个问题才是 Taro 未来的目标。

yuche on 30 Jul 2019

👍12 ❤1

All 10 comments

欢迎提交 Issue~

如果你提交的是 bug 报告，请务必遵循 Issue 模板的规范，尽量用简洁的语言描述你的问题，最好能提供一个稳定简单的复现。🙏🙏🙏

如果你的信息提供过于模糊或不足，或者已经其他 issue 已经存在相关内容，你的 issue 有可能会被关闭。

Good luck and happy coding~

taro-bot[bot] on 25 Jul 2019

@luckyadam @yuche 讨论下？

caolvchong on 30 Jul 2019

关于 Nerv

框架本身投入巨大的精力投入开发，接入 React 新 API；
社区使用足够广泛，踩遍各种第三方库/组件的内部实现细节；

Taro

关于 Taro 的架构设计问题，我在讨论一下 Taro 的架构，小程序端和 nerv 为什么不用同一套 core? 已经回答过了，就不再赘述。

yuche on 30 Jul 2019

👍12 ❤1

是的，我写这篇 issue 的原因是希望看到 taro 团队的声音和想法，很高兴能够进行沟通。

react-like 濒死，我觉得算是我们讨论的一个共识。

至于性能问题，我无意于去挑起争端，taro 在文档、社区活跃度、周边工具开发上做的确实领先。我表达的主要意思是，这个性能问题不应该成为选型的根本性考虑因素，毕竟 react 本身不存在性能问题。而且业务导致的性能问题也有很多解决方案进行处理。

关于 IE8，我也不是质疑 nerv 的兼容性。在兼容 IE8 的事情上，我深有体会。我做过 react 全家桶兼容 IE8 的脚手架（react 0.14.9 + 一系列受限版本的周边），持续做了有近2年的时间。2年中，我通过业务数据进行分析，得出以下的结论：

现有业务项目 IE8 占比非常低（自身业务小于 1%）
对公司而言，投入的成本高、收益小，性价比低
交互差、性能差、可用性差（IE8 下很多交互需要降级处理）
限制技术选型、架构（react 、webpack 等技术栈新版本能力、稳定性），脱离社区
不利于面向发展、未来

提出 IE8 的事情，我是希望能够有人站出来，去分析公司的数据，来判断是否继续进行 IE8 的兼容。而如果数据上支持不需要兼容 IE8（< 5%），应该在公司中提出议题，进行判断、决策，是否继续进行支撑。

去 IE8 不仅仅是开发者个人的行为，数据上支持的话，是一件和公司共赢的事情，可以为公司剩下很多不必要的兼容性开发支出，是一件更全局的事情。

社区中的生态不支持 IE8，对 IE8 投入是一件高开销的事情，而不是一个 nerv 就能做到的，包括了脚手架、UI 库、社区包等等

官方

微软官方在 2016年1月12日宣布对 IE8 停止支持服务（超过3年）

主流站点

教育类产品（相关业务）：网易云课堂、中国大学MOOC（慕课）、学堂在线、新浪公开课、网易公开课等等

C端产品：知乎、天猫、淘宝、bilibili、今日头条等等

主流技术框架

React 2016年4月7日开始不支持IE8（3年余）

Vue 从一开始（2015年12月31日）就不支持IE8（3年半）

Angular 2014年03月07日开始不支持IE8（5年）

jQuery 连以兼容性为亮点的 jQuery 也从 2016年7月9日开始不支持 IE8（3年）

对于不支持 IE8，可以进行友好的提示，让用户进行升级浏览器。

而对于我们公司，很多业务面向学校、政府的项目，针对部分特殊用户，进行有针对性的售前服务（例如升级浏览器）才是更好更贴心的服务。并根据数据埋点，阶段性进行总结反馈，更主动服务于用户。

京东的场景、数据需要你们去判断、推动，我觉得比一个开发埋头于去做 IE8 的兼容是更有意义的事情。去 IE8 事情不容易，我个人从发起、收集数据、汇报、多次往返后，并联合了部分高P、高管，历经4个月时间终于在公司层面做出了去 IE8 的决策。这是一件于开发、于公司，都是很有意义、很有价值的事情。

对于 taro UI，我的团队也维护了公司的 UI 组件库，当然很多受益于社区。我也深知开发、维护一套 UI 组件库的工作量、难度。而在开源上，难度更大。

如果希望社区贡献，我认为让 taro-ui 可以让 UI 库在小程序、H5 端独立运行，是一件非常重要紧急的事情。这样可以吸引众多的 H5 开发者加入，而目前被 taro、taro-ui 吸引的基本是由于小程序。

移动端的 UI 组件库在社区中目前来看并没有一个遥遥领先的组件库，无论是 antd-mobile、有赞、还是其他，成熟度、投入度上都没有。这我觉得是一个机会，如果一个公司愿意投入，最终的收益或许是巨大的，好比于 pc web 端的 ant design，做成了一个标杆类的产品，也吸引了许多开发者进行开发。

最后，UI 组件库是一个可以决定技术选型的重要一环，而脚手架不会，其他辅助工具也不会。应该有不少项目因为 ant design 选择了 react，而不仅仅因为 react 选择了 ant design。如果 taro-ui 能够实现独立的 UI 组件库，必将吸引更多的人，也会让 taro 本身更具吸引力和长期发展的生命力。

希望看到 taro 的改变、进化。 @yuche

caolvchong on 31 Jul 2019

👍7 👀1 👎1

个人理解与看法，理解错了请指出。

Remax 通过在各端实现接管的 VDOM ，让各端小程序的 JS Runtime 跑一个完整的 React.js 的想法确实很好，但是他们也对自己这种实现方式的性能表现保持怀疑，暂时观望一下等待有新的结论。

Taro WePY MpVue 等，他们都是以 React/Vue 的语法作为一套统一的模版语法，让编译器转译成各端的模版语言，API 尽可能保持一致性但仍然对特定 API 采用放任策略，让开发者自行适配。

Chameleon 等，模版语法层依然是转译成各端模版语言，无法免除的模版差异依然由开发者管理，但在 API 层更激进，尽可能的将各端 API 抽象成统一的，符合 Chameleon 框架规范的 API，端差异由框架解决，开发者只需要了解 Chameleon API 而不需要了解各端 API，避免开发者直接调用端自身 API，并且鼓励开发者将各端有差异的 API 抽象成统一的接口（Interface）。