本文列举了当今小程序的框架选择，并简单分析了它们之间的区别。疮，探讨大家的观点，比如怎么选，问问自己。每一帧的详细技术功能都有，可以自行搜索。

　　初级开发

　　当地的发展方式是什么？这个概念其实很难用文字来准确定义，因为原生开发方法没有官方定义。这个概念其实不言而喻。我们会根据小程序官方文档的描述来开发一个小程序。

　　定义对于数学来说是有意义的，但是对于互联网来说，定义只是脑中灵光一闪。雷军可以重新定义“场景的目标”，罗永浩可以重新定义“操作系统”，互联网时代的定义是不负责任的。大家都可以重新定义一堆由来已久的名词，不然，流量？

　　如果不定义所谓的原生开发，我们只需要了解小程序原生开发的缺陷，以及为什么会有很多第三方小程序框架。经过两年多的时间，applet已经解决了很多早期的问题，比如：没有自定义组件，UI控制自由度不高，ES6支持度不高，开发工具几乎等同于废物，但是目前的版本还是有一些缺陷：

　　不能使用预编译的CSS，比如小于/sass/stylus。

　　新ES标准支持度太低，比如Asncy/AWAIT(ES6/ES7好尴尬，NodeJS还不如ES标准)

　　虽然支持承诺，但是官方的API返回并不是承诺，仍然是回调函数。

　　没有国家管理，请参考Vuex和Redux。

　　没有双向数据绑定(严格来说，这不是缺陷，主要是性能问题)

　　无滤镜(LINUI用WXS实现了一些主流滤镜，但官方支持显然更方便)

　　强制WXSS、WXML和JS代码成为3个不同的文件。

　　这些缺点让习惯了现代前端开发方式的开发者不那么舒服。那为什么现在有那么多第三方开发框架？除了以上原生小程序，还有其他原因：

　　小程序不再专指微信小程序，仍然是支付宝/百度/Title小程序。开发人员可能对多功能开发有多种需求，我希望代码能在多端运行，这是很直接的一条。

　　有些开发者想用Vue，响应开发小程序。在我看来，小程序或者多端编译的缺陷并不是第三方框架的主要原因。第三条：对于使用，这是真的。我们会在后面跟上。

　　MPVUE。

　　githubstars:16k

　　最早出现的是Wepi语言，然后是美团的MPVUE开源。MPVUE有两个最早的点：

　　想用Vue开发一个小程序我希望大量现有的H5网页可以转换成小程序代码。

　　Mpvue是从Vue.js继承来的，和我们后面讲的MPX不一样。总之MPVue希望开发者不需要了解小程序，只需要了解有Vue的小程序的Vue。

　　但是我可以随口说，我觉得市场上用的小程序在市场上很重要，H5超越的需求很重要；简单分析一下，小程序传送H5的技术难度其实比H5传送低很多，稳定性也高很多。从实用的角度来说，你想把你的H5变成一个小程序吗？现在很多新产品都是先做一个小程序，然后是H5版的网页。

　　我相信大部分开发者不用MPVUE是因为我想把H5变成一个小程序，而是因为第一点：我想用VUE。

　　最后，你可能忽略了，小程序可以运行H5，而且有很多成功的案例，因为现在的小程序已经很好的支持WebView了，对JS也没有太大的限制。你可以在设备中嵌入H5。看了小程序的1 h5版本，感觉体验还不错。

　　抛出欲望的愿景，MPVue只吸引了我的国民管理。

　　芋

　　GitHub Stars:16K

　　应该算是去年下半年最受小猫欢迎的第三方框架，京东团队出品。或者列举芋头的优点：

　　多端编译。理论上，一套代码可以编译成微信/apapay/百度/title。

　　使用反应生态发展批准

　　英国《三国志传》中只有安古拉吉斯缺席。

　　芋头的突出显示主要是多端编译，问题就出在这个多端编译上。微信小程序和支付宝小程序虽然语法层面的组件不大，但也不可能同时支持这么多端口。

　　组件可能会被完美编译，但是很多开发者忽略了一个事实，那就是除了组件之外，还有另外一个组件有一个API，而API的每一个不同的应用其实都是非常大的，这是编译后必然要手工完成的。调整。还有一点就是，真的需要开发这么多小程序的人有多少？金额较高的是双端：微信和支持。你确定了用太郎开发一套代码的成本要用微信化妆写一个集合，然后复制粘贴替换代码吗？

　　MPX。

　　GitHub Stars:800

　　滴水产生。滴滴很聪明，MPX比较晚，所以他的路线和太郎、MPVue不一样。

　　Taro和MPVUE是编制框架，充分利用了VUE的反应和生态发展。但是MPX不同。他非常聪明地将MPX定位为小程序的语法增强框架。换句话说，也是以原生小程序为主，但是可以使用Vue的一些高级功能。非常聪明的练习。首先，因为MPVue在前，MPX没有亮点；第二，因为你要完成漂亮的Vue编译小程序，要付出非常高的维护成本，所以不一定要解决。

　　以下是MPX文件的内容：

　　我们利用Vue中优秀的语法特性来增强小程序，而不是让用户直接使用Vue语法来开发一个小程序，主要基于以下几点考虑：

　　翻译框不能支持源帧的所有语法特征(例如在反应中生成的Vue模板或JSX中的动态特征)。用户在使用源框架的语法时可能会遇到不可预知的错误，但这是不确定的。

　　小程序本身的技术规范也在不断更新。很多新的技术规范在翻译框架中无法支持或者需要支持或者需要很高的支持成本，而对于增强框架，只要新的技术规范与增强的特性不冲突，就可以直接支持。

　　一个非常清晰的团队。目前还有其他几个框架支持小程序的新功能，以跟上官方的更新速度。

　　我的观点

　　谈人生谈感情，我觉得这个过程很重要。但是为了工作，我只点了成绩。我从未对任何技术有偏见，但我唯一的财富是我的时间。如果我能解决原生开发的问题，我绝对不会花学习第三方框架的成本。如果我能用python解决问题，我就不会用java写java了。

　　第三方框架的存在是有价值的。确实解决了很多人的需求，但我不建议大家盲目。如果是框架，你不知道为什么用，然后用local，最平和的选择。

　　不要忽略这一点：你有第二方框架吗？当然这是不可能的，因为第三方框架。你必须更熟练地开发原生小程序。其他的，你是怎么解决各个第三方框架的“坑”的？没有框架能保证完美翻译成小程序。对付LINUI的时候，至少找到了最近的队伍。很多框架推广支持applet的自定义组件，但是我们使用第三方测试，因为这些框架不能编译applet wxs。