小程序框架选型：Taro和WePY

目前正在开发接手小程序的开发工作。第一件事情就是选择框架，在原生小程序和小程序框架之间还是选择了使用框架，一来可以支持一套代码多端，二来组件化和底层兼容方面可以做的更好。

如何选择框架呢？

先从主观上来看：

框架	文档	大小(压缩后)	代码的干净程序	文件格式	调用原生组件	原生组件可调
[email protected]	齐全	60KB	整洁（React风格）	tsx,jsx	可	可
[email protected]	齐全	100KB	整洁（Vue风格）	wpy	可	否

组件化上的差异：

同样的使用组件，但是编译出来的结果是不一样的。
taro是将组件编译成了小程序原生的组件，在使用的地方也是使用原生的写法。而wepy则不然，wepy将组件的wxml拷贝到了引用的位置，js继承到了引用的js文件中，这就是原生小程序不能使用wepy的组件的原因，同样编译后的wxml文件wepy会比taro来的大。

wepy 缺少wxml文件，所以原生小程序不能使用

Taro，编译成了原生小程序的格式

在来看看生命周期：

wepy则是使用了原生的声明周期，包括onRoute，onLoad，onUnload，onShow，onHide，onReady，app则多了onLauch，onError，onPageNotFound，组件有onLoad，onUnload，文档上没有明确的写明。
taro则使用了类似react的生命周期函数名。这个对于熟悉React的同学来说，真的是很轻松。

在来看看监听方面：

export default class Index extends wepy.component {
   props = {
      title: {
        type: String
      }
    }
    watch = {
      title(oldVal,newVal){
        console.log(newVal, oldVal);
      }
    }
}

wepy实现了自己的watcher方式，暂且不知道性能和原生的比较如何，但是源码量是增加了好多。

export default class Index extends Component {
    static properties = {
        title: {
            type: String,
            value: "标题",
            observer(newVal, oldVal, changedPath) {
                console.log(newVal, oldVal, changedPath);
            }
        }
    };
}

taro则是使用了小程序原生的方式来解决prop和state的监听，所以在state和props中不能同时存在同名的属性。

再来看看插槽（slot）的设计：

wepy可以支持多插槽，也是像前面说到的，编译的时候已经将wxml的内容填充到了相应的地方，这里不会使用小程序原生的插槽特性，而是直接在组件里面生成对应的wxml代码。

taro遵循了react的规范，可以使用children。编译后的代码中，会在对应的组件中children的位置插入组件，这个也是原生小程序支持的。如果要使用多插槽，则需要使用属性传递，taro会生成多个组件，除了children之外的属性需要用render开头，比如renderOther，则会生成的插槽组件。

这里wepy的做法还会带来一个问题，就是如果组件是不显示的，组件的生命周期也会执行，这样就带来了流程上的问题。

总结

个人觉得taro更加适合当前的项目，taro编译后的代码更加遵循原生小程序的风格，也可以和原生小程序互相调用，这个是很重要的。