前言因为春节放假回家没有win电脑，所以才有时间静下心来看看书。这次我读了《JavaScript二十年》。本书主要介绍了该语言的诞生及其发展过程中的一些里程碑。你不会学到太多有用的知识。如果你还没有看过小红书或者《你不知道JavaScript》系列的书，建议先看完这本相对“休闲”的书。下面我将从个人理解的角度总结本书的一些主要内容，为一些想看却没时间看的兄弟节省时间。1、语言诞生1990年代初期，互联网兴起，浏览器出现在大众视野中，人人开始上网。Netscape，也就是Netscape，就是在这个时候创立的，很明显大家都想赚大钱。这个时候Web的核心还是HTML，但是这个时候大家对一种可以方便用户应用操作的脚本语言寄予厚望，所以Netscape找来了BrendanEich进来（为了方便国人，老后来用Eich)代替BrendanEich)，让他开发一种可以集成到网页中的脚本语言。恰在此时，万物之源Java问世了。Java开发公司Sun和Netscape达成协议，决定将Java集成到浏览器中。于是，网景老板现在的战略目标发生了变化。他们可能只需要一种【小语言】来补充Java。这个时候网景内部还是有很多不同的声音，主要是：他妈的Java行不行？为什么需要两种语言？不光用Java就完了，再加上一门小语言，谁用不起？到底谁来开发这个小语言，有没有大佬，在线之类的，第一个问题我很着急。那还是1995年的春天，年轻的Java对于初学者来说还是相当吃力的。于是，从多方面考虑，我们寄予厚望的Java最终倒在了16强！第二个问题，他们对标了当时的竞品微软，他们也把VisualC++卖给专业玩家，然后用VisualBasic作为辅助脚本语言，给一些菜鸟做一些[胶水]定制。这个想法非常好，以至于Netscape也复制了它。那么就剩下第三个问题了。很显然，这个时候，就需要我们的主角老E出场了。他花了10多天的时间（是的，书上就是这么说的，你现在是不是觉得自己傻了？）创造了一种新的语言，叫做Mocha，证明了它在Netscape浏览器中的可行性。1995年12月正式定名为JavaScript并发布。在草案中，JavaScript被描述为“一种对象脚本语言”，可用于编写脚本以动态地“修改Java对象的属性和行为”。它将作为“对Java的补充，以促进在线应用程序开发”。尽管Netscape和Sun在技术设计上只有表面上的相似之处，但他们试图在Java和JavaScript语言之间建立强大的品牌联系。这种名称上的相似性，以及两种语言密切相关的暗示，长期以来一直是混淆的根源。众所周知，程序员最精通CV，所以老E在最初的设计中借鉴了其他语言的很多特性。比如Lisp风格函数的一流概念，比如从Java借用的null概念，本质上表达的是“没有对象”的对象，也是后来的经典bug之一，比如条件语句，从C中借用的循环语句和非顺序控制。正如BrendanEich回忆的那样，流的break、continue和return语句，typeofnull的值是原始Mocha实现中抽象泄漏g的结果。null的运行时值使用与对象值相同的内部标记值进行编码，因此typeof运算符的实现仅返回“对象”。2.创建一个标准虽然作者是天才，但是10天时间就冲出来的新语言还是有很多问题。在JavaScript发布的第二年，微软也宣布将在IE上支持这门语言。同时，他们也开始了JScript的开发。为什么名字不一样？想想看，Netscape肯定不会把代码交给微软，所以他们只是在各自的浏览器上实现相同的逻辑，兼容相同的脚本代码。Netscape的称为JavaScript，Microsoft的称为JScript。每当Microsoft比较两种浏览器并发现同一脚本存在差异时，他们就必须对JavaScript进行逆向工程，以查看这些人在幕后编写了哪些垃圾实现，以及为什么不同的浏览器具有不同的实现。（这种相同代码在不同浏览器下表现不同的经典行为一直延续至今。）在整个JScript开发过程中，微软的人一旦发现JavaScript语言规范缺失，就会发疯dissNetscape的哥们。JavaScript风在屁股上评论说，[创建一个标准以确保在不同浏览器中的兼容性]变得越来越重要。于是，Netscape通过私交找到了ECMA国际组织的秘书长，向他提出要推动JavaScript的标准化。由于国际标准组织(ISO)认可ECMA，因此ECMA的标准可以快速成为ISO标准。1996年10月，ECMA邀请了所有有影响力的人（主要是Netscape和Microsoft的员工）参与JavaScript的讨论，并组成了一个新的Ecma技术委员会（TechnicalCommittee）。ECMA使用数字来标记其技术委员会，下一个可用的数字是39，因此本次组织会议是经典TC39会议的开始。两组人轮流发言。最后，委员会通过了一份微软员工罗伯特韦兰撰写的文件，Netscape确实迈出了一大步，而且还不如继任者。本文档是使用伪代码的概念编写的，它在足够详细地描述JavaScript语义以确保互操作性方面非常有效。那么，ECMAScript和JavaScript是什么关系呢？前者是后者的规范，后者是前者的实现。比如前者描述了内置方法A，应该实现什么逻辑，输入参数是什么类型，返回结果是什么类型。那么不同的浏览器厂商就要实现这套逻辑。不管是JavaScript、JSCript还是BScript，都必须有这个内置方法A，使用方法符合ECMAScript的定义。3.失败的改革随着Netscape、Microsoft和其他浏览器制造商在千禧年之际使浏览器变得更加有用，Web蓬勃发展。Web的成功及其继续发展的愿望催生了EcmaTC39和W3C等工作组。这些组织的一些参与者是不直接参与浏览器开发的行业专家。这些人的兴趣集中在理想化的未来网络上。这时，一些TC39参与者意识到有必要纠正原始JavaScript中的设计错误，并提供满足专业软件开发人员需求的功能，而不仅仅是非专业的脚本编写者。创建新一代ECMAScript的目标以ECMA-262第四版为中心。该版本最初在TC39中称为“E4”，后来称为“ES4”。TC39分两轮试用ES4，“第一版ES4”和“新版ES4”。自从第一次TC39会议提出向该语言添加类定义以来，人们一直在尝试向JavaScript添加新功能以应对大型程序的复杂性。此外，很多成员还提出了很多新特性，比如标称内置基本类型、齐次（homogeneous）数组类型、类（class）类型（其子类为标称子类型）、接口（interface）类型，以及例如需要动态类型检查的any类型等。但是，JavaScript2.0并没有尝试完全向后兼容原始JavaScript（甚至还未完成的ECMAScript3）。由于这个问题，各个供应商在这个问题上分歧很大，TC39-TG1的其余成员决定专注于开发对ECMAScript的XML支持，并暂停ES4的工作，直到XML项目完成并且可以使用新的编辑器为止决定。虽然原始ES4的开发在2003年停滞不前，但JavaScript在Web上的使用仍在继续增长。一年之内，TG1成员再次考虑设计一个称为“ES4”的新版本的ECMAScript。老E在2005年11月的一篇博文中提到了ES4的这些目标，内容如下：Supportlarge-scaleprogrammingwithstrongertypesandnaming。支持引导、自托管和反射。除了为简化语言而进行的一些更改外，保证向后兼容性。不过，作为此时的浏览器霸主，微软几乎没有参与重启ES4新版本，JScript和ECMAScript相关的工作在团队中属于低优先级。鉴于当时微软对Web浏览器技术缺乏战略兴趣，微软软件架构师Wirfs-Brock认为DevDiv管理层不太可能有兴趣将资源分配给与Web浏览器相关的工作，他还推测新的ES4语言可能严重对微软语言和开发者产品的竞争威胁。AllenWirfs-Brock写了一份备忘录来解决这些问题，并建议微软在TG1中积极工作，尝试将TG1重定向到ECMAScript标准的增量、非破坏性演进的道路上。我们认为，目前由TC39-TG1开发的ECMAScript4规范与当前标准有根本的不同，本质上是一种新语言。如此剧烈的变化对于广泛使用的标准化语言的修订是不合适的。鉴于目前在AJAX风格的Web应用程序中广泛采用ECMAScript第三版，这样的改变是不合理的。我们认为，根据当前的语言设计工作，TC39-TG1内部并未达成共识。但是，我们相信可以找到替代解决方案，并将此提议作为可能的解决途径。我们认为ES应该比我们目前看到的ES4更零散地发展。从E262-3的发布到E262-4的发布已经过去了九年，这本身并不是一次引入大量新功能的正当理由。每个功能必须有其重要性，并且必须基于经验来指导我们。即便如此，本文也不提倡接受一个充满水分的“ES3.1”（其实应该叫“ES3.01”）。我们提倡现在采用80%完整的解决方案“ES3.8”，然后计划在不久的将来，当这些需求更加清晰的时候，去满足新的需求。基于以上原因，ES4跌了4。新版ES4的流产，让TC39从1999年开始就可以在一个相对干净的状态下规划JavaScript未来的演进。TC39不再想着从头开始创造一门更好的语言，开始了一条路成功。走到这条路的尽头只需要7年的时间。2008年8月，ECMAScriptWiki上出现了名为“TheHarmonyScarecrow”的页面，es4-discuss邮件列表更名为es-discuss。Harmony项目提出后，es-discuss上又爆发了新的讨论，讨论其潜在的特性。按照当时的工作流程，会在es-discuss或者TC39会议上提出新的想法。如果TC39的成员认为某个想法有价值，他们会写出初步设计或特征并将其发布在ScarecrowWiki页面上。这个“稻草人”随后将在TC39会议上进行展示。根据委员会的反应，这个想法要么被放弃，要么被反复修改以进一步完善。使用可执行、可测试的规范来表达ECMAScript语义的愿望是从新ES4的工作中继承下来的。创建规范不仅仅是项目编辑的简单集成任务。从理论上讲，提案应该由倡导者开发到可以很容易地集成到规范中的程度。但在实践中，这种情况很少发生。一些倡导者对规范的结构或形式不够熟悉，无法创建可集成的伪代码。其他人没有必要的时间或专业知识来创建详细的语义规范。对于许多提案，AllenWirfs-Brock不得不尝试将它们整合到规范中。这需要计算出语义细节，并编写或重写规范中提出的算法。倡导者倾向于狭隘地关注他们的提案所定义的属性。好的建议会考虑该功能如何与语言的现有功能交互。然而，即使是最熟练的倡导者也难以考虑他们的特征与其他倡导者同时开发的其他建议之间的所有潜在相互作用。所有功能都必须经过编辑才能成为实际规范的一部分。因此，Wirfs-Brock对原始语言和所有Harmony提案如何组合在一起形成ES6有着最完整的看法。他特别关注跨多个功能提案的交叉问题，并确保提案之间的句法和语义一致性。从1997年的初稿（图13）到ES5.1，ECMAScript规范的组织结构基本保持不变。在编写ES5规范时，AllenWirfs-Brock发现规范中材料的基本顺序令人困惑。于是他规范了术语，重新整理了ES2015规范的文档组织。在2015年3月的会议上，TC39[2015b]批准了当时的候选规范，并将其提交给EcmaGA大会进行最终批准。EcmaGA在其2015年6月的会议上投票批准了它，并立即将ECMA-262的第6版发布为《ECMAScript 2015 语言规范》[Wirfs-Brock2015a]。
