承载 Web 的主战场转移
2017 年 1 月 9 日凌晨，微信正式推出小程序，为挪动端家族减少了新的业务状态和玩法，当大家还在探讨这一新兴平台能做什么的时候，京东率先上线了「京东购物」小程序，随后，更多的电商行业执牛耳者纷纷入驻小程序，从此，承载电商的主战场逐步从须要自建流量的挪动端 APP 向小程序歪斜。
小程序的呈现，为电商行业的研发带来了微小的挑战。继微信之后越来越多的头部流量互联网公司纷纷盯上小程序这一蛋糕，相继推出了各自的小程序平台，比方京东、阿里、百度、字节跳动、360等等，为了让咱们的电商业务能疾速移植到这些小程序平台，帮忙咱们的业务疾速拓展渠道，咱们开始了新的尝试。
咱们开始尝试应用技术的伎俩，摸索一种可能对立所有平台的新技术。
乘风破浪——初代架构诞生
用 React 写小程序？
后面有提到，为了解决各大小程序平台带来的多端开发的痛点问题，社区先涌现出了 WePy 和 mpvue，那咱们为什么不间接采纳，而要抉择“造轮子”呢？
在过后的前端界言及前端框架，必离不开仍然放弃着统治位置的 React 与 Vue，这两个都是十分优良的前端 UI 框架，而且在网上也常常能看到两个框架的粉丝之间激情交换，碰撞出一些思维火花，让社区异样沉闷。
而咱们团队也在 2017 年怯懦地摈弃了历史包袱，十分荣幸的引入了 React 技术栈。这让咱们团队丢掉了煤油灯，开始通上了电，远离了刀耕火种的前端开发形式。为了解决过后业务环境对极致性能以及低版本 IE 浏览器兼容性的要求，咱们还研发出了一款优良的类 React 框架 Nerv ，并因而对 React 开发思维以及技术栈了解更加粗浅。
遗憾的是，过后社区并没有一款应用 React 开发小程序的框架。
与小程序的开发方式相比，React 显著显得更加现代化、规范化，而且 React 天生组件化更适宜咱们的业务开发，JSX 也比字符串模板有更强的表现力。那时候咱们开始思考，咱们能不能用 React 来写小程序？
感性地摸索
通过比照体验 小程序和 React ，咱们还是能发现两者之间类似的中央，比方生命周期、数据更新形式以及事件绑定，都具备十分多类似的中央，这为咱们应用 React 来小程序提供了十分良好的根底。
然而，咱们也应该看到小程序和 React 之间的微小的差别，那就是模板。在 React 中，是应用 JSX 来作为组件的模板的，而小程序则与 Vue 一样，是应用字符串模板的。这是两种齐全不一样的货色，也是咱们计划摸索上的微小阻碍。所以，为了实现应用 React 来写小程序这一指标，咱们必须解决两者之间微小差别的问题。
解决差别
既然微信不反对 JSX，那咱们只须要将 JSX 编译成小程序模板不久能够在微信上运行了吗，这一步能够通过 Babel 来实现。
Babel 作为一个 代码编译器 ，可能将 ES6/7/8 的代码编译成 ES5 的代码，其的编译过程次要蕴含三个阶段：
- 解析过程，在这个过程中进行词法、语法分析，以及语义剖析，生成合乎 ESTree 规范 虚构语法树(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，其中不乏多端案例。
截止 2021年 1 月 11 日，Taro 已领有 27914 Star ，位列小程序开发框架前列。
Taro 团队一直跟进社区里提出的问题和反馈，始终放弃着高速迭代，并围绕 多端适配、开发体验以及社区共建 三个方面继续优化 Taro 框架。
为了不便开发者疾速开发我的项目，咱们基于 Taro 推出了业内首款小程序多端组件库 Taro UI，
在多端适配方面，咱们始终继续跟进，成为社区适配端最多的小程序开发框架。
为了更好的开发体验，咱们反对了 React Hooks、CSS Modules、Mobx 等。
在社区共建方面，咱们推出了 Taro 论坛、Taro 物料市场等平台，前面公布了 社区共建打算。
在跟进业务的同时，咱们还须要一直跟进社区里提出的问题和反馈，因此就要一直加班加点地去实现，尽管有时会感觉很累，然而技术上的成就感以及能帮忙到更多开发者时的满足感还是一直地激励着咱们后退，让 Taro 我的项目越来越好。
筚路蓝缕——一段苦楚摸索的降级之旅
Taro 在 GitHub 上开源之后尽管播种了十分多的赞美，短短的工夫内就冲破了 10000 Stars，但因为 Taro 初期的自定义组件架构设计得非常复杂，导致应用组件开发的时候总会引起十分多的问题，始终为许多用户诟病。
在 Taro 设计的初期，因为微信小程序刚推出的自定义组件性能并不欠缺，实现不了传入自定义函数等问题，无奈满足组件化灵便应用的需要，所以 Taro 的组件化架构是采纳 template 标签来实现的。
应用 template 计划来实现的组件化架构在通常状况下运行良好，但面对简单循环嵌套输入组件的时候则问题频出，次要起因是：
- JS 逻辑与模板隔离，须要别离解决，导致组件传参十分麻烦，难以对齐
- template 实现的自定义组件无奈嵌套子组件
所以，在 Taro 最后的时光，自定义组件的问题始终是咱们抹不去的痛，作为官网团队，在苦楚考虑解决方案的同时，还要面对社区一直的问题反馈和质疑，让咱们总感觉前途一片灰暗。
但前人的教训通知咱们，不能就此放弃，鲁迅学生已经说过「尔后如竟没有炬火，我便是惟一的光」。咱们在 template 计划挣扎好久之后，终于还是将眼光投向了小程序自带的自定义组件身上。
正所谓山穷水复疑无路，柳暗花明又一村，小程序的自定义组件恰好有了一波更新，通过数个日夜加班摸索之后，之前困扰咱们的问题都失去了一一解决，完满实现了新的自定义组件架构，带来了更加稳固的版本。
在新的架构中，咱们会把 Taro 的组件间接编译成小程序的原生组件的 Component 办法调用，再通过运行时的适配，来对组件参数、生命周期适配、以及事件传入等进行解决，借助小程序的组件化能力来实现 Taro 的组件解决。
通过这一版计划重构之后，Taro 的稳定性与可靠性失去了质的飞跃，社区的好评声一直，而 Taro 的关注数也失去平缓的增长。这一版架构计划也成了 Taro 持续时间最久的计划，为 Taro 日后成为「一款值得信赖」的多端计划打下了松软的根底。
这是一段筚路蓝缕的艰苦创业之旅，对于 Taro 团队来说也是一段十分贵重的教训。没有始终一帆风顺的旅途，唯有不轻言放弃和勇于开拓能力云开见日，让咱们走的更远。
高歌猛进——一直地冲破自我
在实现了自定义组件架构的革新之后，Taro 开始了全速倒退之路。
在 2018 年 11 月份，Taro 推出了 1.1 版本，实现了百度、支付宝小程序的适配反对，成为业界首个同时适配多个小程序平台的多端开发框架，并且在适配期间，Taro 团队和百度、支付宝小程序官网团队建设了分割，为对方小程序的倒退提出了十分多的建设性意见。与此同时，Taro 成为百度小程序官网举荐应用框架之一。
而短短一个月之后，2018 年 12 月份，Taro 火速推出了 1.2 版本，这是一个十分具备翻新意义的版本，在这个版本中，Taro 独创了小程序原生代码反向转换技术，可能将小程序原生代码反向转换成 Taro 代码。原有的微信小程序通过 Taro 转换，就能疾速移植到其余平台，这为业务的疾速扩张提供了微小的设想空间，为业务的高效交付提供了极大的助力。
而「京东快递」业务正是反向转换个性胜利利用的一个榜样案例。最后「京东快递」只有微信小程序平台，通过 Taro 的反向转换个性，以极低的老本疾速移植到百度、头条小程序平台，并且能够只保护一份代码，同时保护 3 端利用，极大地升高了保护老本。
在 Taro 1.2 公布之后，Taro 在业界播种了微小的赞美和关注：GitHub 上 Stars 数量超过 19000 粒，NPM 下载量也稳居同类开发框架之首，同时 Taro 团队也和腾讯、百度、华为等数十家业界巨头的研发团队开展了深刻和无效的单干。
工夫匆匆而逝，来到了 2019 年 6 月，时隔半年，咱们终于公布了 Taro 1.3，这是咱们酝酿最久的版本：经验了横跨 6 个月的开发工夫，近 2000 次的代码提交，同时有近百位开发者的独特参加。在 Taro 1.3 中，咱们不仅仅带来了对 QQ 小程序的反对，同时还反对了快利用，成为业界反对平台最多的多端开发框架，而更重要的是，在这个版本中咱们胜利将业界炽热的 React Hooks 搬到了 Taro 中，反对让用户应用 React Hooks 的形式来开发小程序，成为业界独创。
从 Taro 正式版公布，到 Taro 1.3，能够看出 Taro 始终一直应用翻新的理念打磨自我，以翻新为使命，为业界带来体验优异的多端开发解决方案。
拥抱变动——为将来思考
只管 Taro 始终放弃超高的迭代速度，但自从自定义组件架构革新之后，Taro 的整体架构设计没有产生太大变动，这让 Taro 在这个时刻在变动的时代稍显佛系，且对于一个时刻想要冲破本人的技术团队来说，惯例性质的保护工作，显然无奈安抚咱们躁动的心，毕竟人的幻想，是永远不会进行的，所以咱们决定启动一系列的颠覆式重构设计。
咱们首先从 CLI 开始动手进行革新，家喻户晓，原来 Taro CLI 的编译构建零碎是自研的，整个构建零碎逻辑简单，要思考的边际条件泛滥，这就导致了以下问题：
- 保护艰难，每次须要新增一个性能，例如反对解析 Markdown 文件，就须要间接改变 CLI，不够灵便
- 难以共建，CLI 的代码非常复杂，而且逻辑分支泛滥，让很多想要一起共建的人难以动手
- 可扩展性偏低，自研的构建零碎，设计之初没有思考到后续的扩展性，导致开发者想要增加自定义的性能无从下手
基于以上问题，咱们决定应用 Webpack 来实现编译构建，于是诞生了 2.0。
Taro 2.0 的 CLI 将会变得十分轻量，只会做辨别编译平台、解决不同平台编译入参等操作，随后再调用对应平台的 runner 编译器 做代码编译操作，而原来大量的 AST 语法操作将会革新成 Webpack Plugin 以及 Loader，交给 Webpack 来解决。
相较于旧的构建零碎，新的小程序编译带来了以下劣势：
- 利于保护，大量的逻辑交由 Webpack 来解决，咱们只须要保护一些插件
- 更加稳固，相较于自研的构建零碎，新的构建会更加稳固，升高一些奇怪谬误的呈现概率
- 可扩展性强，能够通过自行退出 Webpack Loader 与 Plugin 的形式做本人想要的扩大
- 各端编译对立，接入 Webpack 后，Taro 各端的编译配置能够实现十分大程度的对立
能够看到新的构建零碎会有很大的提高。同时，更重要的是，基于 Webpack，咱们能够在小程序中尝试更多的个性与技术，例如通过 tree shaking 来优化代码包大小等等，让小程序开发更加与业界倒退同步，让 Taro 更加拥抱社区。
Taro 2.0 只是一个开始。
在 10 年代最初一场 GMTC 寰球大前端技术大会上，Taro 团队向大家展现了 小程序跨框架开发的摸索与实际 的艰苦旅程，同时也提前曝光了正在严密开发中的 Taro Next。
那是一个齐全区别于以往的版本，一条与当初 Taro 截然不同的路线，预示着 Taro 正在革本人的命。
节物景色不相待，桑田碧海顷刻改。
20 年代吼叫而来，下一个 10 年，很多框架都会死去，很多技术也会焕然而生，没有什么是不变的，惟一不变的只有变动，咱们能做的也只能是拥抱变动，为将来思考。
乘风破浪——新架构起航
正如前文所提到的，Taro 迎来了全新的架构。
不同于 Taro 1、2 时代的架构，新的架构次要基于运行时，咱们都晓得应用 React 开发 web，渲染页面次要依附的是 react-dom 去操作 DOM 树，而 React Native 依附的是 Yoga 布局引擎，然而咱们却能通过 React 将他们分割在一起，这次要是通过形象的 Virtual DOM 技术来实现的，通过 Virtual DOM 达到跨平台对立的目标。而小程序中尽管没有间接裸露 DOM 和 BOM API，然而咱们却能够类比 React 和 React Native 的思维，在小程序中模仿实现 DOM 以及 BOM 的 API，从而实现间接将 React 运行到小程序环境中的目标，这就是 Taro 新架构的由来。
在新架构加持下，Taro 不再仅局限于 React 营垒，能够不再限度应用的框架语法，而 Taro 官网内置了 React、Nerv、Vue2、Vue3 四种框架的反对。
Taro2 到 Taro3，是一次技术的跃迁，也是一次翻新的胜利，更是 Taro 团队一直摸索，永不止步精力的体现。Taro 这艘大船又从新杨帆起航，带着初心再次登程。
乘风破浪破浪会有时，直挂云帆济桑田。
众擎易举——开放式架构
自 2020 年 7 月初 Taro 正式公布了 Taro 3，至 12 月半年工夫未然略去。期间咱们一直地修复着问题，同时也在构想着下一个 minor 版本。
面对小程序平台越来越多的大环境，Taro 是抉择偏安一隅，只反对局部的支流小程序，还是成为所有小程序平台开发、多端转换的基础设施，Taro 在 v3.1 给出了答案：开放式架构。
基于 Taro 3 的架构，对于繁多平台的兼容性代码散布于 Taro 外围库的各个角落，波及编译时与运行时等局部。反对一个新的平台须要改变所有的这些中央，开发复杂度高，同时社区也难以参加奉献。
因而咱们萌发了打造一个开放式框架的想法。指标是能够通过插件的模式扩大 Taro 的端平台反对能力：
- 插件开发者无需批改 Taro 外围库代码，即可编写出一个端平台插件。
- 插件使用者只需装置、配置端平台插件，即可把代码编译到指定平台。
- 开发者能够继承现有的端平台插件，而后对平台的适配逻辑进行自定义。
咱们把内置反对的 6 个平台封装成了插件，CLI 默认会全副加载这些插件。封装的过程中，咱们检索了各小程序最新的组件、API，并全数进行更新与反对，对齐各小程序最新的能力。而借助开放式架构，咱们编写了若干端平台插件，开发者装置后即可应用。
结语
开源不易，贵在保持。Taro 一路走来，有泛滥开发者相伴，进入过 中国活跃度 Top 5 的开源我的项目，像河水一直奔涌向前的 Taro 既争先也争滔滔不绝。 Taro 团队衷心感谢各位参加过本我的项目开源建设的敌人，无论是为 Taro 提交过代码、建设周边生态，还是反馈过问题，甚至只是茶余饭后探讨、吐槽 Taro 的各位。
凹凸揭秘系列文章地址
1.《凹凸实验室的过来与将来》
2.《凹凸技术揭秘·羚珑智能设计平台·逐梦设计数智化》
3.《凹凸技术揭秘 · Deco 智能代码 · 开启产研效率反动》
4.《凹凸技术揭秘·羚珑页面可视化·成长变质之路》
5.《凹凸技术揭秘 · 夸克设计资产 · 打造全矩阵优质物料》
6.《凹凸技术揭秘 · Tide 研发平台 · 布局研发新基建》
7.《凹凸技术揭秘 · Taro · 从跨端到开放式跨端跨框架》
8.《凹凸技术揭秘 · 根底服务体系 · 构筑服务端技术中枢》
欢送关注凹凸实验室博客：aotu.io
或者关注凹凸实验室公众号（AOTULabs），不定时推送文章。