前言
最近我们公司有一个项目需要同时开发微信小程序和H5两个平台的AI机器人。我进行了一些技术调研，并最终选择了使用Taro框架进行开发。
Taro是一个跨平台的前端开发框架，它的设计思路是一次编写，多端运行。这意味着我们只需要编写一套代码，就可以将应用程序在多个平台上运行，包括微信小程序和H5等。这种设计思路使得我们能够更加高效地开发和维护项目，因为我们不需要为每个平台编写和维护独立的代码。
对我来说，这是第一次接触Taro，但是我发现相比于之前的微信小程序开发方式，Taro提供了更多便利。它的设计思路和跨平台能力使得我们能够更加高效地开发和维护项目。而且，Taro作为一个活跃的开源项目，还有一个庞大的社区支持和持续的更新和改进，这为我们在开发过程中提供了更多的资源和支持。我期待在使用Taro的过程中能够进一步探索它的功能和优势，并将其应用到我们的项目中。
一.Taro 的诞生
Taro['tɑ:roʊ]，泰罗·奥特曼，宇宙警备队总教官，实力最强的奥特曼。
从2017年微信小程序的诞生，到逐渐火热，但微信小程序让人又爱又恨。一方面在小程序中，一个页面 page 可能拥有 page.js、page.wxss、page.wxml 、page.json 四个文件，切来切去会显得尤其麻烦，影响开发效率。并且在小程序中到处可见规范不统一的情况。官方的文档中既有驼峰命名又有短横线命名。另一方面只能使用微信开发工具来进行开发， 不能使用 npm 管理依赖、不能使用 Sass 等 CSS 预处理器、不完整的 ES Next 语法支持、手动的文件处理，像图片压缩、代码压缩等等的一些文件操作，必须手工来处理，显得有些繁琐。给人们开发微信小程序阻碍。
恰巧，在2018年京东某个部门的业务中，有小程序、H5 以及 APP，得同时维护三套代码，因此萌生一个想法能不能就用一套代码去实现各个端。而且当时正好在做类 React 的框架，整个部门的技术选型就转向了 React 的阵营。后来，就思考怎么写一套代码编译到各个端，于是就有了 Taro。
二.taro 的设计思路
想要一份代码通吃n端，无非2种思路：
- 直接从
1端向n - 1端转换 - 加一层抽象，从这层抽象转换到
n端 在 taro 的设计中，采用了第二种思路，即加一层抽象来实现代码通用性和跨平台的能力。
第一种思路硬转起来比较困难，主要有一下的问题：
- 平台差异性：不同平台之间存在差异性，包括组件系统、API 支持、布局方式等方面。如果直接从一个端转换到其他端，需要处理各种平台之间的差异，这样会增加开发者的工作量和复杂性。
- 扩展性和灵活性：直接转换的方式可能难以适应未来新增的平台或技术。如果每个端都直接依赖于原始端的代码，那么在新增端或技术时，需要对原有代码进行修改和适配。而通过引入抽象层，可以更容易地扩展到新的平台，并且可以根据不同平台的特点进行灵活调整和定制。
- 维护成本：直接转换的方式可能导致代码冗余和维护成本的增加。如果每个端都有自己的代码，那么当需要进行功能更新或修复 bug 时，需要在每个端进行独立的修改和测试。而通过引入抽象层，可以将共享的逻辑抽离出来，减少了代码重复和维护工作，提高了开发效率和代码的可维护性。
Taro 的设计思路是在 React 的基础上引入了一层抽象，即 Taro 的自定义组件。开发者使用 Taro 提供的组件来构建应用界面，这些组件封装了底层不同端的差异，并提供了统一的 API 和生命周期，使得开发者能够在不同端之间共享和复用大部分代码逻辑。
举个例子来说，假设我们要开发一个展示商品列表的应用，包括在微信小程序、H5 和 React Native 上运行。在传统的开发方式下，我们需要编写针对每个平台的不同代码，分别使用小程序的组件、HTML/CSS 和 React Native 的组件来实现相同的功能。这样会导致代码冗余、维护困难，并且需要花费更多的时间和精力。
而在使用 Taro 开发时，我们可以使用 Taro 提供的自定义组件，例如 <TaroList> 来构建商品列表界面。这个自定义组件会根据当前运行的平台，自动选择使用对应平台的原生组件或框架组件进行渲染。开发者只需要编写一次逻辑，就可以在不同平台上实现相同的展示效果，极大地提高了开发效率。
通过加入一层抽象，Taro 实现了代码的通用性，使得开发者可以更加高效地开发多端应用。同时，Taro 还提供了一系列的工具和插件，帮助开发者处理跨平台兼容性问题、性能优化和调试等方面的挑战，进一步简化了多端开发的复杂性。
三.Taro的发展历程
2018.6.7 Taro 开源
支持 H5、微信小程序
2018.9.16 Taro 1.0
- 支持React Native
2018.11.06 Taro 1.1
支持百度智能小程序 和 支付宝小程序
2018.12.18 Taro 1.2
- 微信小程序转多端应用
- 支持字节跳动（头条）小程序
- CSS Modules 支持
- 状态管理工具MobX 支持
2019.6.13 Taro 1.3
- 支持快应用和 QQ 小程序的开发
- 全面支持 JSX 语法和 HOOKS
- 全新生命周期和 Context API
- 大幅提高 H5 性能和可用性决战性能之巅 - Taro H5 转换与优化升级
- 支持开发小程序插件
- 支持「小程序·云开发」
2020.1.8 Taro 2.0
- Taro CLI 的编译构建系统从自研到使用 Webpack 来实现编译构建
基于 Webpack，我们可以在小程序中尝试更多的特性与技术，例如通过 tree shaking 来优化代码包大小等等，让小程序开发更加与业界发展同步，让 Taro 更加拥抱社区
2020.7.1 Taro 3.0
- Taro 3 中我们内置了 React、Nerv、Vue 2、Vue 3 四种框架的支持，开发者可以通过
taro init命令创建对应的模板，并编写与框架本身生命周期、调用方法合乎一致的代码（idiomatic code），在语法上也没有任何的限制 - H5 端基础组件现在全部使用 Web Components 构建，路由系统也完全与前端框架解耦，因此在 H5 端 Taro 也实现了跨框架。不管开发者使用的是 React、Vue 还是 Nerv，都可以同时运行在各种小程序和 H5 上
- 开放式插件系统
- 开源治理与项目治理
- 微信小程序转 React/Vue，现在这个功能也完全兼容 Taro Next 的新架构
- CSS-In-JS
- 虚拟列表
- 预渲染
- 更快的构建速度和 source-map 支持
2021.3.10 Taro 3.1
- 开放式架构
通过引入插件的方式借入其他平台。通过端平台插件能支持任意小程序平台
- 新增小程序性能优化组件 CustomWrapper
- 原生小程序渐进式混合使用 Taro 开发
- 拥抱 React 17、TypeScript 4
2021.4.8 Taro 3.2
- 更快编译速度
source-map支持React Native- 多 React Native 版本支持
- 更丰富 API 与组件(视频、音频、多媒体相关，还有扫码，VirtualList)
- API 与组件按需引入
- 与 React Native 应用融合
- 不跨端使用
2021.8.13 Taro 3.3
- 支持使用 H5 标签
- 支持使用框架的 DevTools
2022.1.20 Taro 3.4
- 支持使用 Preact
- 更好地支持 Vue 3.2
- H5优化，多路由配置、路由动画、dynamic-import-node
- 新增 defineAppConfig 与 definePageConfig 编译宏
2022.7.26 Taro 3.5
- 编译提速，使用Webpack5 构建了新的编译系统
- RN优化
- 支持使用pnpm
- 适配 React 18
- H5 支持服务端渲染
- H5 支持多页应用模式
- 补全对小程序生命周期方法的支持
2023.2.1 Taro 3.6
- 支持路由库
- 支持网络请求库
- 支持鸿蒙端平台插件
- 跨框架组件库
- 研发生态
