《JavaScript二十年》阅读整理

前言

春节假期因为没有win电脑回家，所以才有时间静下心来看会儿书。这次读的是《JavaScript二十年》，书籍主要介绍了语言诞生以及一些阶段性的发展里程碑，能学到的有用知识不会太多，如果你还没看过红宝书或者《你不知道JavaScript》等系列书籍，建议先看完再来读这本比较”闲“的书。

下面我会以我个人的理解角度概括一下书籍的一些主要内容，给一些想看没时间看的兄弟节省一下时间。

1. 语言诞生

90年代初，互联网崛起了，浏览器出现在大众视野了，大家开始冲浪了。Netscape，也就是网景，在此时创立，很显然大家都想要捞一笔大的。

此时，Web核心还是HTML，但是此时大家都对可以方便编排用户应用操作的脚本语言有了极大的期待，于是，网景招了Brendan Eich进来（为了方便国人理解，后文用老E代替Brendan Eich），让他开发一款可以集成到网页里的脚本语言。

恰恰好在这个时候，万物起源 Java 出来了，Java的开发公司Sun和网景达成了协议，决定将Java集成到浏览器中。于是，网景老板现在的战略目标就变了，他们可能只需要一门[小语言]来补充一下Java就可以了。

此时，网景内部还是有很多不同的声音，主要是：

1. 他妈的Java到底行不行？
2. 为什么要两门语言，直接Java不就完了，还小语言补充是瞧谁不起？
3. 谁他妈来开发这门小语言，有没有大佬，在线等，很急

对于第一个问题，当时还是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的这些目标，如下所示：

1. 以更强大的类型和命名支持大型编程。
2. 支持自举、自托管 和反射。
3. 保证向后兼容性，一些简化语言的更改则例外。

但是，作为此时的浏览器霸主，微软几乎没有参与重启新版 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]。