JavaScript 框架對於前端來說就像是，八倍鏡對於98K一樣重要，成爲了前端開發事半功倍，不可或缺的一部分。但是很少有人思考過，我們爲什麼使用框架？僅僅是因爲代碼量減少嗎？
很多前端開發者使用框架是因爲：
“ 現在某某框架很火，我也要學習使用一下。”
“ 這個框架 UI 庫很多，漂亮，跟公司設計很相似。”
“ 這個框架有很多插件，引入調用一下就行，省了我很多代碼量。”
“ 公司項目碰巧很適合做單頁面應用。”
“ 我喜歡用數據綁定。”
上面的幾個答案確實是框架可以解決的問題，但僅僅是因爲這些嗎？因爲某一個問題，就引入一個龐大的框架，絕不應該如此。
爲什麼使用框架？
近年來，因爲互聯網的崛起，web 業務也越來越複雜和多元化，一個web項目也不是像以前那樣寫幾個網頁拼起來，加幾個特效 duang 一下就成了。項目複雜了，出現的問題也就多了。
前後端分離
在前後分離概念出現之前，大部分 web 項目都是後端人員又當爹又當媽的，前後端一起搞，導致質量和效率不是很好。而且對個人的發展也有影響，一個人你什麼都會，也意味着你什麼都不精，畢竟天才還是少數的。這也是社會趨勢影響，大公司招聘，一般也都是需要某一方面很有研究的專才。
在互聯網的洪流下，以前的那種方式越來越跟不上節奏，所以前後端分離應運而生。
前後端分離後，前端的任務也變得重要起來，web前端開發慢慢趨於規範。
但是在 jQuery 稱霸的時代裏，並不能滿足前端開發人員的需求。也慢慢暴露出了很多不好解決的問題：外部js引用太多，複用性低，開發週期太長，性能低，效率低等等，這些 jQuery 不好解決或者說解決不了的問題，也成爲了前端開發的趨勢。
使用框架解決了哪些問題
重複引用外部js
在以前使用jQuery開發時，當項目越來越複雜和龐大的時候，可能會用到各種各樣的第三方插件，而且不只是一個頁面使用，所以會出現每個頁面都要引用一遍相同的js文件，冗餘大的問題。
這樣不僅會使頁面代碼變得雜亂，而且會影響頁面的打開速度，萬一以後需要變更一下js文件的路徑，還要一個一個去修改，對後期的維護也是很大的負擔。
使用框架開發時（例如Vue），一般都會搭配構建工具使用（例如webpack），整個項目運行時會有一個入口文件，當你有多個組件都會用到某個文件或插件時，僅僅在這個入口文件引入一次，就可以在你所有組件中使用這個插件的方法，可以說是一勞永逸。就算後期文件位置有所變動，也只是修改入口文件中的引用路徑就可以了。
組件化
組件是前端框架裏非常強大的功能之一，它可以擴展你的HTML，封裝可以重用的代碼塊，比如你的輪播圖、tab切換、頁面頭部、頁面底部等等。
這種獨立的組件具有了結構（html），表現（css）和行爲（js）完整的功能，很大程度的節省了代碼量，提高了代碼的複用性。根據不同的需求定製你自己的組件，在需要的頁面引用即可。在團隊合作開發中，相對獨立開發不同的組件，效率上也有很大的提升。
開發週期長
jQuery開發時，需要頻繁的操作DOM，幾乎任何動態效果都需要去選擇DOM來進行相應的操作，這使開發變得麻煩起來，很多的時間都用到了操作DOM上，項目的開發週期自然被延長。
使用框架開發，框架中封裝許多的頻繁使用的功能，例如Angular中的指令，指令功能有數據綁定，表單驗證，數據格式化等等。這時前端的重點只需要放在數據邏輯部分，而不需要花費很大的精力去操作DOM完成功能，從而加快項目進度。
性能
很多DOM操作會引起迴流和重繪，對於jQuery來說，大量的操作DOM雖然方便，但是很浪費頁面性能。
框架和jQuery雖然都會操作DOM，但是框架吧大量的DOM進行了處理和優化（例如Vue的虛擬DOM），通過數據驅動，就能渲染出DOM，大大提升了性能。
第二篇：
前端框架到底幫你解決了什麼問題？
這段文字的起因是看到時間線上有篇文章說“前端書籍都是垃圾”（順便說一句，其實這篇文章的作者不是瞎唬爛，他提出了一個深刻的問題，雖然他的思考結論是錯的）。垃圾肯定談不上，但我覺得市面上大部分前端的書籍也好，文章也好，甚至框架官方文檔也好，確實都沒有解釋清楚一個問題：前端框架到底幫你解決了什麼問題？
- 是數據驅動問題嗎？不是，數據驅動我們自己用手敲也能敲的很優雅。
- 是事件監聽問題嗎？也不是，事件監聽用事件代理就可以寫出很好的代碼。
- 是所謂的“組件化開發”嗎？更不是，組件化開發是思想，有沒有框架，組件化都是必須的。
那麼前端框架到底解決了什麼問題？
框架其實就解決了一個問題——使用聲明式語法，描述組件對象的嵌套關係，並自動生成與dom對象的對應關係。
自己敲過框架輪子的人一定明白我在說什麼——你在自己寫框架的時候，最難處理的不是數據驅動，observable庫有的是，也不是事件監聽，那玩意兒jquery已經做的很好了，更不是模板語法，誰還寫不出個模板轉render的函數？真正有點麻煩的問題是：
- dom對象以及他們的從屬（同時是傳遞關係）關係，是通過html自動生成的，然而當你把“組件”抽象爲js對象，你怎麼能實現子組件的自動創建，自動銷燬，自動數據傳遞，自動render，自動事件監聽（不一定是dom事件）？
- 怎麼把js組件對象存在它應該在的地方（我的標題圖截得是preact源碼解決這個問題的部分，preact的子組件實例，是存在dom節點上的），並且rerender的時候能把js組件對象和dom節點對應起來？
- 什麼時候需要new，什麼時候複用原來的組件？
- 組件重渲染之後，怎麼commit到dom上？
這套機制，纔是前端框架真正替你省力的“髒活”，因爲不如此，你的組件根本集成不起來，“組件化開發”、“數據驅動”也就無從談起。至於框架對外提供的那些特性和語法糖，其實都見仁見智，有人喜歡有人不喜歡。但是我前面說的那些髒活，纔是一個框架之所以是一個框架的理由。
關於這套機制，類angular框架和類react框架分別講了兩個故事——
- angular講的故事是“模板編譯爲能精細感知model變化事件的dom-commiter”。
- react講的故事是“model怎麼變不重要，我只要model當前狀態，我有辦法給你patch到dom上”。
表面上看起來是很不一樣的，但是本質上都是做同一件事——
你在模板裏面也好，jsx裏面也好，使用組件時寫的的都是組件的類型，然而實際render的時候，框架幫你自動創建了組件實例。第二次render的時候，框架又幫你做了兩件事，第一件事是，幫你找到應被複用的組件實例，指揮他重新render一遍，第二件事是，幫你把render的結果commit到正確dom節點上。
所以“xxx框架比yyy框架如何”這種問題，壓根就不是問題——反正他們乾的都是同一件事情，內部實現的不同對你來說也不太重要，糾結什麼框架好有什麼用呢？反正在真正比較複雜的項目中，框架的角色無非就是個view層，玩不出什麼花樣來。工程上那個框架最合心意用哪個就好。
