關(guān)于前端框架的一些觀點
說起前端框架，我個人主張有框架不如無框架，這個觀點要先從框架和庫的區(qū)別說起。
我所理解的庫，解決的是代碼或是模塊級別的復(fù)用或者對復(fù)雜度的封裝問題；而框架，更多的是對模式級別的復(fù)用和對程序組織的規(guī)范，這里的模式是指比如 MVC，為了實現(xiàn) M 和 V 的解耦，通過 IOC 或是 PubSub 等手段，把丑陋的耦合由經(jīng)常變化的業(yè)務(wù)代碼轉(zhuǎn)移到不經(jīng)常變化的框架內(nèi)部消化。
對于前端來說，在 WebApp 概念興起前，很少能看到所謂的框架，更多的是類似于 jQuery、YUI 的庫，因為前端的一路下來的發(fā)展歷程和開發(fā)方式的特殊性決定了很難有什么通用的模式能滿足多樣化前端的開發(fā)需要。如果一定要說，也就是近些年伴隨著 SPA（Single-page application）概念興起而出現(xiàn)的所謂前端 MVC 的一系列衍生模式，但是即便如此，光靠一個框架還是解決不了什么問題。
這里要重點說一下 SPA 這個隨著 AJAX 技術(shù)火起來的概念，SPA 的好處有哪些相信不用多說，網(wǎng)上一搜一大堆，接近原生應(yīng)用的表現(xiàn)、和 HTML5 技術(shù)發(fā)展方向向契合等等。SPA 的出現(xiàn)讓前端變得越來越重，代碼組織、邏輯解耦等后端常常面對的問題也開始在前端出現(xiàn)，人們也開始在前端引入 MVC 去應(yīng)對這樣一些問題，確實很有成效。但是前端變重所面臨的問題就僅僅是 JavaScript 層面的 MVC 能解決的嗎？
我們來看前端開發(fā)的特點，HTML + CSS + JavaScript 三種不同類型的語言相互配合實現(xiàn)需求；再來看頁面加載的特點，先加載 HTML，再有策略的加載 CSS 和 JS，碰到對性能要求較高的場景還要考慮分模塊按需加載，在大型 SPA 中還有可能要把頁面拆成一個個組件，每個組件又包含模板、樣式、腳本，頁面拆分成組件的策略是什么，組件的按需加載策略又如何，這些顯然不是 MVC 框架擅長解決的問題，這也是 AMD/CMD 等模塊機制提供者和加載器流行起來的原因。
近兩年開始流行大前端的概念，我的理解這里的大前端說的就是前端的工程化，前端開發(fā)的工程特點開始和后端開發(fā)越來越像，這也給我們提供了更多的思路，框架解決不了的問題，是不是能像后端一樣靠工具解決，過程中的模式（指類似的、重復(fù)性的工作）是否可以借助于持續(xù)集成工具實現(xiàn)自動化?；氐絼偛耪f到的前端組件化問題，代碼在開發(fā)環(huán)境應(yīng)該對開發(fā)人員友好，開發(fā)人員可以分工編寫不同的組件，每個組件的模板、樣式、腳本代碼可以分別寫在獨立的文件中，分目錄組織；代碼在發(fā)布環(huán)境應(yīng)該對用戶友好，組件的代碼應(yīng)該根據(jù)策略打包成一個或多個文件并進行壓縮，便于按需加載和節(jié)省流量。而這些正應(yīng)該是工具要做的。
說到這里，其實框架對于程序組織的規(guī)范性上面的作用已經(jīng)不明顯，為了更靈活的模塊化，不如不去用框架，把自定義事件的能力封裝成模塊，PubSub 模式解耦形成約定，用約定和書面規(guī)范代替框架去約束程序的組織，讓開發(fā)人員直面框架的本質(zhì)，充分發(fā)揮人的能動性，相信這才是更利于人才成長的實踐方式。
最后提一下前端基礎(chǔ)架構(gòu)方面的一些思考，不要放大框架的作用，隨著前端的成熟，工程化的特點會越來越明顯，框架、庫、工具、過程規(guī)范、文檔這些東西的發(fā)展缺一不可，只有系統(tǒng)的結(jié)合才能發(fā)揮出技術(shù)的最大效能，在這樣的平臺上去實踐、去積累，人才能更全面的發(fā)展。
歡迎微博 @Hinc 討論。
P.S. 上述觀點有一定的適用場景，對于比如 HTML5 游戲之類的場景不太適用，請不要斷章取義、生搬硬套。
