摘要：讓人又愛又恨的微信小程序自微信小程序以下簡稱小程序誕生以來，就伴隨著贊譽與爭議不斷。同時于開發者來說，小程序的生態不斷在完善，許多的坑已被踩平，雖然還是存在一些令人詬病的問題，但已經足見微信的誠意了。

在互聯網不斷發展的今天，前端程序員們也不斷面臨著新的挑戰，在這個變化多端、不斷革新自己的領域，每一年都有新的美好事物在發生。從去年微信小程序的誕生，到今年的逐漸火熱，以及異軍突起的輕應用、百度小程序等的出現，前端可以延伸的領域已經越來越廣，當然也意味著業務在不斷擴大。這時候，如何通過技術手段來提升開發效率，應對不斷增長的業務，京東前端凹凸實驗室開源多 Taro 就此誕生。

自 2017-1-9 微信小程序（以下簡稱小程序）誕生以來，就伴隨著贊譽與爭議不斷。從發布上線時的不被大多數人看好，到如今的逐漸火熱，甚至說是如日中天也不為過，小程序用時間與實踐證明了自己的價值。同時于開發者來說，小程序的生態不斷在完善，許多的坑已被踩平，雖然還是存在一些令人詬病的問題，但已經足見微信的誠意了。這個時候要是還沒有上手把玩過小程序，就顯得非常OUT了。

小程序對于前端程序員來說應該算得上是福音了，用前端相關的技術，獲得絲般順滑的 Native 體驗。小程序給前端程序員打開了一扇新的大門，大家都應該感謝微信，但是從開發的角度來說，小程序的開發體驗就非常值得商榷了，不僅語法上顯得有些不倫不類，而且有些莫名其妙的坑也經常讓人不經意間感嘆，從市面上層出不窮的小程序開發框架就可見一斑。以下就盤點部分小程序開發的痛點。

在小程序中，一個頁面 page 可能擁有 page.js、page.wxss、page.wxml 、page.json 四個文件

這樣在開發的時候就需要來回進行文件切換，尤其是在同時開發模板和邏輯的時候，切來切去會顯得尤其麻煩，影響開發效率。

而在語法上，小程序的語法可以說既像 React ，又像 Vue，不能說顯得有點不倫不類，但在使用上總是感覺有些別扭，對于開發者來說，等于又要學習一套新的語法，提升了學習成本。而且，小程序的模板由于沒有編輯器插件的支持，書寫的時候也沒有智能提示與 lint 檢查，書寫起來顯得有些麻煩。

在小程序中到處可見規范不統一的情況

例如組件的屬性，以最簡單的 button 組件為例，在小程序官方文檔中，該組件的屬性部分截圖如下

button 組件

屬性名既有以中劃線分割多個單詞的情況 session-form，也有多個單詞連寫的情況 bindgetphonenumber。當然這也不是最嚴重的，你可以說事件綁定的規范就是 bind + 事件名 ，而其他屬性的規范就是中劃線分割單詞，然而這并不是作為標準

progress 組件

這不統一的標準使得開發者體驗極其難受。

同樣的情況也出現在 頁面 與 組件 的生命周期方法中，頁面 的生命周期方法有 onLoad、onReady、onUnload 等，但到了 組件 中則是 created、attached 、ready 等，這樣規范又不統一了，為啥 頁面 的生命周期方法是 on+Xxx 的格式，但到了 組件 里卻不一樣了呢，讓人費解。

小程序官方提供了 微信開發工具 作為開發編譯工具，而對于代碼本身沒有提供一個類似 webpack 的工程化開發工具，來解決開發中的一些問題，所以小程序原生的開發方式顯得不那么現代化，這也是很多小程序開發框架致力于解決的問題。例如，在小程序開發中

不能使用 npm 管理依賴，在小程序中需要手動把第三方代碼文件下載到本地，然后再 reuqire 進行使用，顯得不那么優雅

不能使用 Sass 等 CSS 預處理器，由于沒有預編譯的概念，小程序開發中無法使用市面上流行的 CSS 預處理器，這樣會使得樣式代碼難以管理

不完整的 ES Next 語法支持，小程序默認只能支持極少一部分 ES6 規范的語法，而 ES 是不斷往前發展的，一些非常優秀的新語法特性就不能使用了

手動的文件處理，像圖片壓縮、代碼壓縮等等的一些文件操作，必須手工來處理，顯得有些繁瑣

以上就是從開發者的角度看到的一些小程序的開發問題，不過縱然有千般困難，我們總要面對，作為新時代的前端開發工程師，我們不能一味忍受問題，要保持技術的頭腦，以技術作為武器，用技術手段去提升的我們開發體驗。

目前前端界言及前端框架，必離不開依然保持著統治地位的 React 與 Vue，這兩個都是非常優秀的前端 UI 框架，而且在網上也經常能看到兩個框架的粉絲之間熱情交流，碰撞出一些思想火花，顯得社區異常活躍。

而我們團隊也在去年勇敢地拋棄了歷史包袱，非常榮幸地引入了 React 開發方式，讓我們團隊丟掉了煤油燈，開始通上了電。而且也研發出了一款優秀的類 React 框架 Nerv ，讓我們和 React 開發思想結合得更深。

與小程序的開發方式相比，React 明顯顯得更加現代化、規范化，而且 React 天生組件化更適合我們的業務開發，JSX 也比字符串模板有更強的表現力。那么這時候我們就在思考，我們能不能用 React 來寫小程序？

理性地探索

類比

通過對比體驗 小程序和 React ，我們還是能發現兩者之間相似的地方

生命周期

小程序的生命周期和 React 的生命周期，在很大程度上是類似的，我們甚至能找到他們之間的對應關系
app 及頁面的生命周期

可以看出，對于 app 及 頁面 來說，除了 onShow 與 onHide 兩個方法，其他方法都能在 React 中找到對應。

數據更新方式

在 React 中，組件的內部數據是用 state 來進行管理的，而在小程序中組件的內部數據都是用 data 來進行管理，兩者具有一定相似性。而同時在 React 中，我們更新數據使用的是 setState 方法，傳入新的數據或者生成新數據的函數，從而更新相應視圖。在小程序中，則對應的有 setData 方法，傳入新的數據，從而更新視圖。
兩者都是以數據驅動視圖的方式進行更新，而且 api 神似。

事件綁定

小程序中綁定事件使用的是 bind + 事件名 的方式，例如點擊事件，小程序中是 bindtap

1

而在 React 里，則是 on + 事件名 的方式，例如點擊事件， React web 中是 onClick

1

雖然看上去不一樣，但其實是可以類比的，我們只需要在編譯時將 on + 事件名 的形式編譯成 bind + 事件名 的形式就可以了。

如此看來，兩者之間有些相似，用 React 來寫小程序貌似是可行的，但接下來我們就發現了巨大的差異。

React 與小程序之間最大的差異就是他們的模板了，在 React 中，是使用 JSX 來作為組件的模板的，而小程序則與 Vue 一樣，是使用字符串模板的。這樣兩者之間就有著巨大的差異了。

JSX

render () {
  return (
    
      {this.state.list.map((item, idx) => (
        {item}
      ))}
      走你
    
  )
}

小程序模板

   {{item}}
   走你
 

眾所周知，JSX 其實本質上就是 JS，我們可以在里面寫任意的邏輯代碼，這樣一來就比字符串模板的表現力與操作性要強多了，況且，小程序的字符串模板功能比較羸弱，只有一些比較基本的功能。那這樣的話，要如何來實現用 JSX 來寫小程序模板呢。

我們可以仔細來分析我們的需求，我們期望使用 JSX 來書寫小程序模板，但小程序顯然是不支持執行 JSX 代碼的（要是支持的話，Taro 應該也就不存在了吧），我們也不能期望微信能給我們開個后門來跑 JSX。那么這個時候我們就想，我們要是能夠將 JSX 編譯成小程序模板就好了。

事實上在我們平時的開發中，這種編譯的操作到處可見，babel 就是我們最常用的 JS 代碼編譯器，一般瀏覽器是不能支持一些非常新的語法特性的，但我們又想使用它們，這個時候就可以借助 babel 來將我們的高版本的 ES 代碼，編譯成瀏覽器可以運行的 ES 代碼。而我們像要將 JSX 編譯成小程序模板，也是同樣的道理。我們首先來了解一下 Babel 的運行機制。

Babel 作為一個 代碼編譯器 ，能夠將 ES6/7/8 的代碼編譯成 ES5 的代碼，其核心利用的就是計算中非常基礎的編譯原理知識，將輸入語言代碼，通過編譯器執行，輸出目標語言的代碼。編譯原理的一般過程就是，輸入源程序，經過詞法分析、語法分析，構造出語法樹，再經過語義分析，理解程序正確與否，再對語法樹做出需要的操作與優化，最終生成目標代碼。

Babel 的編譯過程亦是如此，主要包含三個階段

解析過程，在這個過程中進行詞法、語法分析，以及語義分析，生成符合 ESTree 標準 虛擬語法樹 AST

轉換過程，針對 AST 做出已定義好的操作，babel 的配置文件 .babelrc 中定義的 preset 、 plugin 就是在這一步中執行并改變 AST 的

生成過程，將前一步轉換好的 AST 生成目標代碼的字符串

為了更好地理解這些過程，大家可以利用 Ast Explorer 這個網站接一下自己的代碼，感受一下每一部分代碼所對應的 AST 結構。

可以看到，一份源碼經過編譯器解析后，會變成類似如下的結構

{
  type: "Program",
  start: 0,
  end: 78,
  loc: { start, end }
  sourceType: "module",
  body: [
    { type: "VariableDeclaration", ... },
    { type: "VariableDeclaration", ... },
    { type: "FunctionDeclaration", ... },
    { type: "ExpressionStatement", ... }
  ]
  ...
}

其中，body 里包含的就是我們示例代碼的語法樹結構，第一個 VariableDeclaration 對應的是 const a = 1，第三個 FunctionDeclaration 對應的則是 function sum (a, b) { }，分別就是 JS 中的變量定義與函數定義，每一個樹節點里都會包含許多子節點，這樣就形成了一個樹形結構，更多的節點類型，請參考 babel types。
當然我們在這兒只是簡單介紹下編譯原理與 babel，編譯原理是一門非常深奧的課程， babel 也是一個非常優秀的工具，希望在后續的文章中能和大家再詳細探討這一部分內容。
再次回到我們的需求，將 JSX 編譯成小程序模板，非常幸運的是 babel 的核心編譯器 babylon 是支持對 JSX 語法的解析的，我們可以直接利用它來幫我們構造 AST，而我們需要專注的核心就是如何對 AST 進行轉換操作，得出我們需要的新 AST，再將新 AST 進行遞歸遍歷，生成小程序的模板。

JSX 代碼

  +
  -
  async
  {this.props.counter.num}
  
  走你
  

  
    +
    -
    async
    {{counter.num}}
    
    走你