我了解的前端史-有解無憂

同事邀我寫一篇前端技術發展史，用于新員工培訓，在查資料寫正式檔案之前，我要先寫下自己的所知所感，以免到時分不清什么東西是自己的、什么東西是別人的，

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 標準】發展得很快，但碰到了一個問題：標準跑到了半山腰，瀏覽器們還在山腳下，

../images/comeon.gif

畢竟程式跑在瀏覽器上，標準再好，瀏覽器不支持，開發者也沒法用，而且眾多瀏覽器對標準的支持情況也不一樣，不僅是 javascript，還包括 html 和 css，那個年代的招聘要求里都有一條“能解決瀏覽器兼容性問題”，

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

其中玩得最大的是 ExtJS，html、css、javascript 兼容性問題它全包了，思路是這樣的：

html、css：開發者不要寫了，自然就不需要關心 html、css 兼容性問題了，
- html、css 寫法
```
<style>
  .large-btn {
    font-size: 2em;
    padding: 10px;
  }
</style>
<button >提交</button>
```
- ExtJS 寫法
```
{
  xtype: 'button',
  text: '提交',
  scale: 'large'
}
```
  框架再把這個物件轉成 Dom，
  
  了解 React 的同學有沒有似曾相識的感覺？
  React 把 JSX 表示的虛擬 Dom 轉成 Dom，框架過時了，思想不過時，
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 編譯，轉成瀏覽器支持的代碼，

至此，兼容性問題完美解決了，

下面我再從”事件驅動“這個角度來說說技術的變化，

早些年前端流行 MVC 框架，MVC 就使用了事件驅動，

事件太靈活，茴香豆的“茴”有四種寫法：

../images/hui.gif

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

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

這些事件、監聽器的代碼散落在很多地方，它們通過事件傳遞、變數聯系在一起，只有把這些代碼找全了、呼叫順序看清楚了，才能搞明白資料流是怎么走的，

資料流走向不直觀 成了事件驅動被人詬病的問題，

對于一個問題，有兩種常見的處理方式：

解決問題，
消滅提出問題的人，

下面來看看這兩種處理方式的應用，

從“解決問題”的思路出發，出現了函式式回應式，

函式式回應式直接以“資料流走向”為視角編程，寫代碼就是畫流程圖，

看個計數器的例子：

../images/counter.png

代碼：

merge(
  fromEvent(increaseBtn, "click").pipe(mapTo(1)),
  fromEvent(decreaseBtn, "click").pipe(mapTo(-1))
)
  .pipe(scan((acc, cur) => acc + cur, 0))
  .subscribe(
    count => (resultLabel.innerText = count)
  );

流程圖【下圖的 e 代表 click event】：

../images/counter-flow.png

以“資料流走向”為視角編程：資料流相關的代碼放在了一處，代碼寫的就是怎么操作資料流，

資料流走向清晰了，但新的問題出現了：

流的運算子多、組合方式靈活，每個人習慣不一樣，看別人的流很費勁，
對于一些場景沒有好的解決方案，例如：

資料流共 10 段，第 10 段需要第 1 段的資料，

以下解決辦法我覺得都不完美：
- 第 1 段的資料一直向下傳遞，
  - 每段流都得小心，不能把前一段流的資料弄丟了，
- 用外部變數記錄第 1 段的資料，
  - 又退回了 MVC 事件驅動的形態，
- 第 10 段流再與第 1 段流組合，例如使用 zip、combineLatest 等，
  - tricky，可讀性變差，

因為存在以上問題，作業中我只敢在 ajax 請求或小專案里使用函式式回應式，不敢大范圍使用，

再來看另一個思路：消滅提出問題的人，

翻譯一下：你有問題，我就不用你了，我要另辟蹊徑，

典型代表：React 不通過事件傳遞資料了，改為通過 props 單向傳遞資料，只能父到子，

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

開發的自由度變小了，大家編碼方式更一致了，雖然一些場景下代碼實作變麻煩了，但以往專案的經驗告訴我：比起寫高效的代碼，寫一致的代碼更重要，

這也讓我對框架有了新的認識，框架可以從兩個方面提高開發效率：

提供成熟的解決方案，如組件、路由……少量代碼就能完成復雜的功能，

限制開發的自由度，讓日后維護和開發新功能變得容易，

我以“瀏覽器兼容性”、“事件驅動資料流走向不直觀”這兩個問題入手，談了前端技術的變化，大家還有哪些角度呢？歡迎評論交流，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/161059.html

標籤：JavaScript

上一篇：聊一聊 webpack 中的 preloading 和 Prefetching

下一篇：JS常用正則