Applet development: a native or selected frame (wepy / mpvue / uni-app / taro)?

Applet development: a native or selected frame (wepy / mpvue / uni-app / taro)?

Since 2017-1-9 small micro-channel program was born, after two years of iterative upgrade, there are millions of small programs on line, becoming Web, iOS, Android, the fourth-largest mainstream development technologies.

The accompanying, development of eco-applet is also booming, from the initial micro-channel native development, to wepy, mpvue, taro, uni-app frameworks, etc. appear one after another, from the slash and burn evolved into a modern development, ecology has become increasingly diverse.

Choose more, problems will come, the development of small procedures, the use of native chose tripartite framework?

First, the development of native micro-channel groove points are concentrated as follows:

1. Native Development of Node, the pre-compiler, webpack support is not good, affect the development efficiency and project build process
2. Micro letter defines the syntax of a nondescript, as serious science vue, react, learn the whole end of the universal, and not just for small micro-channel program
3. vue / react the surrounding ecology there are too many tools that can improve development efficiency, such as ide, checker, three libraries. . .
4. Micro letter that ide and professional editors really bad compared with

At the same time, developers of the tripartite framework, but there are always a variety of concerns:

1. Afraid to perform as well as native
2. Some functions can not be afraid framework to achieve, can only use native
3. Fear of unstable framework, jump pit
4. And many tripartite framework, the use of which in the end

Faced with such a tangled scene, many enthusiastic developers publish review article to share experiences, but it feels different opinions, too outdated information. Lack of a very professional, or press the now popular saying in terms of the evaluation report "hard core" depth.

Do evaluation report it, unlike the general experience sharing, in fact, very time-consuming. it needs:

• You have to use a professional staff of each frame, rather than the shallow look at these frameworks
• Real hands-functional test cases written for multiple platforms, each platform comparison, performance, understand their communities, the technology of service
• After you have the long-term ability to track and update report, six months to avoid becoming outdated information

In other words: Trial To really, the effort was so deep!

uni-app team spent two weeks time to complete this report, and insisted on a quarterly update this evaluation report. At present time is updated in May 2019.

From the user-oriented, two dimensions for developers seven breakdown of native micro-channel and mainstream wepy, mpvue, taro, uni-app development framework for horizontal comparison, developers want to provide a frame upon selection of an applet kinds of reference ideas. Based on the official website of each frame can be collected public data and real test data, hoping to re-assess the current situation and the pros and cons of each frame. But to forgive stakeholders, views of this article is most likely a biased, we can take a critical eye to look at, as found herein any distortion evaluation, welcome here to newspaper issuse.

User-oriented, dimensions for developers, including:

1. Users: to provide a complete service implementation, and ensure high performance experience
2. Developer: gentle learning curve, modern development experience (engineering), efficient community support, active development iterations, multiport reuse

2. User

1.1 functions to achieve

Software development, the primary goal is to provide users with a complete, closed-loop business functions.

In web development, if you use the framework of vue, react, resulting in developers can not operate all api provided by the browser, and that such a framework is certainly premature. The same small program development, any development framework, can not restrict api call the bottom.

And various business functions underlying dependent micro-channel storm drain of components and interfaces (micro-channel official website component and the API specifications described, i.e. micro-channel native API), the tripartite framework is based on the second package micro-channel native performed, the developer at this time often have a question: applets continuous iterative upgrade, if a business relies on the latest applet API, but the package has not yet tripartite framework, in how to do?

Actually like web development vue, as react, browser out a new API, and it will not involve upgrade vue, react in. All this in the evaluation framework, will not limit the ability of developers to call the bottom. Here to explain in detail the reasons:

• wepy: No small API procedure for the second package, still using the API of native micro-channel, micro-channel frame and the applet regardless of whether the new API
• mpvue: support micro-channel components of all native and api, unlimited. At the same time frame packages across their ends API, use similar mpvue.request ()
• taro: All native components that support micro-channel and api, unlimited. At the same time the new API framework encapsulates their cross-end API, use similar Taro.request (), support Taro code applet code to write mix, mixed mode by calling the frame has not yet written a small program package
• uni-app: all native components that support micro-channel and api, unlimited. In terms of cross-end, even if still use components and micro-channel native API, you can also directly across the terminal to compile App, H5, and Alipay Baidu headlines and other small programs. However, in order to manage clarity, the API recommended uni package, similar uni.request (). Supports conditional compilation, may be conditionally compiled code block, each new random call and assembly platform API

Note: The above sequence, the sequence order of the frame by the birth, the same below.

Therefore, all the tripartite framework can be called applets API, complete the user's business needs, the dimensions of each frame is undifferentiated.

However, there is a difference, the performance experience.

1.2 Performance Experience

Tripartite framework, they made mostly internal layers of packaging, whether these packages will increase the running load, resulting in performance degradation? Especially how to develop performance compared with the native small micro-channel program, which is generally concerned about the issue.

As an objective comparison, we deliberately built a test model, detailed as follows:

• Content Development: Develop a program imitation microblogging home a long list of complex, support the pull-down refresh, pull-flip, thumbs up.
• Interface is as follows:

 

• Development Version: development of a total of five versions, including a micro-channel original version, wepy version, mpvue version, taro version, uni-app version, according to official guidelines default network installation by cli way.
• Test open source code (Github repository address: https: //github.com/dcloudio/test-framework), Tips: If students feel test code writing is defective, welcome to submit or PR Issus
• Test models: Red rice Redmi 6 Pro, MIUI 10.2.2.0 stable version (the latest version), micro-channel version 7.0.3 (the latest version)
• Test environment: each frame before starting the test, kill each App process, clear the memory, to ensure that the test machine environment consistent; each read from the local static data, shielding the network differences.

We imitate the above microblogging program, for example, test two easy points out the performance issues: a long list of add, in response to a large number of thumbs components.

1.2.1 long list of loaded

List imitation microblogging is a list containing many components, the greater the complexity of this list of pressure on performance, it is suitable for performance testing.

From the trigger Raja upload data to update the page rendering is complete, the need for accurate timekeeping. Human visual timing certainly not, we use the program bury points, we developed the following timing timing:

• 计时开始时机：交互事件触发，框架赋值之前，如：上拉加载（onReachBottom）函数开头
• 计时结束时机：页面渲染完毕(微信setData回调函数开头)

Tips：setData回调函数开头可认为是页面渲染完成的时间，是因为微信setData定义如下(微信规范)：

 

测试方式：从页面空列表开始，通过程序自动触发上拉加载，每次新增20条列表，记录单次耗时；固定间隔连续触发 N 次上拉加载，使得页面达到 20*N 条列表，计算这 N 次触发上拉到渲染完成的平均耗时。

测试结果如下：

 

说明：以400条微博列表为例，从页面空列表开始，每隔1秒触发一次上拉加载（新增20条微博），记录单次耗时，触发20次后停止（页面达到400条微博），计算这20次的平均耗时，结果微信原生在这20次 触发上拉 -> 渲染完成 的平均耗时为876毫秒，最快的uni-app是741毫秒，最慢的mpvue是4493毫秒

大家初看这个数据，可能比较疑惑，别急，下方有详细说明

说明1：为何 mpvue/wepy 测试数据不完整?

mpvue、wepy 诞生之初，微信小程序尚不支持自定义组件，无法进行组件化开发；mpvue、wepy 为解决这个问题，将用户编写的Vue组件，编译为WXML中的模板（template)，变相实现了组件化开发能力，提高代码复用性，这在当时的技术条件下是很棒的技术方案。

但如此方案，在页面复杂、组件较多的时，会大量增加页面 dom 节点数量，甚至超出微信的 dom 节点数限制。我们在 红米手机（Redmi 6 Pro）上实测，页面组件超过500个时，mpvue、wepy实现的仿微博App就会报出如下异常，并停止渲染，故这两个测试框架在组件较多时，测试数据不完整。这也就意味着，当页面组件太多时，无法使用这2个框架。

dom limit exceeded please check if there's any mistake you've made

Tips1：wepy官网的CHANGELOG，提到 v1.7.2 测试版本添加了对小程序原生组件的支持，实测坑很多，因为是测试版，官方在 issue 中也表示不推荐使用；按照官网文档，默认安装的 v1.7.3 正式版本并不支持原生组件

Tips2：wepy在400条列表以内，为何性能高于微信原生框架，这个跟自定义组件管理开销及业务场景有关（wepy编译为模板，不涉及组件创建及管理开销），后续对微博点赞，涉及组件数据传递时，微信原生框架的性能优势就提现出来了，详见下方测试数据。

说明2：为什么测试数据显示uni-app 会比微信原生框架的性能略好呢？

其实，在页面上有200条记录（200个组件）时，taro 性能数据也比微信原生框架更好。

微信原生框架耗时主要在setData调用上，开发者若不单独优化，则每次都会传递大量数据；而 uni-app、taro 都在调用setData之前自动做diff计算，每次仅传递变动的数据。

例如当前页面有20条数据，触发上拉加载时，会新加载20条数据，此时原生框架通过如下代码测试时，setData会传输40条数据

data: {
 listData: []
},
onReachBottom() { //上拉加载
 let listData = this.data.listData;
 listData.push(...Api.getNews());//新增数据
 this.setData({
 listData
 }) //全量数据，发送数据到视图层
}
复制代码

开发者使用微信原生框架，完全可以自己优化，精简传递数据，比如修改如下：

data: {
 listData: []
},
onReachBottom() { //上拉加载
 // 通过长度获取下一次渲染的索引
 let index = this.data.listData.length;
 let newData = {}; //新变更数据
 Api.getNews().forEach((item) => {
 newData['listData[' + (index++) + ']'] = item //赋值，索引递增
 }) 
 this.setData(newData) //增量数据，发送数据到视图层
}
复制代码

经过如上优化修改后，再次测试，微信原生框架性能数据如下：

 

从测试结果可看出，经过开发者手动优化，微信原生框架可达到更好的性能，但 uni-app、taro相比微信原生，性能差距并不大。

这个结果，和web开发类似，web开发也有原生js开发、vue、react框架等情况。如果不做特殊优化，原生js写的网页，性能经常还不如vue、react框架的性能。

也恰恰是因为Vue、react框架的优秀，性能好，开发体验好，所以原生js开发已经逐渐减少使用了。

复杂长列表加载下一页评测结论：微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro> wepy > mpvue

Tips：有人以为uni-app和mpvue是一样的，早期uni-app确实使用过mpvue，但后来因为性能和vue语法支持度问题已经重新开发了。

1.2.2 点赞组件响应速度

长列表中的某个组件，比如点赞组件，点击时是否能及时的修改未赞和已赞状态？是这项测试的评测点。

测试方式：

• 选中某微博，点击“点赞”按钮，实现点赞状态状态切换（已赞高亮、未赞灰色），
• 点赞按钮 onclick函数开头开始计时，setData回调函数开头结束计时；

在红米手机（Redmi 6 Pro）上进行多次测试，求其平均值，结果如下：

 

说明：也就是在列表数量为400时，微信原生开发的应用，点赞按钮从点击到状态变化需要111毫秒。

测试结果数据说明：

• wepy/mpvue 测试数据不完整的原因同上，在组件较多时，页面已经不再渲染了
• 基于微信自定义组件实现组件开发的框架（uni-app/taro），组件数据通讯性能接近于微信原生框架，远高于基于template实现组件开发的框架（wepy/mpvue）性能

组件数据更新性能测评：微信原生开发,uni-app,taro > wepy > mpvue

综上，本性能测试做了2个测试，长列表加载和组件状态更新，综合2个实验，结论如下：

微信原生开发手工优化,uni-app>微信原生开发未手工优化,taro > wepy > mpvue

2.开发者

在满足用户业务需求的前提下，我们谈谈开发者的需求，从如下几个维度比较：

• 平缓的学习曲线：简单易学，最好能复用现有技术栈，丰富的学习资料
• 高效的开发体验：现代前端开发流程、工程化支持
• 高效的社区支持：遇到问题，可很快的寻求到帮助
• 活跃的开发迭代：框架处于积极更新升级状态，无需担心停更

2.1 平缓的学习曲线

2.1.1 DSL语法支持

选择开发团队熟悉的、能快速上手的DSL，是团队框架选型的基本点。

首先微信原生的开发语法，既像React ，又像Vue，有点不伦不类，对于开发者来说，等于又要学习一套新的语法，大幅提升了学习成本，这一直被大家所诟病。

其它开发框架基本都遵循React、Vue（类Vue）语法，其主要目的：复用工程师的现有技术栈，降低学习成本。此时，框架对于原框架（React/Vue）语法的支持度就是一个重要的衡量标准，如果支持度较低、和原框架语法差异较大，则开发者无异于要学习一门新的框架，成本太高。

实际开发中发现，各个开发框架，都没有完全实现Vue、React在web上的所有语法：

wepy开发风格接近于 Vue.js，属于类Vue实现，相对微信原生开发算前进了一大步，但相比完整Vue语法还有较大差距，开发时需要单独学习它的规则；

mpvue、uni-app 框架基于 Vue.js 核心，通过修改 Vue.js 的 runtime 和 compiler，实现了在小程序端的运行。mpvue支持的Vue语法略少，uni-app 则基本支持绝大多数vue语法，如filter、复杂 JavaScript 表达式等；

taro 对于 JSX 的语法支持度，也达到了绝大多数都支持的完善程度。

DSL语法支持评测：taro,uni-app > mpvue > wepy > 微信原生

2.1.2 学习资料完善度

官方文档、问题搜索、示例demo的完备度方面：

• 微信原生：文档丰富，API搜索准确，官方有示例demo，支持官网上调起微信开发者工具，预览运行效果 详见
• wepy：文档只有2页，没有搜索，组件API等文档都直接看微信的文档。没有提供示例demo，很多配置需要靠猜。详见
• mpvue：文档较少，但其概念不复杂，组件API等文档都直接看微信的文档，学习难度低。问题搜索效果一般。没有提供示例demo。详见
• taro：基础文档完整，具体使用问题资源较少，问题搜索效果一般，示例demo只包含基础功能，仅发布了微信一端。详见
• uni-app：基础文档和各种使用专题内容丰富，问题搜索效果较好，示例demo功能完备，并发布为7端上线。详见

教学课程方面：

 

学习资料完善度评测：微信原生 > uni-app > mpvue , taro > wepy

2.2 现代前端开发体验

开发体验层面，处于明显劣势的是微信原生开发，主要差距在于：

• 框架开发提供了精简的代码组织（微信原生开发，一个Page由4个文件构成，写个代码要开的标签卡太多）
• 框架开发提供了更强大的组件化能力
• 框架开发提供了应用状态管理（类Vuex/Redux/Mobx等）
• 框架开发能灵活支持各种 Sass 等 预处理器
• 框架开发可提供完整的 ES Next 语法支持
• 框架开发方便自定义构建策略

其它小程序开发框架均支持cli模式，可以在主流前端工具中开发，且基本都带有d.ts的语法提示库。

由于mpvue、uni-app、taro直接支持vue、react语法，配套的ide工具链较丰富，着色、校验、格式化完善；wepy要弱一些，有部分三方维护的vscode插件。

好的开发工具，绝对可以大幅提升开发体验，这个维度上，明显高出一截的框架是uni-app，其出品公司同时也是HBuilder的出品公司，DCloud.io。HBuilder是四大主流前端开发工具（可对比百度指数），其为uni-app做了很多优化，故uni-app的开发效率、易用性非其他框架可及。

开发体验维度，对比结果：uni-app > taro,mpvue > wepy > 微信原生

这里可以输出一个结论：如果你需要工程化能力，那就直接忘了微信原生开发吧。

2.3 高效的社区支持

学习、开发难免遇到问题，官方技术支持和社区活跃度很重要。

 

本次评测demo开发期间，我们的同学（同时掌握vue和react），在学习研究各个多端框架时，切实感受到由于语法、学习资料、社区的差异带来的学习门槛，吐出了很多槽。

综合评估，本项评测结论：微信原生 , uni-app > taro > mpvue > wepy

2.4 活跃的开发迭代

开发者必须关心一个问题：该项目是否有人长期维护？

这个问题可以通过github commits 频次、产品更新日志（changelog）、百度搜索指数等指标来衡量和对比。

github commits 频次

我们采集2019年4月份（时间为4.1 ~ 4.30），每个项目在github上的master分支有commit的天数，结果如下：

 

Tips：

• 微信原生是闭源的，看不到 commits 数量，但保持每月至少一次的更新节奏，详见
• wepy的master分支无commit，最新的2.0.x分支在4月份也仅1天有commit记录

从 commit 的记录来看，taro、uni-app处于更新比较活跃的状态，wepy、mpvue则相对疲软，呈现无人维护之态。

产品更新日志

通过浏览产品更新日志，可确认产品是否在积极迭代、增加新功能、修复用户bug。

我们分别查看各框架官方链接的更新日志（CHANGELOG），下方是链接地址：

• 微信基础库更新日志
• wepy官网 CHAGELOG
• mpvue官网 Chang log
• taro github 更新日志
• uni-app官网更新日志

通过产品更新日志对比，微信原生、taro、uni-app 三者更新频繁，bug修复、新功能补充都处于比较紧凑的状态；而mpvue、wepy则已有长时间没有版本发布，wepy甚至有将近1年时间未发布正式版本，开发者选型需谨慎。

2.5 多端复用

随着微信小程序的火爆，支付宝、百度、字节跳动等公司也先后进入小程序领域，这些公司个个日活过亿，坐拥海量用户，企业主希望将自己的业务触达每个用户，不管这个用户在哪个小程序中。

需求转接到程序员这里，程序员怎么办？难道真的每个平台到处搬砖吗？此时，一套代码、多端发布就成为很多程序员的梦想，小程序跨端框架应运而生。

现实真能如此理想吗？每个跨端框架能否真的像官网宣传的那样，实现开发一次，发布到所有小程序平台？甚至和H5平台复用代码？

我们用事实说话，依然使用上述仿微博App，依次发布到各平台，验证每个框架在各端的兼容性，结果如下：

 

测试结果说明：

• ⭕ 表示支持且功能正常，❌ 表示不支持，其它则表示支持但存在部分bug或兼容问题

通过这个简单的例子可以看出，跨端支持度测评结论： uni-app,taro > mpvue> 原生微信小程序、wepy

但是仅有上面的测试还不全面，实际业务要比这个测试例复杂很多。但我们没法开发很多复杂业务做评测，所以还需要再对照各家文档补充一些信息。 由于每个框架的文档中都描述了各种组件和API的跨端支持程度。我们过了几家的文档，发现各家基本是以微信小程序为基线，然后把各种组件和API在其他端实现了一遍：

• taro：H5端实现了大部分微信的API
• uni-app：组件、API、配置，大部分在各个端均已实现，个别API有说明在某些端不支持。可以看出uni-app是完整在H5端实现了一套微信模拟器

跨端框架，一方面要考虑框架提供的通用api跨端支持，同时还要考虑不同端的特色差异如何兼容。毕竟每个端都会有自己的特色，不可能完全一致。

• taro：提供了js环境变量判断和统一接口的多端文件，可以在组件、js、文件方面扩展多端，不支持其他环节的分平台处理。
• uni-app：提供了条件编译模型，所有代码包括组件、js、css、配置json、文件、目录，均支持条件编译，可不受限的编写各端差异代码。

跨端框架，还涉及一个ui框架的跨端问题，评测结果如下：

• taro：官方提供了taro ui，只支持微信小程序和H5两端，不支持App，详见
• uni-app：官方提供了uni ui，可全端运行；uni-app还有一个插件市场，里面有很多三方ui组件，详见

最后补充跨端案例：

• mpvue：微信端案例丰富，未见其它端案例
• taro：微信端案例丰富，百度、支付宝、H5端亦有少量案例
• uni-app：多端案例丰富，官方示例已发布到7端(包括App端)

综合以上信息，本项的最终评测结论：uni-app > taro > mpvue > 原生微信小程序、wepy

这里可以输出一个结论，如果有多端发布需求，微信原生开发、wepy这两种方式可以直接排除了。

结语

真实客观的永远是实验和数据，而不是结论。不同需求的开发者，可以根据上述实验数据，自行得出自己的选型结论。

但作为一篇完整的评测，我们也必须提供一份总结，虽然它可能加入了我们的主观感受：

If you only develop small micro-channel program, not many-fold, then use the uni-app, taro is a better choice, they are equivalent to the web world vue and react, With these tools, no longer need to use native wxml development.

• If you insist on micro-channel native development, you need to pay attention to manually write optimized code to control setdata, and pay attention to its engineering capacity is very weak
• If you are react Department, then with taro
• If vue system, then use the uni-app, uni-app performance advantage on the surrounding ecology and development efficiency

If you develop multi-terminal, uni-app and taro are, according to their familiar technology stack selected, relatively speaking multiport maturity uni-app some more.