自 Taro 2.0 起，我们将会启动对整个 Taro 系统架构的革新，这次革新我们将其称之为 Taro Next。Taro Next 革新完成之后，Taro 本身的拓展性、稳定性、可维护性都会大幅提高，相应地，使用 Taro 的开发者也会获得更好的开发体验，降低更多开发成本和学习成本。
我们目前已经完成了编译系统和小程序端的重构，通过 npm i -g @tarojs/cli@next 安装 Taro CLI 预览（alpha）版之后，使用 taro init 创建新项目即可体验 Taro Next 的新特性：
同时支持 React/Vue/Nerv 三种框架
-----------------------------------------------------------------------------------------------------------------
在旧版本的 Taro，我们以微信小程序的开发规范为基准，使用 React/JSX 的方式来进行开发。而在 Taro Next，我们把这一思路量化为一个编程模型：
设微信小程序生命周期为一个 interface，不同的框架实例的生命周期虽然不尽相同，但我们可以根据框架生命周期分别新建一个 class 去 implements 小程序生命周期的 interface。相应地，小程序的组件/API/路由规范可以使用同样的思路和模型让不同框架的代码，运行在不同的端上：
不限制语言、语法
-----------------------------------------------------------------------------------------------------------------
由于 Taro Next 的架构出现了变化，表面上来看 Taro 从一个编译型框架变成了一个运行时框架。但究其内核是整体的设计思路出现了变化：从前是「模拟（mock）」，现在是「实现（implements）」。在 Taro Next 我们实现了 React 在小程序中的完整支持，因此这类曾经的 Taro 无法运行的代码在 Taro Next 中完全没有压力：
import { View } from '@tarojs/components'
function Page (props) {
const view = React.createElement(View, null, props.text)
return [view, React.Children.only(this.prosps.children)]
}
在旧版本的 Taro 中我们对 JavaScript 和 TypeScript 进行了 First Class 的支持，Taro Next 我们更进一步，原理上最终可以编译到 JavaScript 的语言都可以用来构建 Taro 项目，以下是一个在 Vue 中使用 CoffeeScript 的例子：
// config.js
{
webpackChain (chain) {
chain.merge({
module: {
rule: {
test: /\.coffee$/,
use: [ 'coffee-loader' ]
}
}
})
}
}
<template>
<view>{{ title }}</view>
<view>{{ text }}</view>
<input v-model='text' />
</template>
<script lang="coffee">
export default
props:
title:
type: String
required: true
data: ->
text: 'text'
</script>
更快的运行速度
-----------------------------------------------------------------------------------------------------------------
运行时性能主要分为两个部分，一是更新性能，二是初始化性能。
对于更新性能而言，旧版本的 Taro 会把开发者 setState 的数据进行一次全量的 diff，最终返回给小程序是按路径更新的 data。而在 Taro Next 中 diff 的工作交给了开发者使用的框架（React/Nerv/Vue），而框架 diff 之后的数据也会通过 Taro 按路径去最小化更新。因此开发者可以根据使用框架的特性进行更多更细微的性能优化。
初始化性能则是 Taro Next 的痛点。原生小程序或编译型框架的初始数据可以直接用于渲染，但 Taro Next 在初始化时会把框架的渲染数据转化为小程序的渲染数据，多了一次 setData 开销。
为了解决这个问题，Taro 从服务端渲染受到启发，在 Taro CLI 将页面初始化的状态直接渲染为无状态的 wxml，在框架和业务逻辑运行之前执行渲染流程。我们将这一技术称之为预渲染（Prerender），经过 Prerender 的页面初始渲染速度通常会和原生小程序一致甚至更快。
更快的构建速度和 source-map 支持
-----------------------------------------------------------------------------------------------------------------
作为一个编译型框架，旧版本的 Taro 会进行大量的 AST 操作，这类操作显著地拖慢了 Taro CLI 的编译速度。而在 Taro Next 中不会操作任何开发者代码的 AST，因此编译速度得到了大幅的提高。
正因为 AST 操作的取消，Taro Next 也轻松地实现了 source-map 的支持。这对于开发体验是一个巨大的提升：
不忘初心
-----------------------------------------------------------------------------------------------------------------
在做到以上各项特性的同时，我们也没有丢掉原来就已经支持的特性：
- 支持微信小程序、百度智能小程序、支付宝小程序、QQ 小程序、字节跳动小程序
- 使用原生小程序第三方组件/插件
- 多端条件编译
- 跨端 API 和样式处理
这些特性基本涉及到了小程序开发的方方面面，虽然是预览版，但 Taro Next 已经具备了开发生产级小程序的准备，在 Taro 团队内部和兄弟团队也有多款小程序正在使用 Taro Next 进行开发。而在 Taro Next 的 H5 端和移动端，我们还在进行紧张的开发。当 Taro Next 测试（beta）版发布时，使用 Taro Next 构建的一套代码，就可以同时运行在各种小程序、快应用、H5 和移动端当中。在未来，我们还会把 Taro Next 的能力开放出去，让开发者只要写少量的接入代码，就可以使用自己喜欢的任意框架（Angular, Flutter, svelte...）开发小程序或多端应用。
牢记使命
-----------------------------------------------------------------------------------------------------------------
正如我们在 Taro 2.0 发布时所言：
节物风光不相待，桑田碧海须臾改。
20 年代呼啸而来，下一个 10 年，很多框架都会死去，很多技术也会焕然而生，没有什么是不变的，唯一不变的只有变化，我们能做的也只能是拥抱变化。
前端技术一直在高速发展，流行的技术和框架每年都各不相同。但我们始终没有忘记开发 Taro 的初心和使命：降低开发成本，提高开发体验和开发效率。
「不忘初心，牢记使命。」
这就是 Taro 团队拥抱变化的方式。
参考资料
-----------------------------------------------------------------------------------------------------------------
提供