为什么有了Taro，我们还在做Alita？？真正的React？？

自从Alita发布以来，由于Alita和Taro一样都是React语法在小程序上的处理， 所以一直有很多人问我“已经有Taro了，为什么又造轮子呢？？”，今天用这篇文章统一回答一下。

首先我们看下Taro，他是一套遵循 React 语法规范的 多端开发 解决方案。他遵循 React 语法规范，采用与 React 一致的组件化思想，组件生命周期与 React 保持一致，同时支持使用 JSX 语法，让代码具有更丰富的表现力，使用 Taro 进行开发可以获得和 React 一致的开发体验。

截止本文开始的时候，Taro在github上已经获得了2W多star，实际上线的业务也是非常多的，另外Taro已经形成了自己的开发者社区，其周边的工具非常的丰富，可以说是非常成熟，非常成功的开源项目了。

回到故事的开始：怎么样把React程序（主要是JSX）运行在小程序呢？
Taro采用的是编译时方案，通过对代码静态的分析，把JSX修改为等效wxml。

这种方式的局限在于JSX是动态的，编译时是没有办法完全表达JSX的。React“编程”式的构建UI，更多的是把JSX当成一个普通的数据类型来看待，一个JSX片段，可以用来初始化变量，可以作为函数参数，可以作为函数返回值等等

var a = <View><Text>Hi</Text></View>

function f(b) {
    const r =  [
        b,
        <Text>Hello</Text>
    ]
    r.push(a)
}
var x = f(<Text></Text>)

...

编译时方案尝试在编译期推理运行期的信息，这会有很大的局限性。

而类比React Native的渲染思路，有没有一种方案上层还是React环境，然后底层渲染通过小程序的方式。

Alita正是基于这种设计思路的尝试。Alita希望提供一种真正意义上的React与小程序的结合。

不过上面的方式貌似对React语法是完全的支持，但是实际使用过Alita的人，也知道Alita对语法还是有一些限制。这主要是因为出于潜在的性能因素的考虑， Alita采用了 微信小程序自定义组件映射React组件的方式，他们之间有很大不同，比如微信小程序自定义组件引用的组件必须预先在json文件定义其路径。

import {Hello, NiHao} from 'hello'

class A extends Component {
    render(){
        return <View>
            <Hello/>
            <NiHao/>
        </View>
    }
}

以上的NiHao组件，要获取其组件路径，其实还挺困难的，所以Alita会对组件文件有些限制来方便的获取其路径。 诸如此类。

总结

以上就是我们做Alita的一点思考，也算是对最开始的问题做个回答，另外基于相似的原理，我们还尝试过把Flutter底层渲染机制换成小程序:flutter_mp https://github.com/areslabs/flutter_mp。