如何挑選適合的前端框架

來源於:https://github.com/RubyLouvre/agate/issues/8

 

 

最近幾年，前端技術迅猛發展，差很少每一年都會冒出一款主流的框架。 每次新開業務線或啓動新項目時，是第一件事就是糾結：使用什麼框架，重造什麼輪子？我很高興應CSDN的邀請談個人見解。

在五六年，移動端尚未興起，咱們沒有什麼選擇，就是jQuery。有人會說，jQuery只是類庫，不是框架;但那時前端業務尚未像今天這麼繁重，本來是後端乾的事，所有挪到前端來，由於光是jQuery就能夠包打天下。jQuery不夠用，還有成千上萬的jQuery的插件呢。因而問題就是這樣一一衍生出來了，一個頁面太多jQuery插件了，請求數太多了，因而咱們得打包。打包須要咱們對插件有規劃。因而這需求在社區上逐漸造成了某些規則，其中最出名的是AMD規範，體現上requirejs這個加載庫上。

requirejs是前端技術發展上的一個分水嶺。javascript在es6以前一直沒有本身的加載機制，requirejs的出現意味着前端能夠向更大規模發展。之後我說的技術選型，一個很是重要的甄選點， 就是 是否存在加載器機制或符合某個模塊規範。

回到原來的話題，選擇框架要從兩面看，一是看該框架的本領，二是看大家團隊的能耐。

從框架的角度來看， 它的功能豐富不豐富，社區活躍度如何，國內社區活躍度如何（有的在國外流行，但國內只有初創公司或一些大公司的邊緣項目在試水），文檔齊全嗎，及時更新嗎，測試覆蓋率如何，上手難度如何，都是咱們考量點。不過能進咱們視野內的外國框架，基本是身經百戰，在造輪子興盛的世界闖出來的領頭羊。jQuery， angular， knockout， emberjs， polymer， react， backbone， zepto，咱們基本是圍繞在這幾個上面轉了。固然還有更大型的東西， EXT， YUI， dojo， easyui， bootstrap， 這是UI庫層面的。

下面是2012年外國對當時流行12個javascript MVC框架的純技術評估:

顯然，咱們第一步就是圈定時下最流行的框架與庫，做爲評估對象，而後再根據自家公司的狀況進行篩選。貴公司是建站公司，仍是有本身產品的公司呢？若是是建站公司，頁面不會複雜到哪裏去，基本上jQuery+bootstrap 搞定，不要想得太多，就是它們。若是有本身產品， 要維護一大堆客戶數據要與客戶打交道，不難想象是存在很是複雜的CRM系統，按照中國人的特性，這東西只會愈來愈複雜，這就要慎重考慮了。這每每是持續十年的維護升級，咱們須要看一下這框架是否有大家的產品那麼長壽，這框架的升級更新是否頻繁平緩。

若是你的項目是一個跨度三年以上的大工程，用《人月神話》的術語來講，90%就是個焦油坑。咱們須要使用更穩鍵成熟的技術方案，咱們須要重點避開谷歌的產品，它的許多產品都是玩票性質， GWT、Closure、Darty就是前車可鑑。polymer是基於許多新技術構建(http://www.csdn.net/article/2013-05-27/2815450-google-polymer)，其中Object。observe()， Custom Elements， HTML Imports，Shadow DOM， Model-Driven Views是遠遠沒被標準化， 許多仍是獨家的， 變數太大，所以纔出現以下的悲劇 http://weibo.com/1712131295/CfB7X336J?type=comment#_rnd1430880258836。 angular不是我黑它， 這東西也喜歡斷崖式升級， 它在1.08時兼容IE6-8， 1.2時須要打補丁兼容舊式IE， 1.3摒棄對舊式IE的兼容，直接在源碼中刪除全部兼容代碼，所以全部補丁方案都無力迴天，而且不支持全局Ctrl函數，許多模塊須要獨立引用，1.4不向下支持動畫模塊， 2.0由at改爲ts構建，因爲使用Object.observe，所以不支持IE6-11，chrome30-……

若是大家的產品是後臺系統，那麼就有兩個選擇，使用EXT， easyui這些重大的UI庫方案，其中EXT具備嚴重的排它性，它很難與其餘前端解決方案並用。什麼模塊組織，打包，數據可視化，它都已經所有幫你搞定。它文檔齊備漂亮， 入門難度中等， 但它要求你的團隊很是穩定，如今招一個專職EXT的前端是很難的。easyui是國內比較大牌的UI框架，雖然閉源，不過想擴展它不是難事。此外，國內的淘寶kissy， 網易nej也不錯。還有更輕量的方案，MVVM。MVVM最擅長作這些重交互的產品。舉例說，爲了對應複雜交互的gird，jquery社區開發出各類龐大巨物 datagrid， jqgrid， flexigrid，還不如MVVM幾個循環綁定來個乾脆利落，擴展性又好。目前，knockout， emberjs， angular與我寫的avalon就是這一類框架。angular雖然有點坑，但若是你是從1.3用起，而且不鳥IE，它仍是一個不錯的選擇，其活躍的社區爲它帶來無限的可能。knockout在。net人羣中很是流行，微軟出品，前端MVVM框架的鼻祖，不過它須要對後端數據進行過多的加工，由於它自己是不支持對套嵌對象的綁定。emberjs沒有一個好乾爹，但有一個好親爹，做者Yehuda Katz是jQuery， rails， Sproutecore， Merb， Handlebars這些著名框架的核心成員， 虎父無犬子，emberjs如今仍是國外的第二大MVVM框架。avalon是比較適合國情的MVVM，有它專門兼容IE6的版本，易上手，性能高，視頻教程多，出了問題能夠抓得着做者，是它的幾大賣點。

若是大家的產品是商場這樣重演示類的產品，就對SEO有要求，MVVM就不適合了。目前也就angular與avalon在搞後端渲染機制，但還不上了檯面。這時jQuery+bootstrap+requirejs就很是好用。requirejs的做用不僅僅是提供了一個按需加載機制,它還能讓咱們組織起更爲龐大的代碼。若是不用requirejs，國內另外一個選擇是seajs，它的規範是CMD。此外還有commonjs規範， 但這沒法直接運行於前端，須要藉助fekit， fis， webpack這樣的構建工具進行合併了。無論怎麼說，你這時選用的框架必須存在AMD，CMD或commonjs任一種加載規範，這方便你之後的橫向擴展。至於插件，目前小插件們都趨向用UMD（ https://github.com/umdjs/umd ），它可讓AMD，CMD，commonjs任一種加載器加載。

若是大家的產品是移動端，基本上是SPA架構了，由於這會減小等待，整頁刷新與請求數。目前該領域很是混亂了，不一樣於PC端，這要兼容的瀏覽器是多出N倍，而且爲了性能，瀏覽器商亂砍功能或改變一些瀏覽器特性的行爲，這每每引起一些奇怪的BUG，目前社區正在整理這些坑與解藥（ https://github.com/jtyjty99999/mobileTech ）。但目前沒有一個框架可以擺平全部問題，都須要多管齊下。個人看法是

requirejs(按需加載，移動端上能夠不打包，善用304緩存，騰訊搞出一個更牛叉的增量更新加載器MT，也能夠試試) + backbone（組織代碼與路由管理） + zepto（輕量DOM操做） + fastclick.js(點擊穿透與延遲處理) + hammer.js（各類觸屏事件） + iscroll5.js(滾動條處理) + Animate.css(CSS3動畫) + Enquire.js（處理響應式佈局）。

可見移動端每一個部件都爛到蕊了，每一個部件都須要專門的工具進行修復。移動端是很是注重體驗的，每個小角落都存在着各類動畫，但瀏覽器或自帶的webview都不好勁，因而native與hybird的話題才一直這麼火。有的人說，既然dom是最吃性能，那麼就乾脆用canvas來代替吧（ http://zhuanlan.zhihu.com/FrontendMagazine/19967854 與http://www.ruanyifeng.com/blog/2015/02/future-of-dom.html ）。facebook也推出本身相似的方案， react native，本身實現一套GUI，不過編寫語言是javascript。它是使用本身原來的超高性能輪子react實現的。這或者是一條道路。但優缺點也明顯，正如angular濃濃的java風，react是在邏輯插入大段標籤語言（jsx）。同時react的排它性也很是強，很難與其餘庫搭配使用。同時，咱們能夠看到，出自jQuery名門的jQuery mobile並無入圍，那個性能太糟了，連sencha touch。上面說的只是核心庫， 尚未搬出UI庫呢。號稱mobile first的UI庫不在少數，因爲無視IE，能夠大膽使用CSS3。目前比較出彩的有，foundation，semantic，refill， ratchet。若是隻是想運行在平板上，性能問題就不會那麼拮据了，咱們還能夠試試inoic， sencha touch， Kendo UI Mobile……

基本上，針對每一個平臺，我都列出一些主流框架了，但不意味着大家都能駕馭得住。小馬過馬，老牛沒過膝，松鼠淹個半死，就是這麼回事。創業公司喜歡新框架，這與他們拿得起高薪招一兩個前端牛人而致，基本上全部頁面就是他們乾的，所以用angular或ember都沒區別。小公司則當心，人員流失大，jQuery+requirejs是萬金油。大公司則基本上有本身的技術沉澱，換言之，應該有本身的前端框架，除非那東西很陳舊，不建議再造輪子。大公司建議是搞本身的技術委員會，根據本身的人員配置來挑選的框架。有句話說得好，不求最好，但求最合適．有些框架就屬於牛逼人手裏牛逼閃閃，二逼人手裏一團亂麻的。對於某些成長特別快的中等公司來講，這點最需防範 ，牛人是有的，但做戰的主體70%都是剛培訓出來的實習生，難上手，中文文檔不全的框架就必須過濾掉。我也不排除造輪子的可能性，畢竟有些公司就是人才輩出，能推出一些靠譜的開源產品來造福社區。

但不管咱們選擇什麼框架或決定本身動手造輪子，都勿忘初心，技術必須讓咱們工做生活更爲輕鬆愉快——咱們只選擇咱們能駕馭住的框架，咱們不能保證它在一年後會過期落後，但至少不會變成絆腳石。套用亞當·斯密的話(稅收是一種必要的惡)來講，框架是一種必要的惡，它是強約束的，所以必須慎重選擇。