前端SPA框架一些見解

提及前端框架，我我的主張有框架不如無框架，這個觀點要先從框架和庫的區別提及。

　　我所理解的庫，解決的是代碼或是模塊級別的複用或者對複雜度的封裝問題;而框架，更多的是對模式級別的複用和對程序組織的規範，這裏的模式是指好比 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 模式解耦造成約定，用約定和書面規範代替框架去約束程序的組織，讓開發人員直面框架的本質，充分發揮人的能動性，相信這纔是更利於人才成長的實踐方式。

　　最後提一下前端基礎架構方面的一些思考，不要放大框架的做用，隨着前端的成熟，工程化的特色會愈來愈明顯，框架、庫、工具、過程規範、文檔這些東西的發展缺一不可，只有系統的結合才能發揮出技術的最大效能，在這樣的平臺上去實踐、去積累，人才能更全面的發展。