目錄
前章我講了web開發技術發展史，基本上是偏後端的，現在前端技術也複雜起來，所以有必須講一下前端的發展史
前言
於2018年12月做個小小的前端技術分享，分享包括但不限於：Web 前端發展史、JQuery 與 Vue 的比較、Vue/React/Angular 的比較、前端開發經驗的分享與總結等……
一、發展歷史
以銅爲鏡，可以正衣冠；
以古爲鏡，可以知興替；
以人爲鏡，可以明得失。
瞭解一門技術的歷史，可以幫助我們更清晰地瞭解這個行業的動態。
1.1 原始社會
很久很久很久以前，在 jsliang出生的前一年，即 1994 年的時候，網景公司 (Netscape Communications) 推出了第一款瀏覽器：NCSAMosaic，但是它只有少數的幸運兒才能使用。
它的初始作用，是爲了方便科學家看文檔、傳論文。所以，到今天爲止，學習前端的人在接觸 HTML 的時候，都會記得它的第一句有個詞是 Document。
這時候的互聯網，無疑是處於原始社會的文明初創時期。
你的標點符號變了？OK，瀏覽器下載過一個新的頁面；
你提交了一個表單？OK，瀏覽器白屏等待許久，最後返回給你個 “用戶名錯誤”；
你電商網站有一千種商品？OK，那你寫一千個頁面吧……
這時候的互聯網，它的開發者統稱爲程序員。因爲前後端開發是一體的，前端代碼是後端代碼的一部分：後端收到瀏覽器的請求 ---> 發送靜態頁面 ---> 發送到瀏覽器。
1.2 石器時代
就在同一年(1994 年)，PHP 出現了，有了將數據嵌入到 HTML 中的形式，這意味着互聯網行業出現了鑽木取火，不斷朝石器時代發展。
這時候的互聯網，興起了數據嵌入模板，模板直接寫樣式的開發模式，例如 MVC 模式：
Model（模型層）：提供/保存數據。
Controller（控制層）：數據處理，實現業務邏輯。
View（視圖層）：展示數據，提供用戶界面。
在此時，前端只是後端 MVC 中的 V，所以那時候的所謂 “前端工程師” 還沒有對應的概念，前端開發人員都喜歡自稱 “切圖仔”。
後來，因爲後端太忙，沒空寫頁面樣式讓它長得更好看些，於是纔有了前端編寫頁面模板後，讓後端代碼讀取模板，替換變量，渲染出頁面。
以 PHP 框架的 Laravel 爲例：
1.用戶提交請求
2.根據路由不同請求對應的 Laravel 控制器
3.控制器與模型交互
4.控制器調用結果頁面
5.在用戶瀏覽器上渲染頁面
PHP 內嵌 HTML 代碼片段：
相似的：
●PHP 直接將數據內嵌到 HTML 中。
●ASP 的 ASPX，在 HTML 中嵌入 C# 代碼。
●Java 的 JSP 直接將數據嵌入到網頁中。
1.3 鐵器時代
1995 年，網景推出了 Java，形成了前端的雛形：HTML 爲骨架，CSS 爲外貌，Java 爲交互。
而到了 1998 年前後，Ajax（Asynchronous Java And XML：異步的 Java 和 XML）得到了相對的應用，並且在之後逐漸被使用到各個頁面上，從而促進了 Web 從 1.0 的靜態網頁，純內容展示向 Web 2.0 模式邁進：
Web 2.0 時代：動態網頁，富交互，前端數據處理
在 Ajax 的普及中，有三件事是值得一提的：
●2004 年：Gmail
●2005 年：Google 地圖
●2006 年：Ajax 被 W3C 正式納入標準
這時候，前端不再是後端的模板，它可以獨立得到各種數據。相對於 Web 1.0 的時代，Web 2.0 由石器時代邁向了鐵器時代！
在 Web 2.0 的時代中，在 2006 年的時候，用於操作 DOM 的 jQuery 出現了，它快速地風靡了全球。大量的基於 jQuery 的插件構成了一個龐大的生態系統，從而穩固了 jQuery 作爲 JS 庫一哥的地位。
jQuery 的影響是源遠流長的。即時到了今天，還是會有用 jQuery 一把梭、jQuery + gulp 的前端工程化的項目等……無它，唯方便而。
1.4 工業時代
伴隨着信息時代、大數據時代的到來，jQuery 在大量的數據操作中的弊端體現出來了，它在對 DOM 進行大量的操作中，會導致頁面的加載緩慢等問題，這時，有些前端開發人員逐漸覺得力不從心了……
●2008 年，谷歌 V8 引擎發佈，終結微軟 IE 時代。
●2009 年 AngularJS 誕生、Node誕生。
●2011 年 React 誕生。
●2014 年 Vue.js 誕生。
如果說，Angular、React、Vue 等 MVVM 模式的出現，以及 Webpack 的前端工程化構建，加速了數據驅動前端工程化的發展。那麼，Node 這個基於 V8 引擎的服務端 Java 運行環境的誕生，可媲美 Ajax 對於前端的貢獻。
Node 是前端的第二次飛躍，它使 JS 在服務端語言中也有了一席之地。
何爲 MVVM 模式？
●Model：提供/保存數據。
●View：視圖
●View-Model：簡化的 Controller，唯一的作用就是爲 View 提供處理好的數據，不含其它邏輯。
如今，後端負責數據，前端負責其餘工作越發明顯化。它們之間的通訊，只需要後端暴露 RESTful 接口，前端通過 Ajax，以 HTTP 協議與後端通信即可：
在這個前端的工業時代中，Vue、React、Angular 三大框架並駕齊驅。其他框架雖然也有在陸續發佈，但是脫離不了這三大框架的魔爪。而這三大框架的 UI 框架來說，也湧現了不少地技術，例如桌面端的 Electron、NW.js；移動端的React Native、Weex 等。
以此同時，手機端的發展也是不可小覷的：
2007 年第一代 iPhone 發佈。
2008 年第一臺安卓手機發布。
......
2018 年 iPhone Xs Max 發佈。
雖然，一開始的手機應用，是基於手機本地系統如 IOS、Android、WP，使用其原生程序進行編寫的第三方應用程序 —— Native App 的天下。但是，隨着 React Native、微信小程序等這類技術的發展，以及網速等的不斷提升，Native App 逐漸被 Web App 所取代。
如今，多元化的前端框架使這門行業興起了其獨特的工業時代，諸多科技百花爭放、百家爭鳴。
二、技術比較
沒有最好的框架，只有最合適的應用場景。
在前端的開發工作開始之前，我們應該就不同的前端技術進行分析比較，從而更好、更流暢地進行編程開發。
2.1 JSP 與 jQuery
就技術而言，JSP 與 jQuery 是天南地北的。但是，jsliang個人覺得可以就內嵌 HTML 的形式與前後端分離的形式，對 JSP 與 jQuery 進行簡要比較。這裏的比較，僅僅因爲工作中同時有涉及 JSP 與 jQuery，如有不實，望海納指正。
關於 JSP 與 jQuery 的學習記錄：
何爲 JSP？
JSP 全稱 Java Server Page，是 Java 企業應用的一種動態技術。Java 和 JSP 是運行在服務器端的，也就是說他兩運行的結果生成 HTML，HTML 是靜態頁面，而 JSP 是動態頁面。
何爲 jQuery？
jQuery 是一個輕量級的 Java 庫。jQuery 能夠使用戶的 HTML 頁面 和 JS 內容分離，也就是說，jQuery 的使用，更有利於 HTML、CSS、Java 三者的分離，使得前端代碼得到更好的維護。
現在就相同功能進行 JSP 與 jQuery 代碼比較：
咋看之下，你會覺得：“啊，JSP 那麼簡單，用 JSP 好啊！”
是的，JSP 幾行代碼就能解決 jQuery 十幾行代碼才能解決的事，而且運行速度也快過 jQuery，爲啥不一直用它呢？
就項目發展而言。公司初創的時候，項目初期結構不繁雜的情況下，使用 JSP 無可厚非，因爲它快、省事，而且還能節省人力（前後端讓一個 Java 寫就可以搞定了）。
但是，在項目越來越繁雜、龐大的情況下，一個 Java 已經維護不過來了，企業必須不停地增加 Java 開發人手，而 Java 人員也深陷技術債中……
然而，就好比喜歡鍛鍊的不全都喜歡跑步一樣，並不是所有操作數據的 Java 都喜歡寫頁面的，這時候就凸顯了幾個問題：
1.項目越來越大，模塊越來越多，需要投入的人手也越來越多，這時候需要分模塊分人手地去維護。而且這些 Java 開發人員必須喜歡操作數據也喜歡編寫頁面，要不然企業將面臨員工頻繁流動的困擾。
2.用戶開始對界面操作提更高的要求，需要增加更多的 JavaScript 互動和特效，無形中增加 Java 開發人員的工作量。
3.當有員工辭職後，下一名員工接手熟悉項目的時間將逐漸增加，由 1 天增長爲 1 周甚至 1 個月。因爲他不僅要熟悉數據的操作部分，更需要去維護 JavaScript 的頁面互動。而這段時間，辭職員工的工作將施壓到其他 Java 開發人員身上。
綜上，這時候企業不得不考慮了：能不能幫 Java 開發人員減輕負擔，更好地維護髮展項目。
以此同時，JavaScript 經過時間的沉澱，越發凸顯了它的強大。所以，在諸多因素之下，就有了前後端的分離：
2.2 jQuery 與 Vue
在上面的 JSP 與 jQuery 的比較中，我們會發現一個問題，就是 jQuery 在數據操作上，它需要操作的步驟太多了。而且，頻繁地操作 DOM。在數據量比較大的情況下，還會造成頁面卡慢。
而這時候，就有了 MVVM 等 MV* 概念的提出：
何爲 MVVM 模式？
●Model：提供/保存數據。
●View：視圖。
●View-Model：簡化的 Controller，唯一的作用就是爲 View 提供處理好的數據，不含其它邏輯。
簡單來說，就是 MV* 模式，將對數據的操作提升上去了。在 Vue、React、Angular 等 MV* 框架中，可以通過對數據的操作，從而完成對頁面數據的渲染。這裏我們挑選簡單、快速、緊湊而強大的 Vue，與 jQuery 進行比較。
上面的例子，對這兩者進行了簡單的比較與區分。雖然只是一個簡單的說明，但是在實際中，Vue 能解決的問題遠比上面的要多的多，複雜的多。
但是，對 jQuery 與 Vue 進行比較，是推崇 Vue，建議全面廢棄 jQuery 嗎？並不是。
Vue 適用的場景：複雜數據操作的後臺頁面，表單填寫頁面。
jQuery 適用的場景：比如說一些 HTML5 的動畫頁面，一些需要 JavaScript 來操作頁面樣式的頁面。
正應了那句話：“沒有最好的框架，只有更適合的應用”。
我們應該根據項目的需求，對技術進行不同的選取。就好比在公衆號的 H5 頁面上，jsliang就很喜歡用 jQuery 進行操作，因爲它簡單粗暴好操作，在動畫效果的編寫上也不錯；而在使用 Echarts 進行報表演示的開發中，我更喜歡使用 Vue，因爲它能很簡易地對後端傳回的大量數據進行操作。
2.3 Vue 與 小程序
開篇點題；深入學習過 Vue 開發的，那麼在微信小程序、React、Angular 等框架的開發上也不會太差。
爲什麼這麼說呢？因爲它們都是基於 MV* 模式的一些現代前端框架。拿其中的 Vue 與 微信小程序 進行一些簡單區別：
生命週期/鉤子函數不同，微信小程序的鉤子函數要簡單地多。
請求數據方面，Vue 會在created或者mounted中請求數據，而微信小程序會在onLoad和onSow中請求數據。
等等……
往往很多時候，我們會覺得它們是有很多地方是相同的。
所以，對於 Vue、React、Angular、微信小程序等 MV* 模式的前端框架，如果非得進行區分比較的話，我們應該就框架的使用場景、團隊技術能力、框架優劣勢、生態系統等方面去分析它們，並區分它們的適用場景：
Vue：簡單易學，靈活輕便。相對於 React 和 Angular 來說，它的學習成本低，適合快速上手，且學習曲線比較平緩。
React：靈活性很高，生態圈強大。相對於 Vue 來說，React 在數據操作方面更靈動；相對於 Angular 來說，它的學習成本更低。
Angular：完整的框架體系。相對於 React 和 Vue，它是一個成熟完善的框架。
微信小程序：簡單輕便。相對於 Vue 來說，它更加便捷了，而且微信小程序有上傳的代碼大小限制，使得微信小程序是真的 “小”。而且微信小程序結合微信，提供了很多 API 供開發人員使用。
因此，前端團隊在項目開發前，可以就項目涉及領域進行探討：
假如你想快速開發一個成本低的小應用，可以考慮 Vue。
假如你想開發一個大型應用，可以考慮 Angular。
假如你想開發一個跨平臺應用，可以考慮 React。
事無絕對，這裏僅爲本人觀點，實際技術選用應結合團隊意見，從而找到最適合該項目的技術。
就jsliang本人的開發體驗來說：2018 年 4 月份的畢業設計使用了 Vue 進行開發，然後相隔半年進行了微信小程序開發，發覺小程序開發比起 Vue 而言是更輕鬆便捷的，因爲它封裝了很多 API 供開發人員使用，並且它有專門的提 Bug 社區。
三、思考總結
沒有最好的框架，只有最合適的應用場景。
希望小夥伴們在面臨不同的項目時，可以選擇到最合適的框架，從而減少開發工作量，降低開發難度。
最後的最後，我們再談談前端的未來發展及前端職業未來：
前端會繼續分化。例如，喜歡 CSS 圖形化的，將更深入地學習 UI 與 CSS 3D 等，進行更炫酷的佈局；喜歡 JavaScript 的，將更深入地學習數據的操作，實現更復雜地業務、更有趣的用戶體驗。
前端會繼續融合。例如，Vue、React、Angular 合併，實現大一統，結束三分天下的局面。
前端將更加豐富。例如，PC、Mobile、IPad 等的體驗更加豐富，不同的平臺實現不同的功能。
所以，抓住機遇，不斷折騰，創造更好的前端吧！