前言

微信小程序原生开发主要有三大元素：框架、组件、API，而小程序开发框架，其主要功能就是将以该框架支持的语法编写的代码编译转换为小程序原生框架所能支持的。

本人曾在生产项目中使用过小程序原生框架开发，后见WePY发展不错，确认可投入生产使用，便在项目设计改版之际，改用WePY编写代码，同时使用代码分包，至于mpvue，只是初步了解，暂未实际使用。以下简单对两个框架做一些对比，以期对选用哪个框架开发小程序有更多的认识与考量。

WePY

• 一个类Vue开发风格的小程序框架

• 特性：

  • 类Vue开发风格
  • 支持组件化开发
  • 支持NPM
  • 支持Promise, 主动选择是否开启
  • 支持ES2015
  • 编译器：支持less/sass/TypeScript等开发
  • 小程序性能优化
  • 框架大小：24.3k+8.9k
  • wepy-redux数据管理
• 构建与编译工具：wepy-cli，编译配置：wepy.config.js
• 项目目录结构：

├── dist                   小程序运行代码目录（该目录由WePY的build指令自动编译生成，请不要直接修改该目录下的文件）
├── node_modules           
├── src                    代码编写的目录（该目录为使用WePY后的开发目录）
|   ├── components         WePY组件目录（组件不属于完整页面，仅供完整页面或其他组件引用）
|   |   ├── com_a.wpy      可复用的WePY组件a
|   |   └── com_b.wpy      可复用的WePY组件b
|   ├── pages              WePY页面目录（属于完整页面）
|   |   ├── index.wpy      index页面（经build后，会在dist目录下的pages目录生成index.js、index.json、index.wxml和index.wxss文件）
|   |   └── other.wpy      other页面（经build后，会在dist目录下的pages目录生成other.js、other.json、other.wxml和other.wxss文件）
|   └── app.wpy            小程序配置项（全局数据、样式、声明钩子等；经build后，会在dist目录下生成app.js、app.json和app.wxss文件）
└── package.json           项目的package配置
└── wepy.config.json       项目的编译配置
└── project.config.json    小程序开发工具的配置

WePY原理示意图

请查看其使用手册

![WePY文件编译示意图]()
WePY文件编译示意图

![WePY组件实现示意图]()
WePY组件实现示意图

WePY大概做了这些工作：

• 编译代码为原生框架支持的形式

  • .wpy单文件开发简化文件目录
  • 优化数据绑定语法与性能
  • 优化事件绑定语法与传参
  • 优化代码复用，组件化代替原生的模板
  • 支持less/sass/typescript等，优化开发体验
• 将大部分API promise化
• 支持npm外部依赖，ESLink代码规范等

小结

因此，使用WePY开发小程序，除遵循WePY的语法外，

• 仍可保留原生的开发方式，比如按原生自定义组件的方式开发，WePY会将 .js/.json/.wxml原封不动复制到输出目录下，将.less编译为同名的.wxss
• 对于继承自wepy.app/wepy.page/wepy.component的以.wpy为文件后缀名的，则数据赋值需按照WePY的方式，必要时使用$apply, $nextTick, 而不是用setData, 至于事件绑定语法、API调用，可根据喜好与需求，保留原生语法 or 使用WePY优化语法

一点经验

• WePY的文档更新会有一定的延迟。

  • 比如1.7.0正式添加$nextTick支持前，是在1.6.1-alphax版本中实现，若需急用，更新到该版本即可，但在文档中是得不到这一信息的，在相关的issue中也不一定会说明要安装哪个版本；比如wepy-cli 1.7.0版本后，创建项目命令是 wepy init 而不是 wepy new, 输出配置的属性是 target 而不是 output；比如methods中只放视图响应事件，自定义事件需放在其外面，文档是后来才增加说明的。
  • 因此，对于文档中未更新的新的支持，要么耐心等待正式版本发布，要么到相关issue下参与讨论获取最新支持情况；对于文档中亲试有误的地方，可能是新版修改了实现；遇到文档未说明的问题，可搜索相关issue.
• 一些新的支持除了wepy-cli需更新版本，项目中的wepy也要相应更新版本，二者版本号一般是对应的，alpha版本除外。
• wepy预留了输出web版本的能力，但至目前为止，还不适合投入生产，毕竟每个端有每个端的特性。

mpvue

• 命名意思：mp, nimi program的缩写，mpvue, Vue.js in mini program
• 框架基于 Vue.js 核心，mpvue 修改了 Vue.js 的 runtime 和 compiler 实现，使其可以运行在小程序环境中，从而为小程序开发引入了整套 Vue.js 开发体验。

• 特性：

  • 组件化开发
  • 完整Vue.js开发体验，全部.vue单文件组件
  • Vuex数据管理方案
  • webpack构建机制：自定义构建策略、开发阶段hotReload
  • 支持npm
  • 使用 Vue.js 命令行工具 vue-cli 快速初始化项目
  • H5代码转换编译成小程序目标代码能力（可使用html开发）
• 构建与编译工具：vue-cli，编译配置：build/

• 配套设施

  • mpvue-loader
  • mpvue-webpack-target
  • postcss-mpvue-wxss
  • px2rpx-loader
  • 其他
• 项目目录结构：

├── build                  编译配置
├── config                 编译配置
├── dist                   小程序运行代码目录（该目录由编译生成）
├── node_modules           
├── src                    开发目录
|   ├── components         组件目录
|   |   ├── com_a.vue      组件a
|   |   └── com_b.vue      组件b
|   ├── pages              页面目录
|   |   ├── index          index页面（默认会在src/main.js主入口生成pages配置，路径为pages/index/main）
            ├── index.vue  由其入口文件编译main.js后，生成index/main.js、index/main.wxml和index/main.wxss文件
            ├── main.js     页面默认入口文件（config属性会编译为页面配置文件index/main.json）
|   |   └── other           other页面（默认会在src/main.js主入口生成pages配置，路径为pages/other/main）
            ├── index.vue  由其入口文件编译main.js后，生成other/main.js、other/main.wxml和other/main.wxss文件
            ├── main.js    页面默认入口文件（config属性会编译为页面配置文件other/main.json）
|   └── app.wpy            小程序配置项（全局数据、样式、声明钩子等；经build后，会在dist目录下生成app.js、app.json和app.wxss文件）
└── static                 静态文件，会直接被复制到dist/下
└── package.json           项目的package配置
└── project.config.json    小程序开发工具的配置

一点疑问：

• 页面目录结构上感觉不如WePY简洁，每个页面源代码由两个文件组成，且默认其入口文件命名为main.js, 若换其他命名的话，需要修改编译配置 build/webpack.base.conf.js
• 为什么不借鉴小程序原生开发方式，同一页面的文件命名相同，这样在目录上可以根据喜好选择减少一层；若如此，需修改编译配置pages/下的js文件默认为入口页面，但这样必须保证pages/下的js文件均为页面入口文件；或者增加一个entry/目录，用于存放页面入口文件，但分包又如何支持？
• pages页面路径感觉还是用户自己配置的好，不要自动生成

mpvue原理

• mpvue 保留了 vue.runtime 核心方法，无缝继承了 Vue.js 的基础能力
• mpvue-template-compiler 提供了将 vue 的模板语法转换到小程序的 wxml 语法的能力
• 修改了 vue 的建构配置，使之构建出符合小程序项目结构的代码格式： json/wxml/wxss/js 文件

小结

• mpvue与WePY不同，除将代码编译为原生框架所支持的外，还支持使用html标签，因此可以增加代码复用性，比较适合需要Web端、小程序端等多端支持的项目，尤其是已有Vuejs实现的Web端的产品，需要快速开发一个小程序版本的需求场景；且该开发团队更熟悉Vue.js。
• 熟悉mpvue, 可以看看 mpvue-weui: mpvue重写weui

• Web端与小程序如何代码复用？

  • 对于一般的容易转换的html标签，如div/p/ul/li等可以直接使用，让mpvue的编译器帮你完成转换，但对于如picker/checkbox/radio/switch/slider/swiper/progress/icon等这些与html标签不能简单对应的小程序原生组件，mpvue的建议是按小程序原生组件的用法，只不过事件绑定与变量动态赋值的语法要按mpvue的写法（mpvue使用手册有涉及，请别踩坑）
  • 基于上一点，Web端UI复用其实也只是局限于那些容易转换的标签，对于差异化较大的UI,是需要按每个端的特性做修改的
  • 小程序的组件默认样式是weui风格，因此，小程序一些组件与api功能，比如toast/loading/modal/actionsheet/picker，Web端可以借助weui.js来完成
  • 小程序许多API，Web端可对应使用微信的js-sdk

疑问

mpvue的最主要的功能，是Web端与小程序一致的开发体验，以及尽可能地实现UI复用，但据我目前的了解，UI复用也只是一些简单的容易转换的UI，差异化较大的还是需要各端各自实现的，那么，所谓的一套代码跑多端的目的并没有达到，从这个角度来看，mpvue跟WePY的功能其实是一样的；

所以，mpvue最大的不同，其实在于完全的Vuejs开发体验吧？

特性对比

附

• WePY文档

  • 使用手册
  • API文档
  • github地址

• mpvue文档

  • 介绍
  • 使用手册
  • 项目建构文档
  • 常见问题
  • github地址