承载 Web 的主战场转移—
2017 年 1 月 9 日凌晨，微信正式推出小程序，为挪动端家族减少了新的业务状态和玩法，当大家还在探讨这一新兴平台能做什么的时候，京东率先上线了「京东购物」小程序，随后，更多的电商行业执牛耳者纷纷入驻小程序，从此，承载电商的主战场逐步从须要自建流量的挪动端 APP 向小程序歪斜。
小程序的呈现，为电商行业的研发带来了微小的挑战。继微信之后越来越多的头部流量互联网公司纷纷盯上小程序这一蛋糕，相继推出了各自的小程序平台，比方京东、阿里、百度、字节跳动、360 等等，为了让咱们的电商业务能疾速移植到这些小程序平台，帮忙咱们的业务疾速拓展渠道，咱们开始了新的尝试。
咱们开始尝试应用技术的伎俩，摸索一种可能对立所有平台的新技术。
乘风破浪——初代架构诞生—
用 React 写小程序？
后面有提到，为了解决各大小程序平台带来的多端开发的痛点问题，社区先涌现出了 WePy[1] 和 mpvue[2]，那咱们为什么不间接采纳，而要抉择“造轮子”呢？
在过后的前端界言及前端框架，必离不开仍然放弃着统治位置的 React[3] 与 Vue[4]，这两个都是十分优良的前端 UI 框架，而且在网上也常常能看到两个框架的粉丝之间激情交换，碰撞出一些思维火花，让社区异样沉闷。
而咱们团队也在 2017 年怯懦地摈弃了历史包袱，十分荣幸的引入了 React 技术栈。这让咱们团队丢掉了煤油灯，开始通上了电，远离了刀耕火种的前端开发形式。为了解决过后业务环境对极致性能以及低版本 IE 浏览器兼容性的要求，咱们还研发出了一款优良的类 React 框架 Nerv[5]，并因而对 React 开发思维以及技术栈了解更加粗浅。
遗憾的是，过后社区并没有一款应用 React 开发小程序的框架。
与小程序的开发方式相比，React 显著显得更加现代化、规范化，而且 React 天生组件化更适宜咱们的业务开发，JSX 也比字符串模板有更强的表现力。那时候咱们开始思考，咱们能不能用 React 来写小程序？[6]
感性地摸索
通过比照体验 小程序和 React，咱们还是能发现两者之间类似的中央，比方生命周期、数据更新形式以及事件绑定，都具备十分多类似的中央，这为咱们应用 React 来小程序提供了十分良好的根底。
然而，咱们也应该看到小程序和 React 之间的微小的差别，那就是模板。在 React 中，是应用 JSX 来作为组件的模板的，而小程序则与 Vue 一样，是应用字符串模板的。这是两种齐全不一样的货色，也是咱们计划摸索上的微小阻碍。所以，为了实现应用 React 来写小程序这一指标，咱们必须解决两者之间微小差别的问题。
解决差别
既然微信不反对 JSX，那咱们只须要将 JSX 编译成小程序模板不久能够在微信上运行了吗，这一步能够通过 Babel[7] 来实现。
Babel 作为一个 代码编译器，可能将 ES6/7/8 的代码编译成 ES5 的代码，其的编译过程次要蕴含三个阶段：
解析过程，在这个过程中进行词法、语法分析，以及语义剖析，生成合乎 ESTree 规范 [8] 虚构语法树 (AST)
转换过程，针对 AST 做出已定义好的操作，babel 的配置文件 .babelrc 中定义的 preset、plugin 就是在这一步中执行并扭转 AST 的
生成过程，将前一步转换好的 AST 生成指标代码的字符串
再次回到咱们的需要，将 JSX 编译成小程序模板，十分侥幸的是 babel 的外围编译器 babylon 是反对对 JSX 语法的解析的，咱们能够间接利用它来帮咱们结构 AST，而咱们须要专一的远程桌面外围就是如何对 AST 进行转换操作，得出咱们须要的新 AST，再将新 AST 进行递归遍历，生成小程序的模板。
以上仅仅是咱们转换规则的冰山一角，JSX 的写法极其灵便多变，咱们只能通过穷举的形式，将罕用的、React 官网举荐的写法作为转换规则加以反对。
初代架构诞生
通过咱们一次次的摸索，咱们曾经能够将类 React 代码转成能够在小程序环境运行的代码了。然而咱们冲动之余，冷静下来持续思考，咱们还能不能干点别的有意思的事件呢。
咱们发现，在平时的工作中，咱们业务通常有一些“多端”的需要。就是同一个业务或页面，须要同时适配 小程序、H5、甚至 React Native。这个时候，你就会发现，差不多的界面和逻辑，你可能须要反复写上好几轮。
因而，咱们心愿心愿在解决应用 React 开发微信小程序的同时，还能同时是适配到 H5 端、挪动端、以及各平台的小程序。Write once, run anywhere，置信是所有工程师的幻想。
然而认真思考咱们又会发现，仅仅将代码依照对应语法规定转换过来后，还远远不够，因为不同端会有本人的原生组件，端能力 API 等等，代码间接转换过来后，并不能间接执行，还须要运行时的适配。因而，咱们依照微信小程序的组件库与 API 的规范，在其余端（H5、RN）别离实现了组件库和 API 库。
Taro 从立项之初到架构稳固差不多用了三个月左右的工夫，从最后的强烈探讨计划，各种思维的碰撞，到计划逐步成型，进入炽热的开发迭代，再到当初的多个平台小程序端、H5 端和 RN 端的顺利反对，Taro 的将来已来。
初露锋芒——GitHub 开源—
2018 年 6 月 7 日，多端对立开发框架 – Taro 正式开源。
作为首个反对以 React 语法写微信小程序并适配到多端的开发框架，Taro 一举成名。开源不到两个月，在 GitHub 上有 6600 多个 Star，间断数周霸榜 Github Trending；同时曾经解决近 300 个 Issue，还有 100 多个在期待反馈与优化；在公司内、外被动反馈的应用 Taro 的我的项目已有十多个。
截至 2019 年 12 月 18 日，Taro 已领有 22254 Stars 和 250 名 Contributors，社区被动提交的开发案例 150+：taro-user-cases[9]，其中不乏多端案例。