我瞭解的前端史

同事邀我寫一篇前端技術發展史，用於新員工培訓。

在查資料寫正式文檔以前，我要先寫下本身的所知所感，以避免到時分不清 什麼東西是本身的、什麼東西是別人的。

---

1995 年 網景公司想給網頁增長一些交互性，花兩週時間創造了 javascript，用來控制網頁中的元素。

兩週時間創造的語言必定精緻不到哪兒去。
但巧妙的是，這門語言很是得開放靈活，開發者能夠本身定製它。
例如：

• 給 String 添加個首字母大寫的方法：

  String.prototype.capitalize = function() {
    return (
      this.charAt(0).toUpperCase() + this.slice(1)
    );
  };
  
  "hello".capitalize(); // Hello

• 修改 Date toString 方法：

  Date.prototype.toString = function() {
    return (
      this.getFullYear() +
      "/" +
      (this.getMonth() + 1) +
      "/" +
      this.getDate()
    );
  };
  
  new Date().toString(); // 2019/12/21

由於這種開放性，javascript 吸取了大量開發者的智慧，變得愈來愈好。

這種策略對我頗有啓發。

一件事我本身搞不定，那能夠把它變成你們的事，用集體智慧解決它。
道理簡單，但難在放低姿態、保持開放的心態。

---

吸取了開發者集體智慧後，javascript 標準【準確點是 ECMAScript 標準】發展得很快。

但碰到了一個問題：標準跑到了半山腰，瀏覽器們還在山腳下。

畢竟程序跑在瀏覽器上，標準再好，瀏覽器不支持 開發者也無法用。

並且衆多瀏覽器對標準的支持狀況也不同，不只是 javascript，還包括 html 和 css。
那個年代的招聘要求裏都有一條「能解決瀏覽器兼容性問題」。

---

瀏覽器兼容性問題讓開發者很頭疼。「幫開發者解決瀏覽器兼容性問題」成了各框架的重點任務。

其中玩得比較過的是 ExtJS。
html、css、javascript 兼容性問題它全包了。

思路是這樣的：

1. html、css：開發者不要寫了，天然就不須要關心 html、css 兼容性問題了。

   • html、css 寫法

     <style>
       .submitBtn {
         font-size: 2em;
         padding: 10px;
       }
     </style>
     <button class="submitBtn">提交</button>

   • ExtJS 寫法

     {
       xtype: 'button',
       scale: 'large',
       padding: 10
     }

2. javascript：開發者使用 ExtJS 的 api，而不用 ECMAScript 標準的 api。
   例如拷貝 b 對象的屬性到 a 對象上：

   • ECMAScript 標準

     Object.assign(a, b);

   • ExtJS

     Ext.apply(a, b);

ExtJS 讓開發者徹底不用考慮瀏覽器兼容性的問題，大幅提高了開發效率。

但代價是：
開發者和 html、css、javascript 標準被隔離開，
開發者像是在用一門新語言編程，被綁架在這個框架上了。

---

再後來 babel 出現了，開發者終於能夠擁抱最新 ECMAScript 標準了。

babel 的思路是這樣：
開發者用最新 ECMAScript 標準去寫代碼，而後經過 babel 編譯，轉成瀏覽器支持的代碼。

---

咱們說框架提升了開發效率，其實有兩層含義：

1. 框架提供了成熟的解決方案，如 組件、路由……少許代碼就能完成複雜的功能。
2. 框架限制了開發的自由度，讓往後維護和開發新功能變得容易。

我再從 限制開發自由度 這個角度說說框架的變化。

早些年前端流行 MVC 框架。

從代碼職責層面，什麼文件幹什麼活 確實很清楚。
但 MVC 使用事件驅動，事件太靈活。

茴香豆的「茴」有四種寫法：

View 派發一個事件，可能性有千萬種：

• 可能 Controller 在監聽，
• 可能父元素在監聽，
• 可能兄弟元素在監聽，
• 可能多個地方同時在監聽，而且監聽器執行順序還有講究，
• ……

這麼大的靈活性，你敢預判別人的代碼思路嗎？
這時候單步調試成了最穩妥、最「高效」的方法。

近些年 React 等框架限制就嚴格得多：
數據流單項傳遞，只能父到子。

一些場景下 代碼實現比事件驅動麻煩，但好處是 你們的代碼長得更像了。