2018 前端開發分享
Create by jsliang on 2018-11-26 08:10:27
Recently revised in 2018-11-29 22:12:45
Hello 小夥伴們，如果覺得本文還不錯，記得點個贊或者給個 star，你們的贊和 star 是我編寫更多更豐富文章的動力！ ofollow,noindex">GitHub 地址
查閱網上諸多資料，並結合自己的實際開發經驗，進行的一次前端技術分享。
一 目錄
不折騰的前端，和鹹魚有什麼區別
| 目錄 |
|---|
二 前言
於 2018年12月 做個小小的前端技術分享，分享包括但不限於：Web 前端發展史、JQuery 與 Vue 的比較、Vue/React/Angular 的比較、前端開發經驗的分享與總結等……
參考文獻：
- 前端發展史 | 部落格園 - kidney
- 前端發展史 | 簡書 - 迷緣火葉
- 前端開發的歷史和趨勢 | CSDN - 紅豆灬
- 前端基礎歷史 | 百度前端技術學院 - 劉文超
- JSP、JavaScript、jQuery、jQuery Easy UI、Ajax、JSON各自是什麼、區別、聯絡 | CSDN - 南下Debugging
- jquery 和 jsp常用功能點彙總 | CSDN - toMatser
- jquery 和 vue對比 | 部落格園 - 綠茶/
- 淺析 Vue 和微信小程式的區別、比較 | 指令碼之家 - 賣女孩的小火柴
- 怎樣在 vue，angular，react 快速選擇一個合適的框架 | CSDN - 猛碼象
- 前端工程師的未來在哪裡？ | 微信公眾號 - 阿里技術
參與協助：
- 深圳大學 - 陳建光
- 杭州店家科技 智慧財務線 - 靳宗楠
三 發展歷史
以銅為鏡，可以正衣冠；
以古為鏡，可以知興替；
以人為鏡，可以明得失。
瞭解一門技術的歷史，可以幫助我們更清晰地瞭解這個行業的動態。
3.1 原始社會
很久很久很久以前，在 jsliang 出生的前一年，即 1994 年的時候，網景公司 (Netscape Communications) 推出了第一款瀏覽器：NCSAMosaic，但是它只有少數的幸運兒才能使用。
它的初始作用，是為了方便科學家看文件、傳論文。所以，到今天為止，學習前端的人在接觸 HTML 的時候，都會記得它的第一句有個詞是 Document 。
這時候的網際網路，無疑是處於原始社會的文明初創時期。
你的標點符號變了？OK，瀏覽器下載過一個新的頁面；
你提交了一個表單？OK，瀏覽器白屏等待許久，最後返回給你個 “使用者名稱錯誤”；
你電商網站有一千種商品？OK，那你寫一千個頁面吧……
這時候的網際網路，它的開發者統稱為程式設計師。因為前後端開發是一體的，前端程式碼是後端程式碼的一部分：後端收到瀏覽器的請求 ---> 傳送靜態頁面 ---> 傳送到瀏覽器。
3.2 石器時代
就在同一年(1994 年)，PHP 出現了，有了將資料嵌入到 HTML 中的形式，這意味著網際網路行業出現了鑽木取火，不斷朝石器時代發展。
這時候的網際網路，興起了資料嵌入模板，模板直接寫樣式的開發模式，例如 MVC 模式：
- Model（模型層）：提供/儲存資料。
- Controller（控制層）：資料處理，實現業務邏輯。
- View（檢視層）：展示資料，提供使用者介面。
在此時，前端只是後端 MVC 中的 V，所以那時候的所謂 “前端工程師” 還沒有對應的概念，前端開發人員都喜歡自稱 “切圖仔”。
後來，因為後端太忙，沒空寫頁面樣式讓它長得更好看些，於是才有了前端編寫頁面模板後，讓後端程式碼讀取模板，替換變數，渲染出頁面。
以 PHP 框架的 Laravel 為例：
- 使用者提交請求
- 根據路由不同請求對應的 Laravel 控制器
- 控制器與模型互動
- 控制器呼叫結果頁面
- 在使用者瀏覽器上渲染頁面
PHP 內嵌 HTML 程式碼片段：
<html>
<head><title>Car {{ $car->id }}</title></head>
<body>
<h1>Car {{ $car->id }}</h1>
<ul>
<li style="color:red">>Make: {{ $car->make }}</li>
<li style="color:blue">Model: {{ $car->model }}</li>
<li style="color:yellow">Produced on: {{ $car->produced_on }}</li>
</ul>
</body>
</html>
複製程式碼
相似的：
PHP 直接將資料內嵌到 HTML 中。
ASP 的 ASPX，在 HTML 中嵌入 C# 程式碼。
Java 的 JSP 直接將資料嵌入到網頁中。
3.3 鐵器時代
1995 年，網景推出了 JavaScript，形成了前端的雛形： HTML 為骨架，CSS 為外貌，JavaScript 為互動 。
而到了 1998 年前後，Ajax（Asynchronous Javascript And XML：非同步的 JavaScript 和 XML）得到了相對的應用，並且在之後逐漸被使用到各個頁面上，從而促進了 Web 從 1.0 的靜態網頁，純內容展示向 Web 2.0 模式邁進：
Web 2.0 時代：動態網頁，富互動，前端資料處理
在 Ajax 的普及中，有三件事是值得一提的：
這時候，前端不再是後端的模板，它可以獨立得到各種資料。相對於 Web 1.0 的時代，Web 2.0 由石器時代邁向了鐵器時代！
在 Web 2.0 的時代中，在 2006 年的時候，用於操作 DOM 的 jQuery 出現了，它快速地風靡了全球。大量的基於 jQuery 的外掛構成了一個龐大的生態系統，從而穩固了 jQuery 作為 JS 庫一哥的地位。
jQuery 的影響是源遠流長的。即時到了今天，還是會有用 jQuery 一把梭、jQuery + gulp 的前端工程化的專案等……無它，唯方便而。
3.4 工業時代
伴隨著資訊時代、大資料時代的到來，jQuery 在大量的資料操作中的弊端體現出來了，它在對 DOM 進行大量的操作中，會導致頁面的載入緩慢等問題，這時，有些前端開發人員逐漸覺得力不從心了……
如果說，Angular、React、Vue 等 MVVM 模式的出現，以及 Webpack 的前端工程化構建，加速了資料驅動前端工程化的發展。那麼，Node 這個基於 V8 引擎的服務端 JavaScript 執行環境的誕生，可媲美 Ajax 對於前端的貢獻。
Node 是前端的第二次飛躍，它使 JS 在服務端語言中也有了一席之地。
何為 MVVM 模式？
- Model：提供/儲存資料。
- View：檢視
- View-Model：簡化的 Controller，唯一的作用就是為 View 提供處理好的資料，不含其它邏輯。
如今，後端負責資料，前端負責其餘工作越發明顯化。它們之間的通訊，只需要後端暴露 RESTful 介面，前端通過 Ajax，以 HTTP 協議與後端通訊即可：
在這個前端的工業時代中，Vue、React、Angular 三大框架並駕齊驅。其他框架雖然也有在陸續釋出，但是脫離不了這三大框架的魔爪。而這三大框架的 UI 框架來說，也湧現了不少地技術，例如桌面端的 ElementUI、NW.js；移動端的React Native、Weex 等。
以此同時，手機端的發展也是不可小覷的：
雖然，一開始的手機應用，是基於手機本地系統如 IOS、Android、WP，使用其原生程式進行編寫的第三方應用程式 —— Native App 的天下。但是，隨著 React Native、微信小程式等這類技術的發展，以及網速等的不斷提升，Native App 逐漸被 Web App 所取代。
如今，多元化的前端框架使這門行業興起了其獨特的工業時代，諸多科技百花爭放、百家爭鳴。
四 技術比較
沒有最好的框架，只有最合適的應用場景。
在前端的開發工作開始之前，我們應該就不同的前端技術進行分析比較，從而更好、更流暢地進行程式設計開發。
4.1 JSP 與 jQuery
關於 JSP 與 jQuery 的學習記錄：
何為 JSP？
JSP 全稱 Java Server Page，是 Java 企業應用的一種動態技術。Java 和 JSP 是執行在伺服器端的，也就是說他兩執行的結果生成 HTML，HTML 是靜態頁面，而 JSP 是動態頁面。
何為 jQuery？
jQuery 是一個輕量級的 JavaScript 庫。jQuery 能夠使使用者的 HTML 頁面 和 JS 內容分離，也就是說，jQuery 的使用，更有利於 HTML、CSS、JavaScript 三者的分離，使得前端程式碼得到更好的維護。
現在就相同功能進行 JSP 與 jQuery 程式碼比較：
JSP 程式碼片段
<ul>
<c:forEach items="${list}">
<li>${user.userName}</li>
</c:forEach>
</ul>
複製程式碼
jQuery 程式碼片段
<!-- HTML 內容填充 -->
<script src="https://cdn.bootcss.com/jquery/3.3.1/jquery.js"></script>
<script>
$(function() {
// 通過 ajax 從 Java 介面獲取資料
var data;
$.ajax({
// ...請求地址、請求頭及傳參等
success: function(res){
data = res.data;
// 拼接字串，並渲染頁面
var html = '';
$.each(data, function(index, item) {
var html='<li>' + item.userName + '</li>';
html += html;
})
html = '<ul>' + html + '</ul>';
}
})
})
</script>
複製程式碼
咋看之下，你會覺得：“啊，JSP 那麼簡單，用 JSP 好啊！”
是的，JSP 幾行程式碼就能解決 jQuery 十幾行程式碼才能解決的事，而且執行速度也快過 jQuery，為啥不一直用它呢？
就專案發展而言。公司初創的時候，專案初期結構不繁雜的情況下，使用 JSP 無可厚非，因為它快、省事，而且還能節省人力（前後端讓一個 Java 寫就可以搞定了）。
但是，在專案越來越繁雜、龐大的情況下，一個 Java 已經維護不過來了，企業必須不停地增加 Java 開發人手，而 Java 人員也深陷技術債中……
然而，就好比喜歡鍛鍊的不全都喜歡跑步一樣，並不是所有操作資料的 Java 都喜歡寫頁面的，這時候就凸顯了幾個問題：
- 專案越來越大，模組越來越多，需要投入的人手也越來越多，這時候需要分模組分人手地去維護。而且這些 Java 開發人員必須喜歡操作資料也喜歡編寫頁面，要不然企業將面臨員工頻繁流動的困擾。
- 使用者開始對介面操作提更高的要求，需要增加更多的 JavaScript 互動和特效，無形中增加 Java 開發人員的工作量。
- 當有員工辭職後，下一名員工接手熟悉專案的時間將逐漸增加，由 1 天增長為 1 周甚至 1 個月。因為他不僅要熟悉資料的操作部分，更需要去維護 JavaScript 的頁面互動。而這段時間，辭職員工的工作將施壓到其他 Java 開發人員身上。
綜上，這時候企業不得不考慮了：能不能幫 Java 開發人員減輕負擔，更好地維護髮展專案。
以此同時，JavaScript 經過時間的沉澱，越發凸顯了它的強大。所以，在諸多因素之下，就有了前後端的分離：
後端人員提供介面，前端人員使用 jQuery 中封裝好的 Ajax 調取介面獲取資料，渲染到頁面上。
4.2 jQuery 與 Vue
在上面的 JSP 與 jQuery 的比較中，我們會發現一個問題，就是 jQuery 在資料操作上，它需要操作的步驟太多了。而且，頻繁地操作 DOM。在資料量比較大的情況下，還會造成頁面卡慢。
而這時候，就有了 MVVM 等 MV* 概念的提出：
何為 MVVM 模式？
- Model：提供/儲存資料。
- View：檢視。
- View-Model：簡化的 Controller，唯一的作用就是為 View 提供處理好的資料，不含其它邏輯。
簡單來說，就是 MV* 模式，將對資料的操作提升上去了。在 Vue、React、Angular 等 MV* 框架中，可以通過對資料的操作，從而完成對頁面資料的渲染。這裡我們挑選簡單、快速、緊湊而強大的 Vue，與 jQuery 進行比較。
index.html - jQuery
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>jQuery 程式碼演示</title>
</head>
<body>
<div id="app">
<ul id="list">
<li>第1條資料</li>
<li>第2條資料</li>
</ul>
<button id="add">新增資料</button>
</div>
<script src="https://cdn.bootcss.com/jquery/3.2.1/jquery.min.js"></script>
<script>
$(document).ready(function() {
var i = 2;
$('#add').click(function() {
i++;
//通過 DOM 操作在最後一個li元素後手動新增一個標籤
$("#list").children("li").last().append("<li>第" + i + "條資料</li>");
});
});
</script>
</body>
</html>
複製程式碼
index.html - Vue
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=no">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>Vue 程式碼演示</title>
</head>
<body>
<div id="app">
<ul>
<!--根據陣列資料自動渲染頁面-->
<li v-for="item in message">{{item}}</li>
</ul>
<button @click="add">新增資料</button>
</div>
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script>
new Vue({
el: "#app",
data: {
message: ["第1條資料", "第2條資料"],
i: 2
},
methods:{
//向陣列新增一條資料即可
add:function(){
this.i++;
this.message.push("第" + this.i + "條資料");
}
}
})
</script>
</body>
</html>
複製程式碼
上面的例子，對這兩者進行了簡單的比較與區分。雖然只是一個簡單的說明，但是在實際中，Vue 能解決的問題遠比上面的要多的多，複雜的多。
但是，對 jQuery 與 Vue 進行比較，是推崇 Vue，建議全面廢棄 jQuery 嗎？並不是。
- Vue 適用的場景：複雜資料操作的後臺頁面，表單填寫頁面。
- jQuery 適用的場景：比如說一些 HTML5 的動畫頁面，一些需要 JavaScript 來操作頁面樣式的頁面。
正應了那句話：“沒有最好的框架，只有更適合的應用”。
我們應該根據專案的需求，對技術進行不同的選取。就好比在公眾號的 H5 頁面上， jsliang 就很喜歡用 jQuery 進行操作，因為它簡單粗暴好操作，在動畫效果的編寫上也不錯；而在使用 Echarts 進行報表演示的開發中，我更喜歡使用 Vue，因為它能很簡易地對後端傳回的大量資料進行操作。
4.3 Vue 與 小程式
開篇點題； 深入學習過 Vue 開發的，那麼在微信小程式、React、Angular 等框架的開發上也不會太差 。
為什麼這麼說呢？因為它們都是基於 MV* 模式的一些現代前端框架。拿其中的 Vue 與 微信小程式 進行一些簡單區別：
- 生命週期/鉤子函式不同，微信小程式的鉤子函式要簡單地多。
- 請求資料方面，Vue 會在
created或者mounted中請求資料，而微信小程式會在onLoad和onSow中請求資料。 - 等等……
往往很多時候，我們會覺得它們是有很多地方是相同的。
所以，對於 Vue、React、Angular、微信小程式等 MV* 模式的前端框架，如果非得進行區分比較的話，我們應該就框架的使用場景、團隊技術能力、框架優劣勢、生態系統等方面去分析它們，並區分它們的適用場景：
- Vue ：簡單易學，靈活輕便。相對於 React 和 Angular 來說，它的學習成本低，易上手，且效能好，適用於開發小型應用。缺點是在開發中大型應用上比不上 React 和 Angular。
- React ：靈活性很高，生態圈強大。相對於 Vue 來說，React 在資料操作方面更靈動；相對於 Angular 來說，它的學習成本更低。缺點是相對於 Vue 來說，React 比較難上手，並且於 Angular 對比來看，React 在開發大型應用上需配合第三方庫。
- 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 等的體驗更加豐富，不同的平臺實現不同的功能。
所以，抓住機遇，不斷折騰，創造更好的前端吧！
後記：Hello 小夥伴們，如果覺得本文還不錯，記得點個贊或者給個 star，你們的贊和 star 是我編寫更多更豐富文章的動力！ GitHub 地址
由 樑峻榮 採用 知識共享 署名-非商業性使用-相同方式共享 4.0 國際 許可協議 進行許可。
基於 github.om/LiangJunron… 上的作品創作。
本許可協議授權之外的使用許可權可以從 creativecommons.org/licenses/by… 處獲得。