自 2017-1-9
微信小程序诞生以来,历经2年多的迭代升级,已有数百万小程序上线,成为继Web、iOS、Android之后,第四大主流开发技术。
与之相随,小程序的开发生态也在蓬勃发展,从最初的微信原生开发,到wepy
、mpvue
、taro
、uni-app
等框架依次出现,从刀耕火种演进为现代化开发,生态越来越丰富。
选择多了,问题也就来了,开发小程序,该用原生还是选择三方框架?
首先,微信原生开发的槽点大多集中如下:
-
原生开发对Node、预编译器、webpack支持不好,影响开发效率和工程构建流程
-
微信定义了一个不伦不类的语法,不如正经学vue、react,学会了全端通用,而不是只为微信小程序
-
vue/react生态里有太多周边工具,可以提高开发效率,比如ide、校验器、三方库。。。
-
微信那个ide和专业编辑器相比实在不好用
同时,开发者对三方框架,又总是有各种顾虑:
-
怕性能不如原生
-
怕有些功能框架实现不了,只能用原生
-
怕框架不稳定,跳到坑里
-
以及诸多三方框架,到底该用哪个
面对如此纠结的场景,不少热心开发者发布评测文章分享经验,但感觉众说纷纭,过期信息太多。缺少一份非常专业的、深度的,或者按如今流行的话来讲,“硬核的”评测报告。
做评测报告这件事,不同于泛泛经验分享,其实非常花费时间。它需要:
-
你必须成为每一个框架的专业使用人员,而不是浅浅的了解一下这些框架
-
真实的动手写多个平台的测试例,比较各个平台的功能、性能,了解他们的社区情况、技术服务情况
-
你要有长期跟踪和更新报告的能力,避免半年后沦为过期信息
换言之:评测要想真,功夫得做深!
本文从面向用户、面向开发者
两大维度七大细项,对微信原生及主流的wepy
、mpvue
、taro
、uni-app
开发框架进行横向对比,希望给开发者在小程序框架选型时提供一种参考思路。
本文基于各框架官网可采集到的公开数据及真实测试数据,希望客观公正地评价各个框架的现状和优劣。但宥于利益相关,本文的观点很可能是带有偏向性的,大家可以带着批判的眼光来看待,如发现本文中有任何评测失真,欢迎在这里报 issuse。
面向用户、面向开发者
维度,具体包括:
-
用户:提供完整的业务实现,并保证高性能体验
-
开发者:平缓的学习曲线、现代开发体验(工程化)、高效的社区支持、活跃的开发迭代、多端复用。
一、用户
1.1 功能实现
软件开发,首要目标是向用户提供完整、闭环的业务功能。
在web开发中,如果vue、react等框架的使用,造成开发者无法操作浏览器提供的所有api,那这样的框架肯定是不成熟的。小程序开发也一样,任何开发框架,都不能限制底层的api调用。
而各种业务功能底层依赖微信暴漏的组件和接口(微信官网介绍的组件和 API 规范,也即微信原生API),三方框架是基于微信原生进行的二次封装,开发者此时常会有个疑问:小程序在不断的迭代升级,如果某项业务依赖于最新的小程序API,但三方框架尚未封装,该怎么办?
实际上就像web开发的vue、react一样,浏览器出了一个新API,并不会涉及vue、react的升级。本评测里的所有框架,都不会限制开发者调用底层能力。这里详细解释下原因:
-
wepy:未对小程序API作二次封装,API依然使用微信原生的,框架与微信小程序是否新增API无关
-
mpvue:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似
mpvue.request()
-
taro:支持微信的所有原生组件和api,无限制。同时框架封装了自己的跨端API,使用方式类似
Taro.request()
,支持Taro 代码与小程序代码混写,可通过混写的方式调用框架尚未封装的小程序新增API -
uni-app:支持微信的所有原生组件和api,无限制。在跨端方面,即便仍然使用微信原生的组件和API,也可以直接跨端编译到App、H5、以及支付宝百度头条等小程序。但为了管理清晰,推荐使用uni封装的API,类似
uni.request()
。同时支持条件编译,可在条件编译代码块中,随意调用各个平台新增的API及组件
注:以上顺序,按各个框架的诞生顺序排序,下同。
故,三方框架均可调用所有小程序API,完成用户的业务需求,这个维度各框架是无差别的。
然而有差别的,是性能体验。
1.2 性能体验
三方框架,内部大多做了层层封装,这些封装是否会增加运行负载,导致性能下降?尤其是与原生微信小程序开发相比性能怎么样,这是大家普遍关心的问题。
为客观的进行对比,我们特意搭建了一个测试模型,详细如下:
-
开发内容:开发一个仿微博小程序首页的复杂长列表