目前正在开发接手小程序的开发工作。第一件事情就是选择框架，在原生小程序和小程序框架之间还是选择了使用框架，一来可以支持一套代码多端，二来组件化和底层兼容方面可以做的更好。
如何选择框架呢？
先从主观上来看：
| 框架 | 文档 | 大小(压缩后) | 代码的干净程序 | 文件格式 | 调用原生组件 | 原生组件可调 |
|---|---|---|---|---|---|---|
| Taro@1.2.12 | 齐全 | 60KB | 整洁（React风格） | tsx,jsx | 可 | 可 |
| WePY@1.7.0 | 齐全 | 100KB | 整洁（Vue风格） | wpy | 可 | 否 |
组件化上的差异：
同样的使用组件，但是编译出来的结果是不一样的。
taro是将组件编译成了小程序原生的组件，在使用的地方也是使用原生的写法。而wepy则不然，wepy将组件的wxml拷贝到了引用的位置，js继承到了引用的js文件中，这就是原生小程序不能使用wepy的组件的原因，同样编译后的wxml文件wepy会比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<any, any> {
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的位置插入<slot></slot>组件，这个也是原生小程序支持的。如果要使用多插槽，则需要使用属性传递，taro会生成多个<slot></slot>组件，除了children之外的属性需要用render开头，比如renderOther，则会生成<slot name="other"></slot>的插槽组件。
这里wepy的做法还会带来一个问题，就是如果组件是不显示的，组件的生命周期也会执行，这样就带来了流程上的问题。
总结
个人觉得taro更加适合当前的项目，taro编译后的代码更加遵循原生小程序的风格，也可以和原生小程序互相调用，这个是很重要的。
