前端開發發展簡史-我的經驗分享

時間 2019-11-10

標籤前端開發發展簡史我的經驗分享简体版

原文原文鏈接

查閱網上諸多資料，並結合本身的實際開發經驗，進行的一次前端技術分享。css

一目錄

不折騰的前端，和鹹魚有什麼區別html

目錄
一目錄
二前言
三發展歷史
3.1 原始社會
3.2 石器時代
3.3 鐵器時代
3.4 工業時代
四技術比較
4.1 JSP 與 jQuery
4.2 jQuery 與 Vue
4.3 Vue 與小程序
五思考總結
六解疑釋惑

二前言

返回目錄前端

於 2018年12月作個小小的前端技術分享，分享包括但不限於：Web 前端發展史、JQuery 與 Vue 的比較、Vue/React/Angular 的比較、前端開發經驗的分享與總結等……vue

參考文獻：react

三發展歷史

返回目錄jquery

以銅爲鏡，能夠正衣冠；
以古爲鏡，能夠知興替；
以人爲鏡，能夠明得失。git

瞭解一門技術的歷史，能夠幫助咱們更清晰地瞭解這個行業的動態。程序員

3.1 原始社會

返回目錄github

好久好久好久之前，即 1994 年的時候，網景公司 (Netscape Communications) 推出了第一款瀏覽器：NCSAMosaic，可是它只有少數的幸運兒才能使用。web

它的初始做用，是爲了方便科學家看文檔、傳論文。因此，到今天爲止，學習前端的人在接觸 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 的普及中，有三件事是值得一提的：

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 的前端工程化的項目等……無它，惟方便而。

3.4 工業時代

返回目錄

伴隨着信息時代、大數據時代的到來，jQuery 在大量的數據操做中的弊端體現出來了，它在對 DOM 進行大量的操做中，會致使頁面的加載緩慢等問題，這時，有些前端開發人員逐漸以爲力不從心了……

2008 年，谷歌 V8 引擎發佈，終結微軟 IE 時代。
2009 年 AngularJS 誕生、Node誕生。
2011 年 React 誕生。
2014 年 Vue.js 誕生。

若是說，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 框架來講，也涌現了很多地技術，例如桌面端的 Electron、NW.js；移動端的React Native、Weex 等。

以此同時，手機端的發展也是不可小覷的：

2007 年第一代 iPhone 發佈。
2008 年第一臺安卓手機發布。
......
2018 年 iPhone Xs Max 發佈。

雖然，一開始的手機應用，是基於手機本地系統如 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 等的體驗更加豐富，不一樣的平臺實現不一樣的功能。

因此，抓住機遇，不斷折騰，創造更好的前端吧！

六解疑釋惑

返回目錄

quesiton 1

問：爲何 Vue 不建議用於開發大型項目？
答：

首先，這裏討論的 Vue，建議用於開發中小型頁面，可是 Vue 是能夠開發大型項目的。
而後，Vue 自己是個輕量級框架，開發中小頁面應用是挺好的，可是開發大型應用尤爲是涉及大量表單交互的地方，React 和 Angular 就比較合適了。
最後，大型項目的配置較多，而 React 相對於 Vue 來講更加靈活，因此在有對比的狀況下，不推薦你使用 Vue 開發大型項目。

後記：Hello 小夥伴們，若是以爲本文還不錯，記得點個贊或者給個 star，大家的贊和 star 是我編寫更多更豐富文章的動力！GitHub 地址