01
百花齊放的前端框架
2007 年的時候我剛畢業，當時最火的前端框架是 jQuery 和 Ext JS，那時候大家糾結的問題是：我到底是用 jQuery 呢還是用 Ext JS 呢？
後來又出現了：Adobe Flex、Microsoft SilverLight、Dojo、Ember、Backbone、RequireJS......一大堆框架。
從 2008 年到現在，大家能在市面上看到的前端框架不下 10 種，真心讓人目不暇接。
在這個發展過程中，框架的規模和體積也在不斷的增大，最遠古的 prototype.js 和 mootools，都只有幾千行 JS 代碼，壓縮之後的體積也只有 10 K 左右。
到 2006 年 jQuery 出現的時候，體積已經擴大 10 倍到 100 K 左右，最龐大、最完善的是 Ext JS，目前的 6.x 版本中，光 JS 代碼就已經高達 24 萬行代碼了（含註釋）！
Word 天！老子真的學不動了！
朋友，你還是太年輕，這裡面實際上並沒有你想的辣麼複雜，在紛繁繚亂的表象背後，隱藏著簡單的規律。實際上，市面上所有前端框架都在解決兩個大問題：組件化和模塊化。
02
共同問題一：如何實現組件化
組件化有兩個好處：
1. 功能封裝2. 跨項目複用所有框架，無論用什麼語言來實現，都有一些基本的問題需要解決。
如何設計組件的生命週期？
如你所知，前端的特點是帶有 UI 界面的，是需要跟用戶直接交互的東西。
因此，你必須為這些 UI 組件設計完善的生命週期，從遠古的 Java Swing 到 QT，一直到 jQueryUI、Angular、React，大家都設計了自己的生命週期機制。
雖然技術細節有差異，但是基本的結構是類似的，都需要經歷幾個基本的階段：初始化、渲染、存活期、銷燬。請看圖示：
請注意，所有 UI 組件幾乎都是這樣設計的，怎麼樣，還需要去強記那些內容嗎？哈哈哈。
組件之間如何通訊？
OK，無論什麼 UI 框架，有了 UI 組件之後，緊接著就需要解決組件間通訊的問題。
你只要能解決以下 3 種情況就能解決絕大部分的問題了：父子間如何通訊？兄弟間如何通訊？遠房親戚之間如何通訊？
無論哪種框架，典型的解決方案有 3 種：父子之間通過事件或者直接調用進行通訊；兄弟、遠房親戚之間利用事件總線進行通訊；利用 cookie、localstorage、甚至服務端 session 進行通訊。
如何管理組件的狀態？
UI 組件不僅僅有外觀，外觀只是一張畫皮，裡面要有數據才行，既然有數據，就要有狀態管理的問題。
在狀態管理這塊，需要仔細設計這些問題：是否需要雙向綁定？如何配合路由保持組件狀態？
組件樣式怎麼做？
因為是前端框架，所以美觀的問題也不能放鬆。所幸的是，在移動互聯網時代，用戶都已經習慣了“扁平化”、“極簡主義”這些設計風格，我們可以利用市面上現有的 CSS 樣式庫來給我們的組件“化妝”，常用的有這些：
03
共同問題二：如何實現模塊化
如你所知，在 Java 裡面，我們有完善的 Class/Package/Jar/ClassLoader 這些機制的支持。當 JVM 發現所需要的 .class 文件沒有加載的時候，它自己會使用 ClassLoader 去加載，不需要程序員自己操心。
但是在 JS 裡面不行，由於 JavaScript 這門語言本身的缺陷，它沒有提供完善的模塊化支持，這就導致了所有前端框架必須自己解決模塊化的問題。
但是，值得慶幸的是，我們有了 NodeJS，有了 Webpack，再也不用像前幾年那樣自己搞 RequireJS 了！這就是為什麼市面上主流的前端框架都使用 Webpack 來做自己的 CLI 的原因。
總結：無論你目前在使用什麼前端框架，無論你以後想學哪些前端框架，只要緊緊扣住“組件化”和“模塊化”這兩條主線，心裡就會有大方向了，絕對不會迷失在茫茫多的技術細節裡面。
閱讀更多 IT技術之家 的文章
