最近正在更新《微信小程序入門與實踐》一書的第二版。書中有一章節(jié)談到了”多樣化的小程序開發(fā)“，摘取并加以整理分享給各位開發(fā)者。我一向不推薦也不提倡公眾號閱讀學習編程，文章更多的是列出小程序如今多樣化的框架選擇，并簡單剖析它們之間的差異。點到為止，以開拓大家的視野，至于如何選擇，還請君自斟。每個框架的詳細技術特點官方文檔里都有，自行搜索即可。

原生開發(fā)

什么是原生開發(fā)方式？這個概念其實挺難用文字去準確界定的，因為官方也沒有對原生開發(fā)方式作出定義。這個概念其實也是不言而喻的，我們按照小程序官方文檔中的描述去開發(fā)小程序就屬于原生開發(fā)的方式。

定義一個名詞對于數學是有意義的，但對于互聯網而言，定義只是大佬們腦回路中的靈感閃現。雷軍可以重新定義”什么是現貨“、羅永浩可以重新定義”操作系統“，互聯網時代的定義又不用負責任，每個人都可以去重新定義一堆老久的名詞，不然哪里來的流量？

咱就不去定義所謂的原生開發(fā)，我們只需要了解一些小程序原生開發(fā)的缺陷以及為什么會出現眾多的第三方小程序框架就可以了。經過兩年多的發(fā)展，小程序已解決很多早期時候諸如：沒有自定義組件、UI控制自由度不高、ES6支持度不高、開發(fā)工具幾乎等同于廢材等問題，但現在的版本依然有一些缺陷：

• 不能直接使用Less/Sass/Stylus等預編譯CSS
• ES新標準支持度太低，比如不支持Asncy/Await（ES6/ES7就是那么尷尬，NodeJS對于ES的標準支持甚至還不如小程序)
• 雖然支持Promise，但官方的API返回結果并不是Promise，依然是Callback回調函數
• 沒有狀態(tài)管理，參考Vuex和Redux
• 沒有雙向數據綁定（嚴格說這不算是一個缺陷，主要是出于性能的考慮)
• 沒有過濾器（LinUI使用wxs實現了一些主流過濾器，但官方的支持顯然會更加方便）
• 強制將WXSS、WXML和JS代碼分離到3個不同的文件中

這些缺點讓習慣了現代化前端開發(fā)方式的開發(fā)者寫起代碼來并不是那么舒服。那為什么現在會出現如此多的第三方開發(fā)框架呢？除了以上原生小程序語法缺陷外，還有一些其他的原因：

• 小程序已不再特別指代微信小程序，現在還有支付寶/百度/頭條小程序。開發(fā)者可能有多端開發(fā)小程序的需求，希望讓一份代碼能夠在多端運行，這是一個很直接述求
• 一些開發(fā)者希望使用Vue和React來開發(fā)小程序

在我看來，小程序的缺陷或者多端編譯都不是第三方框架出現的主要原因，第三條：為了使用而使用，才是真正的原因。后面我們會聊到這點。

WePY

GitHub Stars：17k +

WePY應該是最早的第三方框架，騰訊團隊出品。兩張圖說明一些問題：

圖一

圖二

圖一，有違反廣告法的嫌疑

圖二，真該改改了。無論是組件化、NPM、Promise、ES6、TypeScript微信官方均已支持。實在沒有吸引力。

Mpvue

GitHubStars：16K +

最早出現的是WePY，隨后就是美團開源的Mpvue。Mpvue最早誕生的目的有兩點：

• 想用Vue開發(fā)小程序
• 希望現有的大量的H5頁面可以轉化成小程序代碼

Mpvue是繼承自vue.js，這和我們后面聊到的滴滴的Mpx有一些不同。簡單來講，Mpvue希望開發(fā)者不需要了解小程序，只需要了解Vue即可用Vue開發(fā)小程序。

但恕我直言，我覺得以現在小程序的市場占用率，H5轉小程序的需求真不是那么重要；相反，能把小程序轉成H5才是真正需要的需求。簡單分析，小程序轉H5的技術難度其實比H5轉小程序要低很多的，穩(wěn)定性也是要高出不少的。從實際情況的角度來看，大家有多少需求是想把H5轉成小程序的呢？現在很多新的產品首先就是做小程序，其次是網頁的H5版本。

我相信絕大多數開發(fā)者根本不是因為想把H5轉成小程序而用Mpvue，而是因為第一點：想用Vue。

最后，可能大家忽略了一個事實，小程序本身就是可以運行H5的，已經有不少成功的案例了，因為現在的小程序已經可以很好的支持WebView，并且對JS的運行沒有太多的限制，你完全可以把H5嵌套到小程序中。我看了1款H5版本小程序，感覺體驗還不錯。

拋開單純想用Vue而用Vue的觀點，mpvue對我的吸引只有狀態(tài)管理。

Taro

GitHub Stars：16K +

應該算是去年下半年最火的小程序第三方框架，京東團隊出品。還是列出Taro的優(yōu)點：

多端編譯。理論上一套代碼可以編譯成微信/支付寶/百度/頭條小程序

使用React生態(tài)開發(fā)小程序

三國群英傳現在只剩AngularJS缺席了。

Taro的亮點主要在于可以多端編譯，但問題恰恰是在這個多端編譯上。雖然微信小程序和支付寶小程序的組件在語法層面上差別不大，但要同時完美支持這么多端簡直不敢想象。

組件也許可以完美編譯，但很多開發(fā)者忽略了一個事實，小程序中除了有組件，還有API，每個不同小程序的API差異其實是極大的，這難免需要在編譯后進行大量的手動調整。

另外一點是，有多少人是真的需要開發(fā)這么多端的小程序？充其量最多就是雙端：微信和支付寶。你確定用Taro開發(fā)一套代碼的成本要比用微信小程序寫一套，然后復制黏貼改改代碼要低嗎？

Mpx

GitHub Stars：800 +

滴滴出品。滴滴是非常聰明的，Mpx誕生較晚，所以他走的路線和Taro、Mpvue不太一樣。

Taro和Mpvue屬于編譯型框架，完全使用React和Vue的生態(tài)開發(fā)。但Mpx不同，他很聰明的把Mpx定位成小程序的語法增強框架。換句話來講，還是以原生小程序開發(fā)為主，但你可以使用Vue的一些高級特性。

很聰明的做法。一是因為Mpvue在前，Mpx走同樣的路線沒有亮點；二是因為想去做到完美的的Vue編譯小程序這要付出極高的維護成本，還不一定能完美解決。

以下摘自Mpx文檔：

我們使用Vue中優(yōu)秀的語法特性增強了小程序，而不是讓用戶直接使用vue語法來開發(fā)小程序，之所以采用這種設計主要是基于如下考慮：
轉譯型框架無法支持源框架的所有語法特性(如Vue模板中的動態(tài)特性或React中動態(tài)生成的jsx)，用戶在使用源框架語法進行開發(fā)時可能會遇到不可預期的錯誤，具有不確定性
小程序本身的技術規(guī)范在不斷地更新進步，許多新的技術規(guī)范在轉譯型框架中無法支持或需要很高的支持成本，而對于增強型框架來說只要新的技術規(guī)范不與增強特性沖突，就能夠直接支持很清醒的團隊，目前其他的幾個框架對于小程序新特性的支持根本跟不上官方的更新速度。

我的觀點

談人生，談情懷，我覺得過程很重要。但對于工作，我只以結果為導向。我從來對任何技術沒有什么偏見，但我唯一珍惜的是我的時間。如果能用原生開發(fā)解決的問題，我絕對不會花成本去學習第三方框架。如果能用Python解決的問題，我100%不會用Java來寫。

第三方框架的存在是有價值的，它確實解決了不少人的需求，但我不建議大家盲從。如果一個框架你根本不知道你為什么用它，那還是用原生吧，最省心的選擇。

同學們也不要忽略了這個一點：用第三方框架就完全不需要學習原生小程序嗎？這當然是不可能的，正是因為用了第三方框架，你反而要更加精通原生小程序的開發(fā)。不然你怎么解決各個第三方框架的”坑“？沒有哪個框架能100%保證完美轉譯成小程序的。至少最近團隊在處理LinUI的時候就發(fā)現，很多框架都宣傳支持小程序的自定義組件，然而我們用第三方測試的結果是，這些框架根本無法編譯小程序的WXS。

那到底用什么開發(fā)小程序？這是個難題，一個永恒的迷。你用什么技術方案開發(fā)小程序？一起留言聊聊吧。

LinUI小程序組件庫：

https://github.com/TaleLin/lin-ui?github.com

LinCMS開源解決方案：

TaleLin/lin-cms-vue?github.com

愛我，請關注我的公眾號：

總結

以上是生活随笔為你收集整理的在react里写原生js_小程序原生开发与第三方框架选择的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。