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