關於前端框架的一些觀點

Hinc Liu發表於2013-04-04

  說起前端框架,我個人主張有框架不如無框架,這個觀點要先從框架和庫的區別說起。

  我所理解的庫,解決的是程式碼或是模組級別的複用或者對複雜度的封裝問題;而框架,更多的是對模式級別的複用和對程式組織的規範,這裡的模式是指比如 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 遊戲之類的場景不太適用,請不要斷章取義、生搬硬套。

相關文章