小程序原生开发与第三方框架选择

比来正在更新《微信小法式入门与理论》一书的第二版。书中有一章节谈到了”多样化的小法式开辟“，摘取并加以整理分享给列位开辟者。我一向不保举也不提倡公众号阅读进修编程，文章更多的是列出小法式现在多样化的框架挑选，并简单分解它们之间的差别。点到为止，以开辟大师的视野，至于若何挑选，还请君自斟。每个框架的具体技术特点官方文档里都有，自行搜索即可。

原生开辟

什么是原生开辟方式？这个概念实在挺难用笔墨去正确界定的，由于官方也没有对原生开辟方式作出界说。这个概念实在也是不言而喻的，我们依照小法式官方文档中的描写去开辟小法式就属于原生开辟的方式。

界说一个名词对于数学是成心义的，但对于互联网而言，界说只是大佬们脑回路中的灵感闪现。雷军可以重新界说”什么是现货“、罗永浩可以重新界说”操纵系统“，互联网时代的界说又不用负义务，每小我都可以去重新界说一堆老久的名词，否则那里来的流量？

咱就不去界说所谓的原生开辟，我们只需方法会一些小法式原生开辟的缺点以及为什么会出现众多的第三方小法式框架便可以了。经过两年多的成长，小法式已处理很多早期时辰诸如：没有自界说组件、UI控制自在度不高、ES6支持度不高、开辟工具几近同即是废材等题目，但现在的版本仍然有一些缺点：

• 不能间接利用Less/Sass/Stylus等预编译CSS
• ES新标准支持度太低，比如不支持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。

那到底用什么开辟小法式？这是个困难，一个永久的迷。你用什么技术计划开辟小法式？一路留言聊聊吧。

LinUI小法式组件库：

LinCMS开源处理计划：

爱我，请关注我的公众号：