前言
春節假期因為沒有win電腦回家，所以才有時間靜下心來看會兒書。這次讀的是《JavaScript二十年》，書籍主要介紹了語言誕生以及一些階段性的發展里程碑，能學到的有用知識不會太多，如果你還沒看過紅寶書或者《你不知道JavaScript》等系列書籍，建議先看完再來讀這本比較”閒“的書。
下面我會以我個人的理解角度概括一下書籍的一些主要內容，給一些想看沒時間看的兄弟節省一下時間。
1. 語言誕生
90年代初，互聯網崛起了，瀏覽器出現在大眾視野了，大家開始衝浪了。Netscape，也就是網景，在此時創立，很顯然大家都想要撈一筆大的。
此時，Web核心還是HTML，但是此時大家都對可以方便編排用户應用操作的腳本語言有了極大的期待，於是，網景招了Brendan Eich進來（為了方便國人理解，後文用老E代替Brendan Eich），讓他開發一款可以集成到網頁裏的腳本語言。
恰恰好在這個時候，萬物起源 Java 出來了，Java的開發公司Sun和網景達成了協議，決定將Java集成到瀏覽器中。於是，網景老闆現在的戰略目標就變了，他們可能只需要一門[小語言]來補充一下Java就可以了。
此時，網景內部還是有很多不同的聲音，主要是：
- 他媽的
Java到底行不行？ - 為什麼要兩門語言，直接
Java不就完了，還小語言補充是瞧誰不起？ - 誰他媽來開發這門小語言，有沒有大佬，在線等，很急
對於第一個問題，當時還是95年的春天，年輕的Java對於初學者來説還是相當難上手的，所以，從多方面考慮，被我們寄予厚望的Java 最終還是倒在了16強！
對於第二個問題，他們對標了當時的競品，微軟，他們也是出售Visual C++給專業選手，然後使用 Visual Basic來作為補充的腳本語言，給一些菜雞做一些[膠合]定製。這個想法很不錯，所以網景也抄了。
那麼就剩下第三個問題了，很顯然，此時需要我們的主角老E登場了。他花了10多天（是的，書裏是這麼寫的，你現在是不是覺得自己像個沙比？）來創建了一門叫做Mocha的新語言，證明這門語言在網景瀏覽器中的可行性。95年12月的時候，正式命名為JavaScript發佈，通稿中 JavaScript 被描述為「一種對象腳本語言」，可用於編寫腳本來動態地「修改 Java 對象的屬性和行為」。它將作為「Java 的補充，方便進行在線應用開發」。儘管它們的技術設計只有表面上的相似，網景和Sun還是試圖在 Java 和 JavaScript 語言間建立牢固的品牌聯繫。這種名稱上的相似性及其帶來的兩種語言具備密切聯繫的暗示，長期以來都是導致混亂的根源之一。
眾所周知，程序員最精通的，還是CV，所以老E在一開始的設計中，借鑑了許多其他語言的特點。
- 比如Lisp 式的函數一等公民概念
- 比如從Java借鑑的
null概念，本質上是表達「沒有對象」的對象，也是後來一個經典Bug之一 - 比如從C借鑑的條件語句，循環語句和非順序控制流的
break、continue和return語句
根據 Brendan Eich 的回憶，typeof null的值是原始 Mocha 實現中抽象泄漏g的結果。null的運行時值使用了與對象值相同的內部標記值進行編碼，因此typeof運算符的實現就直接返回了"object"。
2. 創立標準
儘管作者是一個天才，但是10天趕工出來的新語言還是有很多的問題。
JavaScript發佈後的第二年，微軟也宣佈在IE上支持這個語言，同時他們也開始了JScript的開發工作，為什麼名字不一樣，你想想啊，網景肯定不會把代碼給微軟啊，所以他們只是在各自瀏覽器上實現了一樣的邏輯，並且兼容一樣的腳本代碼，網景的叫做JavaScript ，微軟這邊就叫JScript 。每當微軟對比兩個瀏覽器時發現相同腳本具有差異，他們就要對JavaScript做逆向工程，看看這些人底層寫的什麼垃圾實現，為什麼不同瀏覽器會有不同的實現。（這個同代碼不同瀏覽器下表現不同的經典尿性也一直延續至今）
在整個JScript 的開發過程中，微軟的人一旦發現JavaScript 的語言規範缺失，就瘋狂Diss網景的哥們。
JavaScript風評拉胯，[ 創立一個標準，確保在不同瀏覽器中的兼容性 ]變得越來越重要。
於是，網景通過人際關係找到了ECMA國際組織的秘書長，跟他提議推動JavaScript的標準化。由於國際標準組織（ISO）認可ECMA，ECMA的標準可以通過快速通道來成為ISO標準。
96年10月，ECMA邀請所有風雲人物（基本是網景和微軟的員工）到場共同參與JavaScript的討論，並且組成一個新的Ecma技術委員會（Technical Committee）。
ECMA使用數字來標記旗下的技術委員會，而下一個可用的數字是39，所以這次組織會議就是經典的TC39會議
會議開始，兩派人馬輪番演講，最終委員會採用了微軟員工Robert Welland編寫的文檔，網景確實拉了跨了，還不如繼承者。這份文檔是利用了偽代碼的概念來進行編寫的，這種方式在描述JavaScript的語義方面相當有效，其詳細程度足以確保互操作性。
所以，ECMAScript和JavaScript的關係是什麼？前者是後者的規範，後者是前者的一個實現。比如前者描述了內置方法A，應該實現什麼邏輯，什麼類型入參和什麼類型的返回結果。那麼不同的瀏覽器廠商就要實現這一套邏輯，給自己的 不管是JavaScript 還是 JSCript ，又或者是什麼BScript，都要有這個內置方法A，並且使用方法符合ECMAScript的定義。
3. 改革失敗
千禧年到來之際，隨着 Netscape、微軟和其他瀏覽器廠商不斷增強瀏覽器的實用性，Web 得以迅速發展。Web 的成功與其持續演化的訴求，催生了 Ecma TC39 和 W3C 等工作組。這些組織中有些參與者是行業專家，他們並未直接參與瀏覽器開發。這些人的興趣集中在理想化的未來 Web 上。
這個時候，一些 TC39 的參與者意識到了需要糾正原始 JavaScript 中的設計錯誤，並提供滿足專業軟件開發者需求的特性，而非僅僅滿足非專業的腳本編寫者。打造新一代 ECMAScript 的目標集中在了 ECMA-262 的第四版上。這個版本在 TC39 內部最初被稱為「E4」，後來則稱為「ES4」。
TC39 對 ES4 的嘗試共進行了兩輪，「初版 ES4」和「新版 ES4」。
自首次 TC39 會議提出在語言中添加類（class）定義的提案起，人們一直希望嘗試在 JavaScript 中添加新特性，以便應對大型程序的複雜性。此外，還有許多的成員也提出了很多新特性，比如名義化的內置基本類型、同質（homogeneous）的數組類型、類（class）類型（其中的子類均為 nominal subtype）、接口（interface）類型，以及表示需要進行動態類型檢查的 any類型等。
但是，JavaScript 2.0 並未嘗試與原始 JavaScript（甚至還有尚未完成的 ECMAScript 3）完全向後兼容。
由於這個問題，各家不同的廠商在此問題上有很大的分歧，於是TC39-TG1的其餘成員決定將精力集中在為 ECMAScript 開發 XML 支持上，並中止 ES4 的工作，直到 XML 項目完成並可以確定出新的編輯為止。
雖然初版 ES4 的開發工作在 2003 年停滯了，但 Web 上對 JavaScript 的使用仍在繼續增長。不到一年內，TG1 成員就再次開始考慮設計一個被稱為「ES4」的新版本 ECMAScript 了。
老E 在 2005 年 11 月的博客文章中提到ES4的這些目標，如下所示：
- 以更強大的類型和命名支持大型編程。
- 支持自舉、自託管 和反射。
- 保證向後兼容性，一些簡化語言的更改則例外。
但是，作為此時的瀏覽器霸主，微軟幾乎沒有參與重啓新版 ES4，與 JScript 和 ECMAScript 相關的工作，在 團隊中屬於低優先級的事項。
鑑於微軟當時對 Web 瀏覽器技術缺乏戰略興趣，微軟軟件架構師Wirfs-Brock 認為 DevDiv 管理層不太可能有興趣將資源分配給與 Web 瀏覽器相關的工作，同時他也推測出的ES4新語言可能對微軟的語言和開發者產品造成嚴重的競爭威脅。
Allen Wirfs-Brock 寫了一份備忘錄，説明了這些擔憂，並建議微軟在 TG1 內部積極開展工作，試圖將 TG1 重新引導到對 ECMAScript 標準增量、非破壞性演進的道路上。
我們認為，目前 TC39-TG1 正在開發的 ECMAScript 4 規範，與目前的標準完全不同，它本質上是一種新的語言。對於一個被廣泛使用的標準化語言的修訂版來説，這樣劇烈的改動是不合適的。而且鑑於目前 ECMAScript 第三版在 AJAX 式 Web 應用中的廣泛採用，這樣的改動也是不合理的。我們認為，基於目前的語言設計工作，TC39-TG1 內部無法達成共識。然而，我們相信可以找到一個替代性的解決方案，並將這一提案作為可能的解決途徑。
我們認為 ES 相比於我們目前所看到的 ES4，應該更多地以一種零散的方式發展。從 E262-3 的發佈到 E262-4 的發佈已經過去了 9 年，這本身並不是一次性引入大量新特性的有效理由。每個特性都必須有其重要性，而且必須基於經驗來指導我們。即便如此，本文並不主張接納一個被注水的「ES3.1」（其實應該叫「ES3.01」）。我們主張現在就採用 80% 完成度的解決方案「ES3.8」，然後計劃在不久的將來，當這些需求更明確的時候，再發展到滿足新的需求。
基於以上的原因，ES4倒了
4. 繼往開來
新版 ES4 的流產，使 TC39 自 1999 年以來終於能以相對乾淨的狀態，來規劃 JavaScript 未來的演進之路。TC39 不再考慮從頭開始創造一種更好的語言，開始了一條走向成功的道路。只要花 7 年時間，就能抵達這條路的終點。
在 2008 年 8 月，ECMAScript Wiki 上出現了名為「Harmony 稻草人」的頁面，es4-discuss
郵件列表也更名為 es-discuss。在 Harmony 項目提出後，es-discuss 上爆發了關於其潛在特性的新討論。根據當時的工作流程，新的想法會在 es-discuss或 TC39 會議上提出。如果 TC39 的成員認為某個想法有價值，他們會寫出一份初步的設計或特性描述，並將其發佈到稻草人 Wiki 頁面上。隨後這個「稻草人」將在 TC39 會議上進行展示。根據委員會的反應，該想法要麼被放棄，要麼被反覆修改以繼續完善。
使用可執行、可測試的規範來表達 ECMAScript 語義的願望，從新版 ES4 的工作中延續了下來。
對於項目編輯來説，創建規範並不僅僅是一件簡單的集成任務。從理論上來説，提案應當由倡導者開發到「可以輕鬆集成到規範中」的程度。但在實踐中，這種情況很少發生。一些倡導者對規範的結構或形式不夠熟悉，無法創建可集成的偽代碼。另外一些人則沒有必要的時間或專業知識來創建詳細的語義規範。對於許多提案，Allen Wirfs-Brock 不得不設法將它們集成到規範中。這需要制定語義細節，並編寫或重寫提案在規範中的算法。
倡導者們往往會較為狹隘地關注自己的提案所定義的特性。好的提案會考慮到該特性如何與語言的現有特性交互。然而即使是最熟練的倡導者，也很難考慮他們的特性和「其他倡導者同時開發的其他提案」之間所有的潛在交互。所有特性都必須通過編輯，才能成為實際規範的一部分。所以 Wirfs-Brock 對於原有語言和所有 Harmony 提案如何結合在一起形成 ES6，有着最完整的看法。他特別關注跨越多個特性提案的交叉問題，並確保提案之間在語法和語義上的一致性。
從 1997 年的第一版初稿（圖 13）到 ES5.1 為止，ECMAScript 規範的組織結構基本沒有變化。在編寫 ES5 規範時，Allen Wirfs-Brock 發現規範中材料的基本排序令人困惑。於是他規範了術語，以及重新排列了ES2015 規範的文檔組織。
在 2015 年 3 月的會議上，TC39 [2015b] 批准了當時的候選規範，將其提交給了 Ecma GA 大會進行最終批准。Ecma GA 在 2015 年 6 月的會議上投票批准了它，並立即發佈了 ECMA-262 第 6 版，是為《ECMAScript 2015 語言規範》[Wirfs-Brock 2015a]。
