摘要：前端架構不斷推新，衆多IT企業都面臨着“如何選擇架構”，“是否需要再造輪子”的抉擇。去哪兒網前端架構師司徒正美分析了各主流行架構優劣點、适用場景，并針對不同規模的公司、項目給出了相應的前端技術選擇方案。
最近幾年，前端技術迅猛發展，差不多每年都會冒出一款主流的架構。 每次新開業務線或啟動新項目時，首先第一件事就是糾結：使用什麼架構，重造什麼輪子？我很高興應CSDN的邀請談我的看法。
RequireJS，前端技術發展分水嶺
在五六年前，移動端還沒有興起，我們沒有什麼選擇，就是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個JavasScript MVC架構的純技術評估：
顯然，我們第一步就是圈定時下最流行的架構與庫作為評估對象，然後再根據自家公司的情況進行篩選。貴公司是建站公司，還是有自己産品的公司呢？如果是建站公司，頁面不會複雜到哪裡去，基本上jQuery+Bootstrap搞定，不要想得太多，就是它們。如果有自己産品， 要維護一大堆客戶資料，要與客戶打交道，不難想象存在非常複雜的CRM系統，按照中國人的特性，這東西隻會越來越複雜，這就要慎重考慮了。這往往是持續十年的維護更新，我們需要看一下某架構是否有你們的産品那麼長壽，這架構的更新更新是否頻繁平緩。
大工程應盡量避開谷歌産品
如果你的項目是一個跨度三年以上的大工程，用《人月神話》的術語來說，90%就是個焦油坑。我們需要使用更穩健成熟的技術方案，我們需要重點避開谷歌的産品，它的許多産品都是玩票性質，GWT、Closure、Darty就是前車之鑒。Polymer基于許多新技術建構，其中Object.observe()、 Custom Elements、HTML Imports、Shadow DOM、Model-Driven Views還遠遠沒被标準化， 許多還是獨家的，變數太大，是以才出現下圖所示的悲劇。 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，avalon等國内優秀架構也值得考慮
如果你們的産品是背景系統，那麼就有兩個選擇，使用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産品，可考慮jQuery+Bootstrap+RequireJS組合
如果你們的産品是商場這樣重示範類的産品，就對SEO有要求，MVVM就不适合了。目前也就Angular與avalon在搞後端渲染機制，但還不上了台面。這時jQuery+Bootstrap+RequireJS就非常好用。RequireJS的作用不單單是提供了一個按需加載機制，它還能讓我們組織起更為龐大的代碼。如果不用RequireJS，國内另一個選擇是SeaJS，它的規範是CMD。此外還有CommonJS規範，但這無法直接運作于前端，需要借助fekit、FIS、Webpack這樣的建構工具進行合并了。不管怎麼說，你這時選用的架構必須存在AMD、CMD或CommonJS任一種加載規範，這友善你以後的橫向擴充。至于插件，目前小插件們都趨向用UMD，它可以讓AMD、CMD、CommonJS任一種加載器加載。
移動端技術較混亂，需多管齊下
如果你們的産品是移動端，基本上是SPA架構了，因為這會減少等待，整頁重新整理與請求數。目前該領域非常混亂，不同于PC端，要相容的浏覽器多出N倍，并且為了性能，浏覽器商亂砍功能或改變一些浏覽器特性的行為，往往引發一些奇怪的BUG，目前社群正在整理這些坑與解藥。但目前沒有一個架構能夠擺平所有問題，都需要多管齊下。我的見解是：
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%都是剛教育訓練出來的實習生，難上手，中文文檔不全的架構就必須過濾掉。我也不排除造輪子的可能性，畢竟有些公司就是人才濟濟，能推出一些靠譜的開源産品來造福社群。
但無論我們選擇什麼架構或決定自己動手造輪子，都勿忘初心，技術必須讓我們工作生活更為輕松愉快——我們隻選擇我們能駕馭住的架構，我們不能保證它在一年後是否會過時落後，但至少不會變成絆腳石。套用亞當·斯密的話（稅收是一種必要的惡）來說，架構是一種必要的惡，它是強限制的，是以必須慎重選擇。
作者簡介：鐘欽成，網名司徒正美，是中國最早研究加載器、選擇器與MVVM的人之一，著有《Javacript架構設計》一書。自栩為穿梭于二次元與二進制間的魔法師，緻力發掘各種黑魔法，提升一般前端工程師的生産效率。
轉載自：http://www.csdn.net/article/2015-05-11/2824656