整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
今出現(xiàn)了大量的CSS前端框架，但真正優(yōu)秀的框架只有少數(shù)幾個(gè)。
本文將會(huì)比較其中五個(gè)最佳的框架。每個(gè)框架都有自己的優(yōu)點(diǎn)和缺點(diǎn)，以及具體的應(yīng)用領(lǐng)域，你可以根據(jù)自己的具體項(xiàng)目需求進(jìn)行選擇。此外，許多選項(xiàng)都是模塊化的，允許你僅使用所需的組件，甚至可以混合使用來(lái)自不同框架的組件。
本文依據(jù)各個(gè)框架的GitHub流行度來(lái)順序介紹。
Foundation
Foundation是排在第二名的框架。ZURB這樣堅(jiān)實(shí)的公司一直支持著Foundation，所以這個(gè)框架有強(qiáng)大的基礎(chǔ)。Foundation現(xiàn)已用于許多大型網(wǎng)站，包括Facebook，Mozilla，Ebay，Yahoo！和國(guó)家地理等。
Foundation說明
Foundation是一個(gè)真正的專業(yè)框架，提供業(yè)務(wù)支持、培訓(xùn)和咨詢。它還提供了許多資源來(lái)幫助你更快更輕松地學(xué)習(xí)和使用該框架。
Semantic UI
Semantic UI是一個(gè)語(yǔ)義化設(shè)計(jì)的前端開源框架。它利用自然語(yǔ)言原理，從而使代碼更加可讀和可理解。
Semantic UI說明
Semantic是這里所討論的所有框架中，最具創(chuàng)新性和全功能的框架。其框架的總體結(jié)構(gòu)、類中清晰邏輯的命名約定方式和語(yǔ)義方面也超過了其它框架。
Bootstrap
Bootstrap是目前可用框架中無(wú)可爭(zhēng)議的領(lǐng)導(dǎo)者。其人氣日益增長(zhǎng)，你可以放心的選擇這個(gè)框架，而不必?fù)?dān)心項(xiàng)目會(huì)失敗，因?yàn)榫哂袕V泛使用基礎(chǔ)的框架，不太可能被拋棄。
Bootstrap說明
Bootstrap的廣泛流行是它的優(yōu)勢(shì)所在。在技術(shù)上，它不一定比列表中的其它框架更好，但它提供了比其它四個(gè)框架更多的資源（文章和教程、第三方插件和擴(kuò)展、主題構(gòu)建器等）。簡(jiǎn)而言之，Bootstrap 無(wú)處不在，這是人們繼續(xù)選擇的主要原因。
Pure
Pure是一種輕量級(jí)的模塊化框架，采用純CSS編寫，具有可根據(jù)需要一起使用或單獨(dú)使用的組件。
Pure說明
Pure為你的項(xiàng)目提供了一個(gè)干凈的開始，只提供基本框架。對(duì)于不需要全功能框架但僅包含在其工作中的特定組件的人來(lái)說，pures是一個(gè)理想的選擇。
UIkit
UIkit是一個(gè)易于使用和自定義的組件的簡(jiǎn)潔集合。雖然它不像其它框架那樣受歡迎，但它提供了相同的功能和質(zhì)量。
UIkit說明
UIkit成功應(yīng)用在許多WordPress主題中。它提供了靈活和強(qiáng)大的手動(dòng)定制機(jī)制（以前版本的框架還提供了高級(jí)GUI定制程序）。
什么是最適合你的框架？
在選擇框架時(shí)，可以從以下幾個(gè)方面考慮：
如果你還不確定使用哪個(gè)框架，那么可以采用混合搭配的方式。當(dāng)某個(gè)特定的框架不能滿足你的需求時(shí)，可以混合使用兩個(gè)或多個(gè)項(xiàng)目的組件。
最后值得一提的是，現(xiàn)在Flexbox和Grid Layout在主流瀏覽器的最新版本中得到很好的支持，比以往任何時(shí)候都更容易構(gòu)建復(fù)雜的布局。這可能會(huì)鼓勵(lì)更多的開發(fā)人員放棄前端框架，從頭開始編寫他們自己想要的布局。
原文地址：https://zhuanlan.zhihu.com/p/39837067
近前端屆多端框架頻出，相信很多有代碼多端運(yùn)行需求的開發(fā)者都會(huì)產(chǎn)生一些疑惑：這些框架都有什么優(yōu)缺點(diǎn)？到底應(yīng)該用哪個(gè)？
作為 Taro 開發(fā)團(tuán)隊(duì)一員，筆者想在本文盡量站在一個(gè)客觀公正的角度去評(píng)價(jià)各個(gè)框架的選型和優(yōu)劣。但宥于利益相關(guān)，本文的觀點(diǎn)很可能是帶有偏向性的，大家可以帶著批判的眼光去看待，權(quán)當(dāng)拋磚引玉。
那么，當(dāng)我們?cè)谟懻摱喽丝蚣軙r(shí)，我們?cè)谡務(wù)撌裁矗?/p>
多端
筆者以為，現(xiàn)在流行的多端框架可以大致分為三類：
1. 全包型
這類框架最大的特點(diǎn)就是從底層的渲染引擎、布局引擎，到中層的 DSL，再到上層的框架全部由自己開發(fā)，代表框架是 Qt 和 Flutter。這類框架優(yōu)點(diǎn)非常明顯：性能（的上限）高；各平臺(tái)渲染結(jié)果一致。缺點(diǎn)也非常明顯：需要完全重新學(xué)習(xí) DSL（QML/Dart），以及難以適配中國(guó)特色的端：小程序。
這類框架是最原始也是最純正的的多端開發(fā)框架，由于底層到上層每個(gè)環(huán)節(jié)都掌握在自己手里，也能最大可能地去保證開發(fā)和跨端體驗(yàn)一致。但它們的框架研發(fā)成本巨大，渲染引擎、布局引擎、DSL、上層框架每個(gè)部分都需要大量人力開發(fā)維護(hù)。
2. Web 技術(shù)型
這類框架把 Web 技術(shù)（JavaScript，CSS）帶到移動(dòng)開發(fā)中，自研布局引擎處理 CSS，使用 JavaScript 寫業(yè)務(wù)邏輯，使用流行的前端框架作為 DSL，各端分別使用各自的原生組件渲染。代表框架是 React Native 和 Weex，這樣做的優(yōu)點(diǎn)有：
缺點(diǎn)有：
1. 交互復(fù)雜時(shí)難以寫出高性能的代碼，這類框架的設(shè)計(jì)就必然導(dǎo)致 JS 和 Native 之間需要通信，類似于手勢(shì)操作這樣頻繁地觸發(fā)通信就很可能使得 UI 無(wú)法在 16ms 內(nèi)及時(shí)繪制。React Native 有一些聲明式的組件可以避免這個(gè)問題，但聲明式的寫法很難滿足復(fù)雜交互的需求。
2. 由于沒有渲染引擎，使用各端的原生組件渲染，相同代碼渲染的一致性沒有第一種高。
3. JavaScript 編譯型
這類框架就是我們這篇文章的主角們：Taro、WePY 、uni-app 、 mpvue 、 chameleon，它們的原理也都大同小異：先以 JavaScript 作為基礎(chǔ)選定一個(gè) DSL 框架，以這個(gè) DSL 框架為標(biāo)準(zhǔn)在各端分別編譯為不同的代碼，各端分別有一個(gè)運(yùn)行時(shí)框架或兼容組件庫(kù)保證代碼正確運(yùn)行。
這類框架最大優(yōu)點(diǎn)和創(chuàng)造的最大原因就是小程序，因?yàn)榈谝坏诙N框架其實(shí)除了可以跨系統(tǒng)平臺(tái)之外，也都能編譯運(yùn)行在瀏覽器中。(Qt 有 Qt for WebAssembly, Flutter 有 Hummingbird，React Native 有 react-native-web, Weex 原生支持)
另外一個(gè)優(yōu)點(diǎn)是在移動(dòng)端一般會(huì)編譯到 React Native/Weex，所以它們也都擁有 Web 技術(shù)型框架的優(yōu)點(diǎn)。這看起來(lái)很美好，但實(shí)際上 React Native/Weex 的缺點(diǎn)編譯型框架也無(wú)法避免。除此之外，編譯型框架的抽象也不是免費(fèi)的：當(dāng) bug 出現(xiàn)時(shí)，問題的根源可能出在運(yùn)行時(shí)、編譯時(shí)、組件庫(kù)以及三者依賴的庫(kù)等等各個(gè)方面。在 Taro 開源的過程中，我們就遇到過 Babel 的 bug，React Native 的 bug，JavaScript 引擎的 bug，當(dāng)然也少不了 Taro 本身的 bug。相信其它原理相同的框架也無(wú)法避免這一問題。
但這并不意味著這類為了小程序而設(shè)計(jì)的多端框架就都不堪大用。首先現(xiàn)在各巨頭超級(jí) App 的小程序百花齊放，框架會(huì)為了抹平小程序做了許多工作，這些工作在大部分情況下是不需要開發(fā)者關(guān)心的。其次是許多業(yè)務(wù)類型并不需要復(fù)雜的邏輯和交互，沒那么容易觸發(fā)到框架底層依賴的 bug。
那么當(dāng)你的業(yè)務(wù)適合選擇編譯型框架時(shí)，在筆者看來(lái)首先要考慮的就是選擇 DSL 的起點(diǎn)。因?yàn)橛卸喽诵枨髽I(yè)務(wù)通常都希望能快速開發(fā)，一個(gè)能夠快速適應(yīng)團(tuán)隊(duì)開發(fā)節(jié)奏的 DSL 就至關(guān)重要。不管是 React 還是 Vue（或者類 Vue）都有它們的優(yōu)缺點(diǎn)，大家可以根據(jù)團(tuán)隊(duì)技術(shù)棧和偏好自行選擇。
如果不管什么 DSL 都能接受，那就可以進(jìn)入下一個(gè)環(huán)節(jié)。
生態(tài)
以下內(nèi)容均以各框架現(xiàn)在（2019 年 3 月 11 日）已發(fā)布穩(wěn)定版為標(biāo)準(zhǔn)進(jìn)行討論。
開發(fā)工具
就開發(fā)工具而言 uni-app 應(yīng)該是一騎絕塵，它的文檔內(nèi)容最為翔實(shí)豐富，還自帶了 IDE 圖形化開發(fā)工具，鼠標(biāo)點(diǎn)點(diǎn)點(diǎn)就能編譯測(cè)試發(fā)布。
其它的框架都是使用 CLI 命令行工具，但值得注意的是 chameleon 有獨(dú)立的語(yǔ)法檢查工具，Taro 則單獨(dú)寫了 ESLint 規(guī)則和規(guī)則集。
在語(yǔ)法支持方面，mpvue、uni-app、Taro 、WePY 均支持 TypeScript，四者也都能通過 typing 實(shí)現(xiàn)編輯器自動(dòng)補(bǔ)全。除了 API 補(bǔ)全之外，得益于 TypeScript 對(duì)于 JSX 的良好支持，Taro 也能對(duì)組件進(jìn)行自動(dòng)補(bǔ)全。
CSS 方面，所有框架均支持 SASS、LESS、Stylus，Taro 則多一個(gè) CSS Modules 的支持。
所以這一輪比拼的結(jié)果應(yīng)該是：
uni-app > Taro > chameleon > WePY、mpvue
多端支持度
只從支持端的數(shù)量來(lái)看，Taro 和 uni-app 以六端略微領(lǐng)先（移動(dòng)端、H5、微信小程序、百度小程序、支付寶小程序、頭條小程序），chameleon 少了頭條小程序緊隨其后。
但值得一提的是 chameleon 有一套自研多態(tài)協(xié)議，編寫多端代碼的體驗(yàn)會(huì)好許多，可以說是一個(gè)能戳到多端開發(fā)痛點(diǎn)的功能。uni-app 則有一套獨(dú)立的條件編譯語(yǔ)法，這套語(yǔ)法能同時(shí)作用于 js、樣式和模板文件。Taro 可以在業(yè)務(wù)邏輯中根據(jù)環(huán)境變量使用條件編譯，也可以直接使用條件編譯文件（類似 React Native 的方式）。
在移動(dòng)端方面，uni-app 基于 weex 定制了一套 nvue 方案 彌補(bǔ) weex API 的不足；Taro 則是暫時(shí)基于 expo 達(dá)到同樣的效果；chameleon 在移動(dòng)端則有一套 SDK 配合多端協(xié)議與原生語(yǔ)言通信。
H5 方面，chameleon 同樣是由多態(tài)協(xié)議實(shí)現(xiàn)支持，uni-app 和 Taro 則是都在 H5 實(shí)現(xiàn)了一套兼容的組件庫(kù)和 API。
mpvue 和 WePY 都提供了轉(zhuǎn)換各端小程序的功能，但都沒有 h5 和移動(dòng)端的支持。
所以最后一輪對(duì)比的結(jié)果是：
chameleon > Taro、uni-app > mpvue > WePY
組件庫(kù) / 工具庫(kù) /demo
作為開源時(shí)間最長(zhǎng)的框架，WePY 不管從 Demo，組件庫(kù)數(shù)量 ，工具庫(kù)來(lái)看都占有一定優(yōu)勢(shì)。
uni-app 則有自己的插件市場(chǎng)和 UI 庫(kù)，如果算上收費(fèi)的框架和插件比起 WePy 也是完全不遑多讓的。
Taro 也有官方維護(hù)的跨端 UI 庫(kù) taro-ui ，另外在狀態(tài)管理工具上也有非常豐富的選擇（Redux、MobX、dva），但 demo 的數(shù)量不如前兩個(gè)。但 Taro 有一個(gè)轉(zhuǎn)換微信小程序代碼為 Taro 代碼的工具，可以彌補(bǔ)這一問題。
而 mpvue 沒有官方維護(hù)的 UI 庫(kù)，chameleon 第三方的 demo 和工具庫(kù)也還基本沒有。
所以這輪的排序是：
WePY > uni-app 、taro > mpvue > chameleon
接入成本
接入成本有兩個(gè)方面：
第一是框架接入原有微信小程序生態(tài)。由于目前微信小程序已呈一家獨(dú)大之勢(shì)，開源的組件和庫(kù)（例如 wxparse、echart、zan-ui 等）多是基于原生微信小程序框架語(yǔ)法寫成的。目前看來(lái) uni-app 、Taro、mpvue 均有文檔或 demo 在框架中直接使用原生小程序組件 / 庫(kù)，WePY 由于運(yùn)行機(jī)制的問題，很多情況需要小改一下目標(biāo)庫(kù)的源碼，chameleon 則是提供了一個(gè)按步驟大改目標(biāo)庫(kù)源碼的遷移方式。
第二是原有微信小程序項(xiàng)目部分接入框架重構(gòu)。在這個(gè)方面 Taro 在京東購(gòu)物小程序上進(jìn)行了大膽的實(shí)踐，具體可以查看文章《Taro 在京東購(gòu)物小程序上的實(shí)踐》。其它框架則沒有提到相關(guān)內(nèi)容。
而對(duì)于兩種接入方式 Taro 都提供了 taro convert 功能，既可以將原有微信小程序項(xiàng)目轉(zhuǎn)換為 Taro 多端代碼，也可以將微信小程序生態(tài)的組件轉(zhuǎn)換為 Taro 組件。
所以這輪的排序是：
Taro > mpvue 、 uni-app > WePY > chameleon
流行度
從 GitHub 的 star 來(lái)看，mpvue 、Taro、WePY 的差距非常小。從 NPM 和 CNPM 的 CLI 工具下載量來(lái)看，是 Taro（3k/week）> mpvue (2k/w) > WePY (1k/w)。但發(fā)布時(shí)間也剛好反過來(lái)。筆者估計(jì)三家的流行程度和案例都差不太多。
uni-app 則號(hào)稱有上萬(wàn)案例，但不像其它框架一樣有一些大廠應(yīng)用案例。另外從開發(fā)者的數(shù)量來(lái)看也是 uni-app 領(lǐng)先，它擁有 20+ 個(gè) QQ 交流群（最大人數(shù) 2000）。
所以從流行程度來(lái)看應(yīng)該是：
uni-app > Taro、WePY、mpvue > chameleon
開源建設(shè)
一個(gè)開源作品能走多遠(yuǎn)是由框架維護(hù)團(tuán)隊(duì)和第三方開發(fā)者共同決定的。雖然開源建設(shè)不能具體地量化，但依然是衡量一個(gè)框架 / 庫(kù)生命力的非常重要的標(biāo)準(zhǔn)。
從第三方貢獻(xiàn)者數(shù)量來(lái)看，Taro 在這一方面領(lǐng)先，并且 Taro 的一些核心包 / 功能（MobX、CSS Modules、alias）也是由第三方開發(fā)者貢獻(xiàn)的。除此之外，騰訊開源的 omi 框架小程序部分也是基于 Taro 完成的。
WePY 在騰訊開源計(jì)劃的加持下在這一方面也有不錯(cuò)的表現(xiàn)；mpvue 由于停滯開發(fā)了很久就比較落后了；可能是產(chǎn)品策略的原因，uni-app 在開源建設(shè)上并不熱心，甚至有些部分代碼都沒有開源；chameleon 剛剛開源不久，但它的代碼和測(cè)試用例都非常規(guī)范，以后或許會(huì)有不錯(cuò)的表現(xiàn)。
那么這一輪的對(duì)比結(jié)果是：
Taro > WePY > mpvue > chameleon > uni-app
最后補(bǔ)一個(gè)總的生態(tài)對(duì)比圖表：
未來(lái)
從各框架已經(jīng)公布的規(guī)劃來(lái)看：
WePY 已經(jīng)發(fā)布了 v2.0.alpha 版本，雖然沒有公開的文檔可以查閱到 2.0 版本有什么新功能 / 特性，但據(jù)其作者介紹，WePY 2.0 會(huì)放大招，是一個(gè)「對(duì)得起開發(fā)者」的版本。筆者也非常期待 2.0 正式發(fā)布后 WePY 的表現(xiàn)。
mpvue 已經(jīng)發(fā)布了 2.0 的版本，主要是更新了其它端小程序的支持。但從代碼提交， issue 的回復(fù) / 解決率來(lái)看，mpvue 要想在未來(lái)有作為首先要打消社區(qū)對(duì)于 mpvue 不管不顧不更新的質(zhì)疑。
uni-app 已經(jīng)在生態(tài)上建設(shè)得很好了，應(yīng)該會(huì)在此基礎(chǔ)之上繼續(xù)穩(wěn)步發(fā)展。如果 uni-app 能加強(qiáng)開源開放，再加強(qiáng)與大廠的合作，相信未來(lái)還能更上一層樓。
chameleon 的規(guī)劃比較宏大，雖然是最后發(fā)的框架，但已經(jīng)在規(guī)劃或正在實(shí)現(xiàn)的功能有：
如果 chameleon 把這些功能都做出來(lái)的話，再繼續(xù)完善生態(tài)，爭(zhēng)取更多第三方開發(fā)者，那么在未來(lái) chameleon 將大有可為。
Taro 的未來(lái)也一樣值得憧憬。Taro 即將要發(fā)布的 1.3 版本就會(huì)支持以下功能：
同時(shí) Taro 也正在對(duì)移動(dòng)端進(jìn)行大規(guī)模重構(gòu)；開發(fā)圖形化開發(fā)工具；開發(fā)組件 / 物料平臺(tái)以及圖形化頁(yè)面搭建工具。
結(jié)語(yǔ)
那說了那么多，到底用哪個(gè)呢？
如果不介意嘗鮮和學(xué)習(xí) DSL 的話，完全可以嘗試 WePY 2.0 和 chameleon ，一個(gè)是醞釀了很久的 2.0 全新升級(jí)，一個(gè)有專門針對(duì)多端開發(fā)的多態(tài)協(xié)議。
uni-app 和 Taro 相比起來(lái)就更像是「水桶型」框架，從工具、UI 庫(kù)，開發(fā)體驗(yàn)、多端支持等各方面來(lái)看都沒有明顯的短板。而 mpvue 由于開發(fā)一度停滯，現(xiàn)在看來(lái)各個(gè)方面都不如在小程序端基于它的 uni-app 。
(本文章轉(zhuǎn)載自infoq, 如有侵權(quán), 請(qǐng)聯(lián)系作者刪除)
于web前端三大框架，一直以來(lái)是廣大前端開發(fā)者口水戰(zhàn)必爭(zhēng)話題。那么阿多比設(shè)計(jì)學(xué)院的小編也來(lái)趟一趟這渾水，僅僅是小編的個(gè)人一點(diǎn)小的看法，輕噴哦~
之所以web前端框架這個(gè)話題熱度那么高，很大程度上是因?yàn)槭鼙姳姸?。這一點(diǎn)我要解釋給前端小白聽一下，雖然你在剛開始學(xué)習(xí)的時(shí)候往往是從HTML，CSS，JS學(xué)起的，但是一個(gè)完整的課程最后肯定是少不了web框架的。因?yàn)樽詈笤趯?shí)際工作的時(shí)候，一般都是在框架上搭建網(wǎng)站的，是不會(huì)真的從底層開始寫代碼的。
因此框架作為項(xiàng)目接近100%利用率的好工具，也是網(wǎng)站的基礎(chǔ)，他的好壞也就顯得尤為重要了。說到這里大家應(yīng)該能夠明白，大家嘴里的三大框架，肯定是平分秋色，各有優(yōu)劣的。不然這樣激烈的市場(chǎng)，一無(wú)是處的框架一早就被淘汰了。
下面給大家具體分析一下這三個(gè)前端框架：
1. Angular
大家眼里比較“叼”的框架，甚至有人說三大框架中只有她能稱的上一個(gè)完整的框架，因?yàn)樗臇|西比較完善，包含模板，數(shù)據(jù)雙向綁定，路由，模塊化，服務(wù)，過濾器，依賴注入等所有功能。對(duì)于剛開始學(xué)習(xí)使用框架的小伙伴們，可以推薦這個(gè)框架，學(xué)會(huì)之后簡(jiǎn)直能顛覆之前你對(duì)前端開發(fā)的認(rèn)知。使用 TypeScript能夠提高代碼可維護(hù)性，有利于后期重構(gòu)。雙向數(shù)據(jù)流很方便，但是等業(yè)務(wù)復(fù)雜之后，你可能就搞不清楚數(shù)據(jù)流了。還有令人不開心的臟值檢查，以及directive的封裝并沒有解決視圖與數(shù)據(jù)關(guān)系完全分離，有時(shí)候還要用$digist強(qiáng)制觸發(fā)檢測(cè)。
2.React
這個(gè)框架本身比較容易理解，他的結(jié)構(gòu)很清晰，就是由十幾個(gè)API組成，然后異步渲染，我們只需要處理好接口和維護(hù)就好了，但是很多人反映上手還是有一定的的難度的。React是單向數(shù)據(jù)流，代碼寫起來(lái)會(huì)較雙向數(shù)據(jù)流的多一些，但是同樣的排查問題時(shí)思路清晰很多。
3.Vue
號(hào)稱是最簡(jiǎn)單，最容易上手的框架，同時(shí)也是行內(nèi)的大趨勢(shì)，還可以用來(lái)開發(fā)最火的小程序。畢竟用這神器，代碼碼的飛快，項(xiàng)目也能快速上線。同時(shí)他也是雙向數(shù)據(jù)流。有些人認(rèn)為Vue是Angular和React的結(jié)合，既有Angular的模板語(yǔ)法也有React的組件化體系。
當(dāng)你學(xué)會(huì)其中某個(gè)框架之后，你再轉(zhuǎn)用其他框架的時(shí)候，學(xué)會(huì)是很容易的，因?yàn)榉椒ǘ际谴笸‘惖摹＞唧w的使用還是得看公司的項(xiàng)目適合或者要求哪個(gè)框架。之前阿多比設(shè)計(jì)學(xué)院的小編再網(wǎng)上暗訪了一下，看看有沒有人這三個(gè)框架都十分精通的，但是很遺憾的發(fā)現(xiàn)，都用過的人不少，但是真正敢說精通的還是沒有。這些框架學(xué)會(huì)使用還比較容易，但是里面的“水太深”，精通還需長(zhǎng)久的時(shí)間，望大家共勉，一起學(xué)習(xí)進(jìn)步呀!
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
