from | 公用号 林间有风

作者 | 七月

最近正在更新《微信小程序入门与实践》一书的第二版。书中有一章节谈到了”多样化的小程序开发“，摘取并加以整理分享给各位开发者。我一向不推荐也不提倡公众号阅读学习编程，文章更多的是列出小程序如今多样化的框架选择，并简单剖析它们之间的差异。点到为止，以开拓大家的视野，至于如何选择，还请君自斟。每个框架的详细技术特点官方文档里都有，自行搜索即可。

原生开发

什么是原生开发方式？这个概念其实挺难用文字去准确界定的，因为官方也没有对原生开发方式作出定义。这个概念其实也是不言而喻的，我们按照小程序官方文档中的描述去开发小程序就属于原生开发的方式。

定义一个名词对于数学是有意义的，但对于互联网而言，定义只是大佬们脑回路中的灵感闪现。雷军可以重新定义”什么是现货“、罗永浩可以重新定义”操作系统“，互联网时代的定义又不用负责任，每个人都可以去重新定义一堆老久的名词，不然哪里来的流量？

咱就不去定义所谓的原生开发，我们只需要了解一些小程序原生开发的缺陷以及为什么会出现众多的第三方小程序框架就可以了。经过两年多的发展，小程序已解决很多早期时候诸如：没有自定义组件、UI控制自由度不高、ES6支持度不高、开发工具几乎等同于废材等问题，但现在的版本依然有一些缺陷：

不能直接使用Less/Sass/Stylus等预编译CSSES新标准支持度太低，比如不支持Asncy/Await（ES6/ES7就是那么尴尬，NodeJS对于ES的标准支持甚至还不如小程序)虽然支持Promise，但官方的API返回结果并不是Promise，依然是Callback回调函数没有状态管理，参考Vuex和Redux没有双向数据绑定（严格说这不算是一个缺陷，主要是出于性能的考虑)没有过滤器（LinUI使用wxs实现了一些主流过滤器，但官方的支持显然会更加方便）强制将WXSS、WXML和JS代码分离到3个不同的文件中

这些缺点让习惯了现代化前端开发方式的开发者写起代码来并不是那么舒服。那为什么现在会出现如此多的第三方开发框架呢？除了以上原生小程序语法缺陷外，还有一些其他的原因：

小程序已不再特别指代微信小程序，现在还有支付宝/百度/头条小程序。开发者可能有多端开发小程序的需求，希望让一份代码能够在多端运行，这是一个很直接述求一些开发者希望使用Vue和React来开发小程序

在我看来，小程序的缺陷或者多端编译都不是第三方框架出现的主要原因，第三条：为了使用而使用，才是真正的原因。后面我们会聊到这点。

WePY

GitHub Stars：17k +

WePY应该是最早的第三方框架，腾讯团队出品。两张图说明一些问题：

图 一

图二

图一，有违反广告法的嫌疑

图二，真该改改了。无论是组件化、NPM、Promise、ES6、TypeScript微信官方均已支持。实在没有吸引力。

Mpvue

GitHubStars：16K +

最早出现的是WePY，随后就是美团开源的Mpvue。Mpvue最早诞生的目的有两点：

想用Vue开发小程序希望现有的大量的H5页面可以转化成小程序代码

Mpvue是继承自vue.js，这和我们后面聊到的滴滴的Mpx有一些不同。简单来讲，Mpvue希望开发者不需要了解小程序，只需要了解Vue即可用Vue开发小程序。

但恕我直言，我觉得以现在小程序的市场占用率，H5转小程序的需求真不是那么重要；相反，能把小程序转成H5才是真正需要的需求。简单分析，小程序转H5的技术难度其实比H5转小程序要低很多的，稳定性也是要高出不少的。从实际情况的角度来看，大家有多少需求是想把H5转成小程序的呢？现在很多新的产品首先就是做小程序，其次是网页的H5版本。

我相信绝大多数开发者根本不是因为想把H5转成小程序而用Mpvue，而是因为第一点：想用Vue。

最后，可能大家忽略了一个事实，小程序本身就是可以运行H5的，已经有不少成功的案例了，因为现在的小程序已经可以很好的支持WebView，并且对JS的运行没有太多的限制，你完全可以把H5嵌套到小程序中。我看了1款H5版本小程序，感觉体验还不错。

抛开单纯想用Vue而用Vue的观点，mpvue对我的吸引只有状态管理。

Taro

GitHub Stars：16K +

应该算是去年下半年最火的小程序第三方框架，京东团队出品。还是列出Taro的优点：

多端编译。理论上一套代码可以编译成微信/支付宝/百度/头条小程序

使用React生态开发小程序

三国群英传现在只剩AngularJS缺席了。

Taro的亮点主要在于可以多端编译，但问题恰恰是在这个多端编译上。虽然微信小程序和支付宝小程序的组件在语法层面上差别不大，但要同时完美支持这么多端简直不敢想象。

组件也许可以完美编译，但很多开发者忽略了一个事实，小程序中除了有组件，还有API，每个不同小程序的API差异其实是极大的，这难免需要在编译后进行大量的手动调整。

另外一点是，有多少人是真的需要开发这么多端的小程序？充其量最多就是双端：微信和支付宝。你确定用Taro开发一套代码的成本要比用微信小程序写一套，然后复制黏贴改改代码要低吗？

Mpx

GitHub Stars：800 +

滴滴出品。滴滴是非常聪明的，Mpx诞生较晚，所以他走的路线和Taro、Mpvue不太一样。

Taro和Mpvue属于编译型框架，完全使用React和Vue的生态开发。但Mpx不同，他很聪明的把Mpx定位成小程序的语法增强框架。换句话来讲，还是以原生小程序开发为主，但你可以使用Vue的一些高级特性。

很聪明的做法。一是因为Mpvue在前，Mpx走同样的路线没有亮点；二是因为想去做到完美的的Vue编译小程序这要付出极高的维护成本，还不一定能完美解决。

以下摘自Mpx文档：

我们使用Vue中优秀的语法特性增强了小程序，而不是让用户直接使用vue语法来开发小程序，之所以采用这种设计主要是基于如下考虑：转译型框架无法支持源框架的所有语法特性(如Vue模板中的动态特性或React中动态生成的jsx)，用户在使用源框架语法进行开发时可能会遇到不可预期的错误，具有不确定性小程序本身的技术规范在不断地更新进步，许多新的技术规范在转译型框架中无法支持或需要很高的支持成本，而对于增强型框架来说只要新的技术规范不与增强特性冲突，就能够直接支持很清醒的团队，目前其他的几个框架对于小程序新特性的支持根本跟不上官方的更新速度。

我的观点

谈人生，谈情怀，我觉得过程很重要。但对于工作，我只以结果为导向。我从来对任何技术没有什么偏见，但我唯一珍惜的是我的时间。如果能用原生开发解决的问题，我绝对不会花成本去学习第三方框架。如果能用Python解决的问题，我100%不会用Java来写。

第三方框架的存在是有价值的，它确实解决了不少人的需求，但我不建议大家盲从。如果一个框架你根本不知道你为什么用它，那还是用原生吧，最省心的选择。

同学们也不要忽略了这个一点：用第三方框架就完全不需要学习原生小程序吗？这当然是不可能的，正是因为用了第三方框架，你反而要更加精通原生小程序的开发。不然你怎么解决各个第三方框架的”坑“？没有哪个框架能100%保证完美转译成小程序的。至少最近团队在处理LinUI的时候就发现，很多框架都宣传支持小程序的自定义组件，然而我们用第三方测试的结果是，这些框架根本无法编译小程序的WXS。

那到底用什么开发小程序？这是个难题，一个永恒的迷。你用什么技术方案开发小程序？一起留言聊聊吧。