2017 年 1 月 9 日凌晨，萬眾期待的微信小程式正式上線，前有跳一跳等爆圈小遊戲的帶動，後有特殊時期下各類健康碼小程式的加持，小程式成為了國內技術圈獨樹一幟的存在。但隨著小程式的迅猛發展，其實在小程式發展的過程中，關於小程式的架構就層出不窮，小程式架構的後面也會繫結一個專屬 DSL，如類 React 或者類 Vue。

這其中，又有一個受到廣大開發者認可和開源的框架，不用過多的介紹，可能大部分都知道這個就是 Taro 。

關於 Taro

Taro 是一個開放式跨端跨框架解決方案，支援使用 React/Vue/Nerv 等框架來開發微信 / 京東 / 百度 / 支付寶 / 位元組跳動 / QQ / 飛書/ FinClip 小程式 / H5 / RN 等應用。

現如今市面上端的形態多種多樣，Web、React Native、微信小程式等各種端大行其道。當業務要求同時在不同的端都要求有所表現的時候，針對不同的端去編寫多套程式碼的成本顯然非常高，這時候只編寫一套程式碼就能夠適配到多端的能力就顯得極為需要。

在非常強調效率的時代下，Taro 3 可以支援轉換到 H5、ReactNative 以及任意小程式平臺，就可以大大的避免在多個平臺重複的進行開發。

如果再回溯的更深一些，我們可以參照京東官方的說法：

團隊人力資源捉襟見肘，與此同時，以上的業務都或多或少存在多端的需求，比如微信小程式、H5、React Native (京東的主流 APP 基本都內建了 React Native 渲染引擎)，而且可以預見的是，以後很有可能需要適配更多的小程式平臺，而每個端開發一套程式碼又不現實，會導致：研發成本上升，程式碼維護困難。

當時我們團隊自研了一款類 React 框架：Nervjs, 整個團隊的技術棧因此全部轉向了 React ，而當時市面上又沒有一款遵循 React 語法的小程式框架，因此，我們開發了 Taro，希望能夠使用 React 語法寫小程式的同時，通過「Write once Run anywhere」來實現跨端的。

Taro 的架構

小程式的架構都很清楚了，主要分為邏輯層是檢視層兩部分，邏輯層主要負責 JS 執行，檢視層主要負責頁面的渲染，它們之間主要通過 Event 和 Data 進行通訊，同時通過 JSBridge 呼叫原生的 API。

再來看看 Taro 的架構，Taro 當前的架構主要分為：編譯時和執行時。其中編譯時主要是將 Taro 程式碼通過 Babel 轉換成小程式的程式碼，如：JS、WXML、WXSS、JSON。執行時主要是進行一些：生命週期、事件、data 等部分的處理和對接。

歸納起來，整個 Taro 架構有三大特點：

重編譯時，輕執行時，這從程式碼行數的對比就可見一斑。
編譯後程式碼與 React 無關，Taro 只是在開發時遵循了 React 的語法。
直接使用 Babel 進行編譯，這也導致當前 Taro 在工程化和外掛方面的羸弱。

與其他框架的橫向對比

在這裡也不說哪個框架絕對的好用，由於本篇文章是專門針對 Taro 的介紹，所以我們就以官方的一些能力對比為參照進行分析。

直接先放一張總體能力的對比圖：

關於開發的支援

在語法支援方面，mpvue、uni-app、Taro 、WePY 均支援 TypeScript，四者也都能通過 typing 實現編輯器自動補全。除了 API 補全之外，得益於 TypeScript 對於 JSX 的良好支援，Taro 也能對元件進行自動補全。但在工具的支援上 uni-app 還是有較為明顯的優勢。

多端支援度

只從支援端的數量來看，Taro 和 uni-app 以六端略微領先（行動端、H5、微信小程式、百度小程式、支付寶小程式、抖音小程式），chameleon 少了抖音小程式緊隨其後。

但值得一提的是 chameleon 有一套自研多型協定，編寫多端程式碼的體驗會好許多，可以說是一個能戳到多端開發痛點的功能。

Taro 的價值

為什麼會說到這個呢？因為大部分的開發者只會講 Taro 用到小程式相關的開發當中，但其實我們還能將 Taro 開發的小程式放到自己的App中，充當或者代替原生/H5的部分，但要實現這一部分需要搭配藉助小程式容器進行實現。