3 JavaScript 的歷史與演進

---

---

3.1 JavaScript 的誕生

JavaScript 於 1995 年 5 月由 Brendan Eich 在 10 天內創建。Eich 在 Netscape 工作，並為其網路瀏覽器《Netscape Navigator》實作 JavaScript。

當時的想法是，客戶端網路的主要互動部分將以 Java 實作。JavaScript 應該作為這些部分的膠水語言，並讓 HTML 變得更具互動性。由於 JavaScript 協助 Java，因此它必須看起來像 Java。這排除了 Perl、Python、TCL 等現有解決方案。

最初，JavaScript 的名稱變更了幾次

• 它的代號是《Mocha》。
• 在 Netscape Navigator 2.0 beta 版（1995 年 9 月）中，它被稱為《LiveScript》。
• 在 Netscape Navigator 2.0 beta 3（1995 年 12 月）中，它獲得了最終名稱《JavaScript》。

3.2 JavaScript 的標準化

JavaScript 有兩個標準

• ECMA-262 由 Ecma International 主辦。它是主要標準。
• ISO/IEC 16262 由國際標準化組織（ISO）和國際電工委員會（IEC）主辦。這是次要標準。

這些標準所描述的語言稱為《ECMAScript》，而非《JavaScript》。之所以選擇不同的名稱，是因為 Sun（現為 Oracle）擁有後者的商標。而「ECMA」在「ECMAScript」中來自主辦主要標準的組織。

該組織的原名為ECMA，是歐洲電腦製造商協會（European Computer Manufacturers Association）的縮寫。後來由於組織的活動已擴展到歐洲以外，因此更名為Ecma International（「Ecma」是一個專有名詞，而非縮寫）。最初的全大寫縮寫說明了 ECMAScript 的拼寫。

原則上，JavaScript 和 ECMAScript 的意思相同。有時會做出以下區分

• 術語JavaScript指的是該語言及其實現。
• 術語ECMAScript指的是語言標準和語言版本。

因此，ECMAScript 6是該語言的一個版本（其第 6 版）。

3.3 ECMAScript 版本的時間表

這是 ECMAScript 版本的簡要時間表

• ECMAScript 1（1997 年 6 月）：標準的第一個版本。
• ECMAScript 2（1998 年 6 月）：小幅更新，以使 ECMA-262 與 ISO 標準保持同步。
• ECMAScript 3（1999 年 12 月）：增加了許多核心功能 - 「[…] 正規表示式、更好的字串處理、新的控制陳述式 [do-while、switch]、try/catch 例外處理、[…]」
• ECMAScript 4（2008 年 7 月放棄）：將會是一次大規模升級（具有靜態型別、模組、命名空間等），但最終變得過於雄心勃勃，並分裂了該語言的管理者。
• ECMAScript 5（2009 年 12 月）：帶來了一些小改進 - 幾個標準函式庫功能和嚴格模式。
• ECMAScript 5.1（2011 年 6 月）：另一個小更新，以使 Ecma 和 ISO 標準保持同步。
• ECMAScript 6（2015 年 6 月）：一次大幅更新，實現了 ECMAScript 4 的許多承諾。此版本是第一個官方名稱為ECMAScript 2015的版本，其名稱基於發布年份。
• ECMAScript 2016（2016 年 6 月）：第一個年度版本。與大型 ES6 相比，較短的版本生命週期導致較少的新功能。
• ECMAScript 2017（2017 年 6 月）。第二個年度版本。
• 後續的 ECMAScript 版本（ES2018 等）總是在 6 月獲得批准。

3.4 Ecma 技術委員會 39（TC39）

TC39 是負責 JavaScript 演進的委員會。嚴格來說，其成員是公司：Adobe、Apple、Facebook、Google、Microsoft、Mozilla、Opera、Twitter 等。也就是說，通常是激烈競爭的公司為了這門語言的利益而共同努力。

TC39 每兩個月舉行一次會議，由成員指定的代表和受邀專家參加。這些會議的記錄公開在GitHub 儲存庫中。

3.5 TC39 流程

有了 ECMAScript 6，當時發布流程出現的兩個問題變得明顯

• 如果發布之間經過太長的時間，那麼準備好的功能必須等待很長的時間才能發布。而準備好的功能，則有趕在最後期限發布的風險。

• 功能通常在實作和使用之前很久就被設計出來。因此，與實作和使用相關的設計缺陷發現得太晚了。

為了應對這些問題，TC39 制定了新的TC39 流程

• ECMAScript 功能獨立設計，並經歷階段，從 0（「稻草人」）開始，以 4（「完成」）結束。
• 特別是後續階段需要原型實作和實際測試，導致設計和實作之間的回饋迴路。
• ECMAScript 版本每年發布一次，並包含在發布期限之前達到第 4 階段的所有功能。

結果：較小、漸進式的發布，其功能已經過現場測試。圖 1 說明了 TC39 流程。

ES2016 是第一個根據 TC39 流程設計的 ECMAScript 版本。

3.5.1 提示：以個別功能和階段思考，而不是 ECMAScript 版本

在 ES6 之前，最常見的是根據 ECMAScript 版本來思考 JavaScript，例如「這個瀏覽器是否支援 ES6？」

從 ES2016 開始，最好以個別功能來思考：一旦某個功能達到第 4 階段，你就可以安全地使用它（如果它受到你鎖定的 JavaScript 引擎支援）。你不需要等到下一個 ECMAScript 發布。

3.6 常見問題：TC39 流程

3.6.1 [我最喜歡的建議功能] 進展如何？

如果你想知道各種建議功能處於哪些階段，請參閱 GitHub 儲存庫提案。

3.6.2 是否有 ECMAScript 功能的官方清單？

是的，TC39 儲存庫列出了 已完成的提案，並提到它們在哪些 ECMAScript 版本中引入。

3.7 JavaScript 的演變：不要破壞網路

偶爾會出現一個想法，即透過移除舊功能和怪癖來清理 JavaScript。雖然這個想法的吸引力很明顯，但它有很大的缺點。

假設我們建立一個與舊版本不相容的新版 JavaScript，並修復其所有缺陷。結果，我們會遇到以下問題

• JavaScript 引擎變得臃腫：它們需要同時支援舊版本和新版本。IDE 和建置工具等工具也是如此。
• 程式設計師需要知道不同版本之間的差異，並持續注意這些差異。
• 你可以將所有現有程式碼庫移轉到新版本（這可能需要大量工作）。或者，你可以混合版本，但重構會變得更困難，因為你無法在不變更程式碼的情況下在版本之間移動程式碼。
• 你必須以某種方式為每個程式碼片段（無論是檔案或嵌入在網頁中的程式碼）指定它所寫入的版本。每一個可能的解決方案都有優缺點。例如，嚴格模式 是 ES5 的一個較為簡潔的版本。它沒有像預期中那麼受歡迎的原因之一：它必須透過在檔案或函式開頭的指令選擇加入，這很麻煩。

那麼解決方案是什麼？我們可以兩全其美嗎？ES6 選擇的方法稱為「一個 JavaScript」

• 新版本永遠完全向後相容（但偶爾可能會有一些微小的、幾乎不顯著的清理工作）。
• 舊功能不會被移除或修復。相反地，會引入它們的更好版本。一個例子是透過 let 宣告變數，這是 var 的一個改良版本。
• 如果語言的某些方面發生變更，則會在新的語法結構內進行變更。也就是說，你會隱含地選擇加入。例如，yield 僅在產生器（ES6 中引入）內是一個關鍵字。而模組和類別（ES6 中引入）內的所有程式碼都隱含地處於嚴格模式。