我瞭解的前端史

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

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

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>
       .large-btn {
         font-size: 2em;
         padding: 10px;
       }
     </style>
     <button class="large-btn">提交</button>

   • ExtJS 寫法

     {
       xtype: 'button',
       text: '提交',
       scale: 'large'
     }

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 使用了事件驅動，事件太靈活。

茴香豆的“茴”有四種寫法：

一個事件的處理 有 N 種方式：

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

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

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

這就好像從 A 處到達 B 處，
事件驅動不限制交通方式，有的人走路、有的人開車、有的人坐飛機……
數據流單向傳遞規定了大家都得開車去。

一些場景下 數據流單向傳遞比事件驅動麻煩，但好處是軟體複雜度降低了。

框架的關註點向 限制開發自由度 偏移也反映出了：
現在的產品大都是團隊合作完成的。
比起寫高效的代碼，寫一致的代碼更重要。