对 ES4 的第二轮尝试

虽然初版 ES4 的开发工作在 2003 年停滞了，但 Web 上对 JavaScript 的使用仍在继续增长。不到一年内，TG1 成员就再次开始考虑设计一个被称为「ES4」的新版本 ECMAScript 了。

重置 TC39-TG1

Macromedia 于 2003 年 11 月成为了 Ecma 会员，Jeff Dyer 则成为了 TC39 的代表之一。Macromedia 此举的意图是很明显的，因为 ActionScript 3 的设计受到了 TG1 最初开发的 ES4 规范的强烈影响。对 Macromedia 而言，让 ActionScript 的设计与将来的 ECMAScript 规范保持一致非常重要，并且他们也需要 TG1 考虑来自 ActionScript 的需求和先例。

2004 年春季，Mozilla 基金会发布了 Firefox 浏览器的技术预览版，有望在年底之前发布 Firefox 1.0。Mozilla 的首席技术官 Brendan Eich 对开放 Web 的未来感到担忧。此时业界对基于浏览器的 Web 应用的兴趣正在迅速增长，但当时最新的浏览器标准并不足以支持交互足够丰富的应用。像 Flash 和微软 WPF 与 .NET 这样封闭的专有应用平台，正在竞相取代 HTML / CSS / JavaScript 的 Web 技术栈，但负责开放 Web 的标准化组织并未响应这一挑战。1998 年，W3C [W3C 1998] 决定停止发展 HTML，转而支持基于 XML 的替代方法。但是 XHTML 在语法和语义上都不兼容 HTML，并没有被浏览器厂商和 Web 开发者普遍接受。同样地，Ecma TC39-TG1 对发展 ECMAScript 规范的尝试也陷入困境，它的注意力已经转移到了设计 ECMAScript 的 XML 支持上。Web 技术社区的一些成员担心「ECMAScript 已死」[Schulze 2004b]。

在这个时候，Brendan Eich [2004] 站了出来，促进了 WHATWG（Web 超文本应用技术工作组）[Hickson 2004] 的成立，这个工作组专注于 HTML 的未来。他还开始重新介入 TG1。Eich 于 2004 年 3 月会见了 Ecma 秘书长 [Marcey 2004]。当年 5 月，Mozilla 基金会申请了 Ecma 会员资格。在 2004 年 6 月，Eich 自 1998 年 2 月以来首次参加了 TG1 会议 [Schulze 2004a]。

在 6 月的会议 [Schulze 2004b] 上，TG1 的召集人（Convener）职责从微软的 Rok Yu 移交给了 Macromedia 的 William Schulze。Jeff Dyer 则成为了 ECMA-262 的编辑。代表们再次致力于完成 ECMAScript 规范的第四版，但决定不再继续投入 Waldemar Horwat 的初版 ES4 草案。根据 Schulze 的报告，「初版 ES4 太过于笼统而宽泛，难以完成或获得采用」。取而代之地，成员们同意采取「一种更为增量的途径」[Schulze 2004a]。基于这种方式，新版语言可以集成到包括 ActionScript 在内的现有实现中。被列为候选待集成的特性包括：包、命名空间、条件属性、运行时类型检查，以及 XML 支持。这份列表包括了原有初版 ES4 草案中一些最复杂的部分，但成员们仍然认可了新版 ES4 的 12 个月开发周期。Dyer 同意准备一份介绍变更计划的草案，以在 2004 年 10 月的会议上进行介绍。

TG1 暂时还无法处理这些新需求。在 2004 年下半年和 2005 年的大部分时间里，委员会的大部分注意力都集中在修订 E4X 规范 [Schneider et al. 2005] 上，这是 ISO 快速通道流程的一部分。直到 2005 年 10 月，委员会才对新版 ES4 开始了认真的工作。但在这段时间里，Brendan Eich 熟悉了 ECMAScript 当时的标准化状态，并开始在会议演讲和博客文章中公开表达其对下一版的想法 [Eich 2005a, b]。在 2005 年 9 月的会议 [TC39-TG1 2005] 上，Eich 成为了 TG1 的召集人，开始推动新版 ES4 的开发。

重新设计 ES4

在 2005 年 10 月的博客文章中，Brendan Eich [2005d] 列举了下一轮 ES4 工作的四个目标，如下所述：

• 让第 4 版重新朝向当前的语言发展。这样一来，「基于原型的委托」就不再属于残留的兼容模式，而是组成语言对象系统的动态部分。这个对象系统中所包含的类，可以带有不会被隐藏或覆盖的固定成员。
• 允许标准实现者让语言自举62，从而表达出所有「原生」对象使用的「元对象协议」黑魔法（参见 ECMA-262 第 3 版第 15 节），包括读取、设置、调用 、构造等操作，以及对属性标记（如可枚举性）的控制。
• 加入类型注解以支持大规模编程，前提是不破坏现有版本与新版本之间的互操作性。XUL63 框架和现代 Web 应用都越来越需要这样的特性。
• 修复其他长期困扰着几乎所有 JS 开发者的问题。

据 Eich 所述，他的预期是在 2006 年底之前完成这项工作，其中包括初步实现以及对互操作性的测试。

Brendan Eich [2005d] 在 2005 年 11 月的博客文章中简化了这些目标，如下所示：

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

他还指出，标准的目标并不是让 ECMAScript 更像 Java 或任何其他语言，也不是让 ECMAScript 更易于被优化。在随后的演讲中，Eich [2006a] 认可了对初版 ES4 规范的批评，这其中也包括了对于是否需要「声明式的静态类型」或者「类定义」的质疑。对此 Eich 反驳说，对此什么都不做是不行的。他认为，随着 Web 开发者构建出日益复杂的应用，ES3 语言在未来十年内的扩展性会显得很差。他特别指出，要想支持这样的应用，需要的是一种保证语言不变性（invariance，描述类型严谨程度的概念，译者注）的类型系统，这样的类型系统可以选择性地执行静态检查。不过做这种改变的机会只有一次，所以现在就是时候了。

Brendan Eich 乐观地认为，在编程语言规范和类型系统领域的现代研究，可以帮助解决初版 ES4 原始工作中某些领域的问题。在 2006 年初，他招来 Dave Herman 加入了 TG1 新版 ES4 的设计团队64。Herman 是美国东北大学的博士研究生，当时正致力于开发 ES3 的操作语义（operational semantics，用于保证程序在数学上严谨性的概念，译者注）。通过 Herman 的推荐，Eich 还邀请了圣克鲁斯大学教授 Cormac Flanagan 加入。Flanagan 是混合类型系统 [Flanagan 2006] 领域的专家。大约在同一时间，Opera Web 浏览器上的软件架构师 Lars Thomas Hansen 成为了 TG1 的经常性参与者。Herman、Hansen 和 Flanagan 都与美国东北大学的编程语言研究社区有着直接或间接的联系。

图 26. 2006 年新版 ES4 的核心设计团队。

2005 年末，TG1 为新版 ES4 项目制定了每周电话会议和每月面对面会议的时间表。图 26 列出了 2006 年的新版 ES4 核心设计团队。这些人定期参加会议，参与关键决策，并不断做出重要贡献。来自 Adobe、Mozilla 和其他组织的其他人员偶尔会参加会议和（或）做出贡献，但很少积极参与这个项目。

在 JS2 / ES4 的第一轮开发中，要想进行与现有 ECMAScript 程序不兼容的更改是非常容易的。它假定在浏览器中，HTML <script> 元素里的版本信息，可以用来选择语言的不同版本。在与新版 ES4 有关的新工作中，人们进一步地意识到了变更的潜在影响，但仍然希望能够通过版本控制的方式，来纠正委员眼中属于早期 JavaScript 设计错误的内容。Brendan Eich 曾经在他的博客文章和演讲中谈及这种可能性，但也有一些 TG1 成员提出了反对意见。Douglas Crockford 代表雅虎在 2006 年 7 月的 TG1 会议 [TC39-TG1 2006c] 上指出，「向后兼容是困难且重要的」。不过对于雅虎来说安全还是最大的问题。如果是为了解决与安全相关的问题，那么也可以忍受后向的不兼容性。微软的 Pratap Lakshman 则表示：「向后兼容属于最高优先级。除非为了修复安全性问题，否则向后兼容性不应该被破坏。」

2005 年，Brendan Eich 在 ICFP（函数式编程的学术会议，译者注）发表了纪念 JavaScript 十周年的主题演讲。演讲后的问答环节中，他对 Python 做出了积极的评价 [Danvy 2005]。他甚至还推测对于较大规模的 Web 脚本来说，Python 可能比 JavaScript 更好。在接下来的一年里他都在做游说，希望在新版 ES4 中再加入一些根据等价的 Python 特性直接建模的特性，包括迭代器、生成器、解构g赋值和数组推导式。他还提倡使用具备块级作用域的 let 和 const 关键字来声明变量，从而替代函数级作用域的 var 声明。在很大程度上，它们与人们为新版 ES4 提出的其他（所谓）更复杂的「大规模编程」特性并没有关系。这些特性被添加到了基于 SpiderMonkey 的 JavaScript 1.7 引擎 [Mozilla 2006a] 中，相应的 Firefox 2 浏览器版本于 2006 年 10 月发布。但是这些特性未被其他浏览器接纳，因此并未在 XUL 之外的地方获得广泛的使用。

Eich 担心其他浏览器厂商（尤其是微软）会选择非常缓慢地接纳新版 ES4 的 JavaScript 改进。另外还有一个令人担忧之处，那就是 JavaScript 引擎可能无法继续提高性能，满足不了 AJAX Web 应用涌现出的需求。有种能解决这两个问题的方法，即打造出支持设想中新版 ES4 规范的高性能开源 JavaScript 引擎。为此，Eich 说服了 Adobe 基于开源许可将其 AVM2 引擎实现贡献给了 Mozilla。Mozilla 将获得的代码库命名为「Tamarin」[Mozilla 2006b]。在后面几个月中，Mozilla 发布了 [Eich 2007a] 两个项目：一个是旨在用 Tamarin 代码库替代 SpiderMonkey 的 ActionMonkey，而另一个是基于 Tamarin 的 JavaScript 引擎 ScreamingMonkey，它可以当作 Internet Explorer 的第三方插件扩展来安装。这两个项目都没有完成。

在执行这些工程行动之际，TG1 同时也在继续致力于新版 ES4 的设计。新版 ES4 的主要目标是提供一种类型系统和类型注解符号，用来在大型程序中验证对复杂数据抽象的使用。只要是恰当地写出的程序，都应该能在部署前做静态类型分析。但这样的类型系统不仅需要能处理新程序和现有未加注解的程序，还要能处理当前语言所支持的对象动态结构变化。在 2006 年的大部分时间里，委员会都在理解这些需求的含义，并尝试设计出一种类型系统来适应它们 [TC39-TG1 2006a, d]。

委员会的工作起点，是 ActionScript 3 规范 [Macromedia 2005] 中具备非正式描述的类型系统。这是一个名义化类型系统，其中的类和接口类型与 Java 类似，而泛型则是在这基础上加入的。ActionScript 3 支持为声明添加类型注解，而对于缺少显式类型注解的声明，语言还引入了一种通用类型。ActionScript 3 规范没有明确加入「函数子类型」的概念，并且对类和接口子类型的定义也并不完整。语言还具有严格模式，这个模式下会使用具有类型注解的声明和有限的类型推断，来执行提前（ahead-of-time）的静态类型检查。另外也有一种标准模式，可以用来根据类型注解来动态验证实际数据值。

Dave Herman 和 Cormac Flanagan 早期提出的建议，是使用契约模型（contract model）[Findler and Felleisen 2002] 来更好地统一严格和标准模式，以及类型化和非类型化的声明。随着工作的进行，结构化类型（structural type）[TC39 ES4 2006d] 也被加入了进来，用于处理对象和数组字面量。一并加入的还有用于处理数组类型的参数化类型。TG1 在内部67 Wiki 网站 [TC39 ES4 2007f] 上为此考虑并记录了许多可选的方法 [TC39 ES4 2006b]。Herman 和 Flanagan 还试验了类型系统的形式化 [TC39 ES4 2007a]。到 2007 年初，语言设计仍不完整，但已演变到覆盖了许多现代类型概念，包括函数类型和协变 / 逆变（co/contra-variance）[TC39 ES4 2007b]。语言还需要支持可选类型（optional typing）和历史遗留的动态类型程序，这个现实需求一直是复杂性的重要来源。

在整个 2006 年和 2007 年的大部分时间里，TG1 继续致力于制定新提案和完善现有提案，最终在内部 Wiki 上整理出了一份列表。这其中包括了 54 份已批准的提案，它们都被规划进了新版 ES4 规范里。另外的 26 个提案则被推迟或删除。

在 Brendan Eich 发现了 Dave Herman 介绍如何对 ES3 的形式化语义进行文档化实验的网页 [Herman 2005] 后，Herman 也被招募进了 TG1。2006 年 2 月的 TG1 会议 [TC39-TG1 2006b] 上，Herman 介绍了用于规范化编程语言的形式化技术。他解释说，除了为实现者提供指导之外，形式化的规范还提供了一种在规范中查找和纠正错误的方法。有人担心 ECMAScript 实现者和规范的其他使用者是否能阅读这种形式化的规范。对此 Herman 认为，基于操作语义的形式化是可以变得非常易读的。在接下来的几个月中，Herman 尝试使用 Maude [Clavel et al. 2003]、Stratego [Visser 2001] 和 PLT Redex [Matthews et al. 2004] 等工具来确定 ECMAScript 的语义，但最终发现它们都不够令人满意。在同一时期，TG1 还讨论了 [TC39-TG1 2006e] 根据参考实现（Reference Implementation）来定义语言的可能性。还有一种可能性是专门为 ECMAScript 设计一种新的形式化规范语言。在 2006 年 10 月的会议上，TG1 讨论了这种语言的可能语法和语义。最后 Cormac Flanagan 指出，工作组现在已经在讨论定义两种语言（规范语言和新版 ECMAScript）的工作。于是工作组很快同意使用现有的语言来为新版 ES4 编写定义解释器，并迅速决定使用 SML68 语言 [Milner et al. 1997]。到 11 月中旬，TG1 已经为此搭建了工具和基础架构，相关成员也在着手编写解释器。Herman 和 Flanagan [2007] 描述了这对委员会工作风格的影响，如下所述：

在我们选择了确定性的解释器后，委员会的互动方式就发生了很大变化，从每月一天半的讨论型会议转为了为期 3 天的 hackathong。这中途也会进行技术讨论，涉及语言设计和实现时的各种极端情况。这些问题都被逐一发现和解决。

阻力

微软几乎没有参与重启新版 ES4。虽然 DevDiv 在组织上远离了负责 IE 的微软 Windows 团队，但 JScript 的开发始终由 DevDiv 负责。在 2000 年初，DevDiv 为支持 .NET 计划进行了重组，其中的 C# 产品部门同时负责 JScript .NET 和 IE 中更传统的 JScript 引擎。这也包括了参加 ECMAScript 标准化活动的责任。但由于客户对 JScript .NET 的接受程度较弱，而且 Windows 团队对于增强 IE 的兴趣不大，因此与 JScript 和 ECMAScript 相关的工作，在 C# 团队中属于低优先级的事项。

在 2000 年代，微软通常将战略上重要的开发工作放在华盛顿州 Redmond 市的总部里，并经常将更多的战术项目分配到世界各地的其他分部中。在 2006 财年（2005 年 7 月至 2006 年 6 月）里，微软 DevDiv 决定将所有与 JScript 和 ECMAScript 相关工作的职责交接给位于印度 Hyderabad 市的印度研发中心（IDC）。DevDiv 之前已经将类似 Java 的 J# .NET 产品交接给了 IDC [Prasanna 2002]。到 2006 年春季，交接工作得以基本完成。在 TG1 上代表微软的任务，则交给了曾经在 J# 团队工作过，并参与过 Ecma C# 标准工作组 TC39-TG3 的 Pratap Lakshman。Lakshman 在 2006 年 4 月第一次远程参加了 TG1 会议，并开始参加电话会议和一些面对面的会议。但在此期间，他并不是新版 ES4 开发工作的重要贡献者。

本文作者之一 Allen Wirfs-Brock 于 2003 年加入微软，担任软件架构师，负责研究新 IDE 体系结构的探索性项目。在加入微软前，他已经在 Smalltalk 编程语言和开发环境方面工作了二十多年。Wirfs-Brock 曾是首个商用 Smalltalk 虚拟机实现 [Caudill and Wirfs-Brock 1986] 的首席开发者。他致力于增强 Smalltalk 的特性以支持大型编程，设计了标准的 Smalltalk 异常处理系统，并编写了 ANSI Smalltalk 标准 [ANSI X3J20 1998] 中的语言定义部分。

到 2006 年底，IDE 项目似乎已经进入了正轨，Wirfs-Brock 也开始寻找新的机会。这时 DevDiv 内部对于动态语言的兴趣正在增加。由于还没有单独的 DevDiv 产品组负责动态语言，各个产品组的经理都抢着想揽下这份工作。Wirfs-Brock 当时担任资深架构师，向 Visual Basic 产品组经理 Julia Liuson 汇报，为她提供动态语言技术和机遇方面的建议。

Allen Wirfs-Brock 的新岗位从 2007 年 1 月的第一周起开始。在一次偶然的谈话中，Liuson 问他是否了解 JavaScript。Wirfs-Brock 回忆说他的回复大致是这样：「我不太了解，只知道这是一种用于网页的动态语言，我认为它与 Self 有一定关系。」随后 Liuson 将显示器转了过来，给他看了一封她刚刚收到的电子邮件，问他是否有什么想法。

这封邮件是 Pratap Lakshman 发给所有 DevDiv 产品组经理的，希望获知他对 Ecma TC39 正在开发的一个新 JavaScript 标准所应采取的立场。据 Wirfs-Brock 回忆，Lakshman 的信息说新的标准基于 Adobe Flash。与当时的浏览器相比，这将会是个实质性的变化。Lakshman 说，TC39 正在开发的是一门强大的语言，对 Web 来说可能太复杂了。他还列举了一长串新特性和变化，包括基于类的静态类型、结构化类型、参数化类型，以及方法重载。他还说，修订后的语言将通过 Standard ML 编写的参考实现来定义。

Allen Wirfs-Brock 回复 Julia Liuson 说，这听起来像是一次彻底的重新设计。根据他的经验，通过增加静态类型来改进动态语言的尝试很少成功。他对 JavaScript 或 Web 开发还不够了解，无法给出更确切的意见。不过，他提出要进一步研究一下。

Wirfs-Brock 花了几天时间来熟悉 JavaScript、当时的 ES3 规范以及公开 Wiki 快照中的 TG1 提案 [TC39 ES4 2007f]。他与 Lakshman、IE 团队的软件架构师和从事 Web 应用开发的微软工程师都进行了交谈。他意识到 JavaScript 在 Web 上发挥的作用，明显属于 Richard Gabriel [1990]「Worse Is Better」理念的实例。它最早只是个最低限度上的创造，并以一种分散的方式成长，现在则已经深深地根植在了 Web 之中。相比之下，新版 ES4 的努力在 Wirfs-Brock 看来，则属于被 Gabriel 称为「做正确的事」的项目，不太可能获得成果。哪怕取得了成果，也会对 Web 造成很大的破坏。作为结论，他认为在技术上负责任的做法，是尝试让 ECMAScript 的演化重新回到增量演进的道路上。

鉴于微软当时对 Web 浏览器技术缺乏战略兴趣，Wirfs-Brock 认为 DevDiv 管理层不太可能有兴趣将资源分配给与 Web 浏览器相关的工作。他决定在向 DevDiv 内部公开时，需要关注新版 ES4 倘若成功所可能带来的后果。他确定的主要关注点是 Adobe 在 ActionScript 3 语言定义和虚拟机方面的贡献。DevDiv 特别关注的地方是 .NET 平台和 C# 旗舰语言，这些产品的主要客户是企业级应用的开发者。虽然 .NET 的主要竞争对手是 Sun 公司的 Java 平台，但 DevDiv 也开始将 Adobe 公司基于 ActionScript 的 Flash 和 Flex 产品视为 .NET 的竞争对手。Wirfs-Brock 预计新版 ES4 如果成功落地，可以将 ActionScript 转变为一线企业级语言，其功能和实用性可以与 C# 或 Java 相媲美。基于这一点，再加上 JavaScript 作为 Web 开发主要语言的标准化，可以推测出新语言可能对微软的语言和开发者产品造成严重的竞争威胁。

Allen Wirfs-Brock 写了一份备忘录，说明了这些担忧，并建议微软在 TG1 内部积极开展工作，试图将 TG1 重新引导到对 ECMAScript 标准增量、非破坏性演进的道路上。到 1 月中旬，这个建议获得采纳，Wirfs-Brock 则被授权执行该建议。2007 年 1 月 18 日，Pratap Lakshman 在 TG1 内部邮件列表上发布了一条消息 [TC39 2003]，介绍 Wirfs-Brock 为新的微软 TG1 代表。

3 月份的 TG1 面对面会议将由微软主办，Wirfs-Brock 决定在这次会议上首次参会。但他还觉得，必须尽快打消委员会对「微软支持新版 ES4 工作」态度的认识。他要求 Pratap Lakshman 在 2 月的会议上传达这一信息。Lakshman 照做了，并在 TG1 的内部 Wiki 上发布了一个页面 [Lakshman 2007a]，提出了一种描述简化的 ES4 浏览器模式（browser profile）的设想。他报告说自己收到的回应相当不友好，但在一次茶歇时间，Douglas Crockford 找到了他，提出雅虎愿意和微软一起反对新版 ES4。

Allen Wirfs-Brock 联系了 Douglas Crockford，他们同意一起合作制定微软 - 雅虎的联合提案，以替代新版 ES4 项目。Crockford [2002d] 此前曾发布过一小套关于修改 ECMAScript 语言的建议，其目的是通过纠正原始设计中的错误和不便，从而使语言「更好一点」。Wirfs-Brock 和 Crockford 同意将这些建议作为联合提案在技术上的出发点。Pratap Lakshman 则提出了一份进行最小化修改的提案 [Lakshman 2007b]，其中能纳入 Crockford 所建议的许多 ES3 改动，相当于他对自己「浏览器模式」设想的后续行动。同时，Wirfs-Brock 与 Crockford 和 Lakshman 合作，起草了一份更正式的提案，并在微软和雅虎内部流传，以供内部批准。在 3 月 21 到 23 日的 TG1 会议前，他们于 2007 年 3 月 15 日发布了提案 [Crockford et al. 2007]。Crockford 将提案通过 TG1 的内部邮件列表进行了分发。

这份提案名为《关于重新聚焦 TC39-TG1 对 ECMAScript 第三版规范维护的提案》，其开篇段落如下：

我们认为，目前 TC39-TG1 正在开发的 ECMAScript 4 规范，与目前的标准完全不同，它本质上是一种新的语言。对于一个被广泛使用的标准化语言的修订版来说，这样剧烈的改动是不合适的。而且鉴于目前 ECMAScript 第三版在 AJAX 式 Web 应用中的广泛采用，这样的改动也是不合理的。我们认为，基于目前的语言设计工作，TC39-TG1 内部无法达成共识。然而，我们相信可以找到一个替代性的解决方案，并将这一提案作为可能的解决途径。

这份提案建议，TG1 应围绕三个工作项目进行重组。第一个工作项目是维护当时的 ECMAScript 语言，即由第三版规范定义的 ECMAScript 语言。维护工作将包括：澄清第三版规范中未明确的部分，纳入新特性（如 Mozilla 的 JavaScript 1.6 / 1.7 中的新特性），以及一些如 Crockford 所列举的小型修正和改进。第二个工作项目是为 ActionScript 起草一份标准定义。第三个工作项目是为浏览器定义一种新的编程语言，这门语言可以与 ECMAScript 共存，同时不受 ECMAScript 兼容性的限制。提案还提出了将工作项目二和三合并的可能性。它建议将这两者分配给一个新的 TC39 工作组，而不是 TG1 工作组。

正如预期的那样，TG1 内部邮件列表69上对此的反应普遍是负面的，但它确实显示出苹果的 Maciej Stachowiak [2007b] 也对新版 ES4 的发展方向持保留意见。Brendan Eich [2007b] 是最有分量的回应者，他为静态类型和其他新版 ES4 的特性辩护，认为这些特性对于增强性能和大型应用的结构化至关重要。他还质疑了微软和雅虎提出这份提案的动机 [Eich 2007c]。

随着 3 月会议日期的临近，电子邮件上的讨论愈演愈烈。Pratap Lakshman 要求将会议第二天的大部分时间用于讨论微软和雅虎的提案。Brendan Eich 反驳说讨论一个小时就应该足够了。他和 Jeff Dyer 都表示希望将会议的大部分时间继续作为新版 ES4 的 hackathon。并且 Eich 和 Dyer 都认为，新版 ES4 的开发代表了微软帮助建立的 TG1 长期以来形成的共识，并质疑微软和雅虎现在试图打破这一共识是否合适。Allen Wirfs-Brock 对此回复说，现在共识已经被打破了，因为微软和雅虎是 Ecma 三个标准会员（Ordinary Member）中的两个，他们都经常参加 TG1。

3 月份会议第二天 [TC39-TG1 2007c] 的出席人数比平时多。除了 Allen Wirfs-Brock 和 Pratap Lakshman 外，微软的代表还有 Scott Isaacs 和 Chris Wilson。Isaacs 是微软「live.com」的框架架构师，还是 DHTML70 的初始开发者之一。Wilson 则是 Internet Explorer 的平台架构师，并积极参与 W3C Web 标准的制定。Isaacs 和 Douglas Crockford 都谈到了在浏览器 ECMAScript 实现的互操作性不佳的情况下，Web 应用开发上的困难。Crockford 认为，更完整的 ES3 级特性规范将有助于消除互操作性问题，从而提高 Web 的稳定性。Isaacs 特别关注的是，应当尽量减少新的语言语法扩展，因为这些新的扩展可能导致旧浏览器在执行新网页时出现解析错误。Isaacs 和 Crockford 都强调了 Web 应用中安全和隐私功能的重要性。对此 Eich、Dyer 和 Graydon Hoare 则反驳说，要想构建更稳定、更安全、更高性能的浏览器编程环境，新版 ES4 的类型系统是必需的基础。Wirfs-Brock 认为，进化后的「ES3.1」规范将有助于稳定 Web，并为 ES4 的实现和流行提供时间。Eich 担心这只是一种拖延策略，让微软有时间建立他们基于 .NET 的富互联网应用平台71，从而与基于标准的 HTML / CSS / JavaScript 平台进行竞争。他警告说，现在社区里已经有很多人对 ES4 充满了热情，如果微软和雅虎强行推迟开发 ES4，会给微软和雅虎带来负面影响。

最终，大家一致认为，开发「ES3.1」规范可能有一定的价值，微软和雅虎可以在 TG1 的背景下进行工作。这也就是 Wirfs-Brock 在筹备会议时所希望的结果。新版 ES4 的支持者坚持认为 ES3.1 必须是新版 ES4 的一个子集，其规范必须使用为新版 ES4 开发的规范风格。Wirfs-Brock 对这些限制并不太担心，因为他仍然认为新版 ES4 规范不太可能完成并发布。

会后，Pratap Lakshman、Allen Wirfs-Brock 和 Douglas Crockford 开始着手定义 ES3.1 项目。Wirfs-Brock 和 Crockford 在 3 月 29 日举行了会议，并同意 Lakshman 应起草一份初步提案，在 4 月 TG1 会议前分发。Crockford 提出了一些设计准则，并建议 3.1 规范采用与 ES3 规范相同的风格。这与 3 月会议上达成的共识有冲突，但在新版 ES4 规范的最终形式尚未确定的情况下，使用相同的规范形式也是有问题的。

4 月 15 日，Pratap Lakshman 以《ES3.1 提案工作草案》[Lakshman et al. 2007] 为题，在 Wiki 上发布了一些页面。它列出了一系列目标、前后向兼容性要求，以及设计准则（图 27）。它还包括了大约 20 个修复、修改和新特性的描述，这些特性都是候选的，其中有许多来自于 Douglas Crockford 的《ECMAScript 修改建议》文档。他于 4 月初更新了这份文档，并在 ES3.1 开发过程中进行了两次更新 [Crockford 2007b, c, d]。

目标
1. 通过重写规范来提高实现的一致性，提高规范的严谨性和明确性，并纠正已知的模糊点或不够规范之处。
2. 在标准中添加已被实现和使用的常见扩展（特别是大多数 JavaScript 1.6 和 1.7 的特性）。
3. 纳入增量扩展，着重支持当前的使用经验和最佳实践。
4. 采用影响较小的语言修改，纠正已知的性能或可靠性问题。
5. 将确定有问题的特性标记为废弃。
6. 最大限度地提高 ES3 和 ES3.1 之间，以及 ES3.1 和 ES4 之间的前向和后向兼容性。
设计准则
1. 主要重点是纠正已知的错误和澄清已知的歧义。
2. 只有在以下情况下才考虑新特性：
  a. 不引入新的语法
  b. 提供重要的新价值
3. 倾向于现有实现方案中已被证明的特性。
4. 如果已有特性会造成重大的安全性或可靠性问题，则可能被标记为废弃。
  a. 考虑废弃那些会导致重大性能问题的低价值特性。

图 27. ES3.1 的初始目标和设计准则 [Lakshman et al. 2007]。

在 4 月的会议 [TC39-TG1 2007a] 上，委员会讨论了 ES3.1 工作草案。新版 ES4 开发者的主要关注点是 ES3.1 工作与新版 ES4 规范之间的关系。他们希望 ES3.1 工作遵循他们打算在新版 ES4 中使用的 ML 参考实现规范技术。ES3.1 小组反驳说，为一个规范的维护版本完全改变规范技术，其意义似乎并不大。Jeff Dyer 最后建议，鉴于观点的不同，ES3.1 的人应该继续他们手头的工作。但他也提出了警告，认为在 ES3 规范的背景下所做的工作，对小组的其他成员没有什么价值。

在 2007 年春夏之交的其余时间里，这两个小组基本上都持续在各自的项目上工作。ES3.1 小组分析了现有的 ES3 规范及其实现，以确定由于规范化程度不够或未能遵循规范而存在的互操作性问题 [Lakshman 2007c; Wirfs-Brock 2007b; Wirfs-Brock and Crockford 2007]。新版 ES4 小组则以其 ML 参考实现为工具，继续完善他们的各种提案。

新版 ES4 项目的时间安排仍然非常紧迫。在 2007 年 5 月初，一份提交给 Ecma 共同管理委员会的报告 [Miller 2007] 指出，新版 ES4 规范的最终草案将在 2007 年 10 月前完成，以便 Ecma GA 大会在 12 月批准它。2007 年 6 月 8 日，Dave Herman [2007; Appendix K] 在 Lambda the Ultimate72 博客上宣布 ES4 参考实现的「M0」版本73已经可用。

在 6 月的会议 [TC39-TG1 2007b] 上，有人呼吁立即启动 ES4 的规范编写进程。但当时仍有重大的技术设计问题未能解决，也经常发现新的问题。例如在 7 月的会议 [Eich 2007d] 上人们意识到，新版语言在对结构化类型做运行时类型检查时还有重大问题。

9 月 7 日的 TG1 召集人报告指出，想在 2007 年完成新版规范是不现实的，新的完成日期被推后一年至 2008 年 9 月。报告中还介绍 Lars Hansen 将担任新版 ES4 的编辑。这份报告既没有提到正在进行的 ES3.1 工作，也没有提到雅虎和微软对新版 ES4 的保留。

9 月会议 [TC39-TG1 2007d] 的目标之一，是接受、拒绝或推迟 ES4 Wiki 上所有未决的新版 ES4 提案。从新版 ES4 工作组的角度来看，这包括了被标记为「维护 ES3」的提案，这是 ES3.1 工作的总括性提案。Jeff Dyer 在会上的立场是，这份提案需要在当天被接受或拒绝（并在 Wiki 上标明）。如果被否决，该提案将不再作为 TG1 的工作项目。从会议记录中可以看出，他不认为提案有可能被接受。Brendan Eich 的立场则更为微妙。作为新版 ES4 的公开支持者，他认为 ES3.1 的努力让他分心，并非常怀疑微软的动机。他不希望 ES3.1 的开发与新版 ES4 竞争，并建议 ES3.1 的支持者们考虑离开 TG1，看看 TC39 是否愿意为他们建立一个新的任务组。然而作为 TG1 的召集人，他希望找到一种避免组织分裂的方法。他建议，ES3.1 小组的工作成果可以作为 Ecma 技术报告来发表，或发表为其他一些不太正式、非 ISO、非标准轨道的文档。整个谈话过程非常激烈，对新版 ES4 和 ES3.1 的支持者来说都很紧张。Pratap Lakshman 一度沮丧地表示：「不论是全部还是部分，我们都既不支持也不同意目前的 ES4 提案。我们打算继续与有兴趣的任务组成员合作，制定一份对现行规范进行更多增量修订的提案。」尽管这不是个非常政治化的声明，但它也反映了微软的立场，只是在范围涉及全部新版 ES4 这一点上略有出入。最后「维护 ES3」提案状态的问题得以变通解决，方法是将关于 ES3.1 的页面从 Wiki 的「提案」命名空间下移到了新的「ES3.1」命名空间下。然而，ES3.1 和新版 ES4 的支持者们在目标上的冲突仍然存在，相关言论很快就公开化了 [Kanaracus 2007]。

寻求和谐

2007 年期间，活跃的 TG1 参与者开始增加，这其中部分原因在于 ES3.1 和新版 ES4 小组都努力鼓励新成员和目前不活跃的成员参加会议。在当年春季，先前并不活跃的 TG1 成员 IBM 和苹果，也开始更经常地派代表参加 TG1 会议，并参与在线讨论。Google 作为标准会员加入了 Ecma，并任命 Waldemar Horwat 为其 GA 代表和 TG1 代表领导。Dojo 基金会作为非营利会员加入，由 Alex Russell 和 Chris Zyp 代表。Allen Wirfs-Brock 和 Douglas Crockford 都鼓励对象能力（OCAP）[Miller 2006] 语言74专家 Mark S. Miller 参与进来。Miller 曾在 Google 工作，他开始以 Google 代表的身份参加会议。一些新的与会者为小组带来了属于 Web 开发者的视角，在以前小组一直是由语言设计者和引擎实现者主导的。

2007 年初，TG1 的目标是在 10 月前完成新版 ES4 规范。这一目标没有实现，但 Lars Hansen [2007e] 在 10 月完成了一份文件，其初稿 [Hansen 2007b] 名为《ECMAScript 第四版语言概述》。这不是一份详细的规范，而是对语言主要特性的 40 页总结。其摘要的第一段是这样描述新版 ES4 语言的：

第四版的 ECMAScript 语言（ES4）代表了 ECMA 在 1999 年批准的 ECMA-262 标准语言第三版（ES3）的重要演变。ES4 与 ES3 兼容，并增加了重要的设施，用于大型程序设计（类、接口、命名空间、包、程序单元、可选的类型注解，以及可选的静态类型检查和验证）、演化式编程和脚本编写（结构化类型、鸭子类型、类型定义和方法多重派发）、数据结构构建（参数化类型、getter / setter 和元级方法）、控制抽象（适当的尾调用、迭代器和生成器）以及类型自省（类型元对象和堆栈标记）。

最终证明，这份文档是对人们设想中新版 ES4 语言的最佳整体描述。然而，Allen Wirfs-Brock [2007c] 和 Douglas Crockford [2007a] 都对「ECMAScript 第四版」这一名称被不加限定地使用表示担心，这暗示了其所描述的语言已非常接近最终批准的 Ecma 标准。此外这份文档在导言中宣称，其整体设计代表了 Ecma TC39-TG1 的共识，并未提及任何 TG1 中对新版 ES4 在设计上的不同意见。在沟通后，Hansen 同意在文档标题前加上「拟议」字样，并在文档导言中插入了一段话，指出 TG1 中有少数成员对该设计的标准化表示反对。在新版 ES4 小组成员为分发概览文件和参考实现代码而建立的网站 [TC39 ES4 2007c] 上，人们也提出了类似的意见。这些事件增加了 ES3.1 支持者对新版 ES4 支持者们的担忧，担心他们继续公开宣传 ES4，同时继续无视或贬低 ES3.1 的开发。

Allen Wirfs-Brock 经常与微软的企业标准小组保持联系，其中包括 Ecma 共同协调委员会（CC）的成员 Isabelle Valet-Harper。协调委员会 [Ecma International 2007b] 关注的是，TG1 将外部托管的私有 Wiki 作为文档和会议记录的载体，Ecma 秘书处和一般会员无法访问它们。秘书处要求 TG1 将议程、会议记录和重要文档格式化，以便发表到对 Ecma 内部成员专用的网站上。TG1 决定，对此最简单的办法是将整个 TG1 的 Wiki 网站都设为公开可读 [TC39 2007]。

在 2007 年 10 月的 Ecma CC 会议 [Ecma International 2007a] 上，委员会讨论了 TC39-TG1 的运作问题。在 2001 年之前，TC39 的章程只涉及 ECMAScript。2001 年它进行了扩张，包含了更多的编程语言和平台，其中每种都由一个基本独立的 TG 任务组负责。ECMAScript 的开发工作则交由 TC39-TG1 负责。Ecma 秘书处一般侧重于监督和支持 TC 技术委员会一级的活动，而非监督 TG 工作组。在 2007 年，TG1 工作组的独立运作似乎缺乏 TC39 或秘书处的监督。一些协调委员会成员担心，TG1 可能没有完全遵守 Ecma 的政策和程序。会议还讨论了 TG1 工作组内部据称对其当时的工作缺乏共识的问题。人们讨论了一种可能的解决办法，那就是将 TC39-TG1 升格为正式的 TC 技术委员会，这样它将得到秘书处更大的监督。时任 Ecma 主席 John Neumann 同意出席 2007 年 11 月的 TG1 会议，试图使情况明朗化。

这次会议 [TC39 2007] 主要用于表达协调委员会的关切，并讨论了 ES3.1 和新版 ES4 项目之间显著缺乏共识的问题。John Neumann 强调了他对 TG1 在向 Ecma 传达会议通知、议程、会议记录和关键文档时缺乏沟通的关切，并坚持认为这种情况需要改变。他还提出了警告，认为从 Ecma 委员会的角度来看，TG1 在某些情况下过于公开。特别是 Ecma 管理部门内也有人担心，TG1 成员之间的分歧会在网络博客和论坛上公开争论。Neumann 宣布，他将建议把与 ECMAScript 相关的活动再次作为 TC39 的唯一关注点。总体上看来，TC39-TG1 将被重命名为 TC39。这将使与 ECMAScript 相关的工作在 Ecma 内部得到更多的关注，并使 Ecma 秘书处能直接为其提供支持和监督。TC39 内其他正在开展工作的任务组，则将转入新成立的 TC49 任务组。这一改组在 2007 年 12 月的 Ecma GA 大会上获得批准。自 2008 年 1 月起，TC39-TG1 再次成为了 TC39。

11 月的会议还讨论了 TC39 的后续章程。Douglas Crockford 提议，应该有个新项目来定义一种安全的 ECMAScriptg（SES），以支持 mashupg 和其他注重安全性的应用。Allen Wirfs-Brock [2007] 则发布了一份新的《微软立场声明》，重申了微软的呼吁，即采取循序渐进的方式推进 ES3 语言和规范的发展，而非继续现有的新版 ES4 工作。Crockford 宣布雅虎支持这一立场。Lars Hansen 断言称「3.1 的提案一直停滞，最终在 9 月份被搁置，我们在这里致力于 ES4 而非 3.1」。Brendan Eich 也认为自 4 月以来 ES3.1 都没有多少进展。Wirfs-Brock 不接受 ES3.1 被搁置的说法，指出已有多份分析 ES3 互操作性问题的文档 [Lakshman 2007c; Wirfs-Brock 2007a, b; Wirfs-Brock and Crockford 2007]，它们都属于对 ES3.1 开发的投入。

为了评估对 TC39 三项可能的开发活动的兴趣，委员会进行了一次投票调查。与会的所有人（代表九个组织）都支持继续开展新版 ES4 的工作。继续开发 ES3.1 的工作得到了微软、雅虎、苹果、谷歌和 Mozilla 的支持。安全 ECMAScript 的启动工作得到了微软、雅虎、苹果和谷歌的支持。从 Ecma 的角度来看，这一支持度已足以证明在新的 TC39 中推进这些活动是合理的。不过微软也支持新版 ES4，这并不符合其立场文件中的说法。Allen Wirfs-Brock 回忆说，他认为不必在这一点上更进一步，因为他仍然预测对新版 ES4 的努力最后不会成功。

在 2007 年 12 月的 Ecma GA 大会后，Isabelle Valet-Harper 与 Allen Wirfs-Brock 讨论了谁可能是新 TC39 的合适主席。Brendan Eich 无法担任主席，因为 Ecma 当时的规则要求 TC 主席必须是一名来自标准会员的代表，而 Mozilla 则是一个非营利性会员。Wirfs-Brock 和 Valet-Harper 达成了一致，认为理想的主席应该是对 ES4、ES3.1 或任何其他可能的 TC39 项目没有利益相关或意见的人。Valet-Harper 建议微软和 Adobe 本着合作的精神，分别与 John Neumann 签约，由 John Neumann 代表他们，并共同提名他担任 TC39 主席。这一想法获得了 Adobe 的同意，并在 2008 年 1 月的 TC39 会议上得以宣布。在 2008 年 3 月的会议上，Neumann 被正式选为 TC39 主席。

2007 年 11 月，Lars Hansen [2007c] 编写了一份《编辑报告》，并提出了新的时间表，目标是在 2008 年 10 月前完成新版 ES4 的最终草案，并在 2008 年 12 月将其作为 Ecma 标准发布。他还写了一篇论文 [Hansen 2007a]，总结了新版 ES4 与 ES3 的有意不兼容之处，并写了一篇关于如何用新版 ES4 的渐进式类型支持演化式编程的教程 [Hansen 2007d]。2008 年 2 月，Jeff Dyer [2008a] 发布了一份新的工作计划，目标仍然定在 12 月，而中间的草案将在 5 月、7 月和 9 月完成。Hansen 和 Dyer [2008] 还发布了一份题为《在拟议的 ECMAScript 4 中将推迟的特性》的立场声明。声明中认为，当时的新版 ES4 计划包括了一些「奇怪的、未经证实的或代价高昂的」特性。而推迟实现这些特性：

将会大大增加在 2008 年完成规范的可能性，增加社区的参与度，有助于保持实现的复杂性可控，降低标准化的风险，并在一定程度上减少 TG1 成员之间的分歧。

声明中建议推迟的特性包括：数值转换、int 和 uint、十进制小数运算、运算符重载、泛型函数、wrap75、堆栈标记、生成器、尾调用、nullability、程序单位、重构的 with、修订后的 eval 和命名空间过滤器。在说明了这些特性被推迟的原因之后，声明提出了 Adobe 对 ECMAScript 未来发展的修订后意见：

我们认为 ES 相比于我们目前所看到的 ES4，应该更多地以一种零散的方式发展。从 E262-3 的发布到 E262-4 的发布已经过去了 9 年，这本身并不是一次性引入大量新特性的有效理由。每个特性都必须有其重要性，而且必须基于经验来指导我们。即便如此，本文并不主张接纳一个被注水的「ES3.1」（其实应该叫「ES3.01」）。我们主张现在就采用 80% 完成度的解决方案「ES3.8」，然后计划在不久的将来，当这些需求更明确的时候，再发展到满足新的需求。

在 TC39 的会议记录中，或者在 TC39 的内部或公开的电子邮件渠道中，都没有关于这份立场文件的实质性讨论记录。唯一有记录的回应是 IBM 对于排除十进制小数运算的建议表示反对。在同一时期，还出现了大量对新版 ES4 在设计、方法论和开发进程等各方面的批评意见。这些批评意见被发布到了 es4-discussg 邮件列表中，其中一些批评来自于有影响力的框架开发者，以及苹果和谷歌的 ECMAScript 实现者。2008 年 3 月，新版 ES4 的设计者们发现 [Dyer 2008b] 用于定义模块的新版 ES4 包抽象存在着根本性的语义问题，在 5 月还发现了命名空间的问题 [Stachowiak 2008b]。

在 2008 年的春天，Lars Hansen 发布了新版 ES4 个别规范部分的初稿以征求反馈意见。5 月 16 日，Hansen [2008] 公布了他的规范初稿 [Hansen et al. 2008a, b, c]。

随本文附上的是拟议的 ECMAScript 第四版规范相当不完整的初稿。这份草案包括一个简短的介绍，语言的表层语法，以及对核心语义的描述——包括值、存储、类型、名称、作用域和名称解析。更多的内容将在准备就绪后陆续发布，可能（或多或少地）每两个月发布一次。

在同一时期，ES3.1 子组开始开发一个由 ES3 规范衍生的规范。来自 Google、IBM、Dojo 基金会和苹果等组织的参与者不断扩大。ES3.1 规范的初稿于 5 月 28 日发布 [Lakshman 2008; Lakshman et al. 2008]。

在 2008 年 5 月 29 日到 30 日的会议上，这两份规范都由其编辑进行了介绍。详细的讨论时间被推迟到了 7 月份的会议上，以使成员们有时间阅读规范。从进展速度、剩余的写作量以及尚未解决的设计问题的数量来看，新版 ES4 的最终规范明显不可能在 2008 年 12 月前完成，其发布时间更可能是 2009 年 6 月或 2009 年 12 月。而对 ES3.1 来说，为了使其能在 2008 年 12 月前完成，所有主要的设计决策都需要在 2008 年 7 月会议前完成。将其发布时间定于 2009 年 6 月似乎是个较为现实的目标。

2008 年 6 月底，John Neumann 组织了一次电话会议，与会者包括 Brendan Eich、Allen Wirfs-Brock、Douglas Crockford、Adobe 的 Dan Smith76，以及 Adobe 的 Ecma GA 代表 David McAllister。McAllister 和 Smith 宣布，Adobe 将停止对新版 ES4 的支持，分配给它的工作人员将转到其他事项中去。在场的每个人都明白，这标志着新版 ES4 已经告终，下面应该为此仔细安排一份更为公开的声明。他们同意在 7 月份即将召开的 的 TC39 会议上向全体 TC39 成员宣读这一决定，并在会上决定如何发表公开声明。而对 Eich 来说，Adobe 已经事先告知了他这一决定。他对此表示同意，并希望 TC39 的所有成员都能围绕着完成 ES3.1 的工作，制定出一个不受过去 ES4 设计决定限制的共同计划。他也同意在即将举行的会议上提出这一设想。接下来的会议将于 7 月 23 日至 25 日在挪威奥斯陆举行。这次会议的议程被修订 [TC39 2008f]，将「ECMAScript 的和谐化（Harmonization ）」列为了第一个新议题。

在 2018 年的电子邮件讨论中，Jeff Dyer 和 Lars Hansen 回忆说，退出是他们与经理 Dan Smith 协商后做出的决定。他们已经确信，新版 ES4 不太可能完成。他们认为，ES3.1 工作组成员的反对意见使得新版 ES4 的工作停滞不前，而且很明显，在 ES3 现状基础上进行修复的方法在 TC39 中已经成为了主流，已经不再有空间来整合 ActionScript 3 的静态特性了。

Cormac Flanagan 在 2019 年的个人交流中推测，Adobe 的退出确实表明了新版 ES4 存在的问题。他的事后感想还包括以下几点：

• 为 ES4 计划的大量语言扩展（回头看来）是种高风险、非保守的做法。
• 在标准化进程中，主要由于静态类型系统的加入，标准涉及到了最前沿的语言技术（十多年后的 2019 年，这里仍然有一些未解决的研究和性能问题 [Greenman et al. 2019]）。在 TFP 07 上发表的《空间高效的渐进式类型》论文 [Herman et al. 2011] 受到了 ES4 中的性能问题的启发，这或许也体现了 ES4 工作的研究性质。
• 在 TC39 中，围绕 ES4 的「是否买入」担忧虽然一直是个问题，但从来都不是致命的。
• 尽管在后来的版本中被废弃，但基于 ML 的参考规范是个可行的设想。现在回想起来，也许从参考规范开始实现 ES3 会更好。

Douglas Crockford [2008c] 在一篇博文中，则将新版 ES4 的失败归咎于「未经证实的过度创新」：

事实证明，标准机构不是创新的好地方。这是属于实验室和初创公司的领域。标准必须通过共识来起草。标准必须是没有争议的。如果一个特性过于模糊，以至于无法形成共识，那么它就不应该成为标准化的备选项。正由于这个原因，「委员会设计」是个贬义词。标准化机构不应该参与到设计的工作中来。他们应该坚持认真制定规范，这也是一项重要而艰巨的工作。

Allen Wirfs-Brock 回忆说，当 Adobe 宣布退出新版 ES4 时，他感到松了一口气。他知道，微软负责 IE 浏览器的高管们已经意识到，放弃对 IE 浏览器的投资是个战略错误。当时 IE 的市场份额正大量流失到 Firefox 浏览器，而且高管们也知道谷歌正准备推出新的浏览器。微软正在主动面对 Web 开发者中所流传的「微软反对 Web 技术进步」的观点。微软对新版 ES4 的反对（特别是经由 Brendan Eich 和微软 Chris Wilson 的公开争论所暴露出的事实）也更加印证了这种观点。到 2008 年 6 月，Wirfs-Brock 担心微软可能会因为纯粹的商业原因而改变决定：与其公开反对，不如顺其自然地支持新版 ES4。

在奥斯陆举行的 TC39 会议 [TC39 2008g] 上，委员会的大部分时间都在围绕一套共同可实现的目标来解释「和谐化 TC39」的概念。总体计划是这样的：整个委员会的重点是在 2009 年完成 ES3.1 版本的发布，同时合作规划一个更重要的后续版本，即代号「和谐」（Harmony）的项目，它不受十年来 ES4 设计决策的限制。会议上讨论了一些特性算或不算「和谐的」，但在会上或会后与未参会的 TC39 成员的邮件讨论中，都没有人对基本计划提出严重的反对意见。会后编写的一份白皮书 [Eich et al. 2008] 总结了实施这一计划的步骤：

1. 在各方的充分合作下，将工作重点放在 ES3.1 上，目标是在明年初实现两个具备互操作性的实现。
2. 在 ES3.1 以外的下一步工作上进行合作，这将包括在语义和句法创新方面比目前 ES4 的建议更适度的语法扩展。
3. 删除 ES4 中的「包」、「命名空间」和「早期绑定」等概念。
4. 改写 ES4 中的其他目标和想法，以保持委员会的共识。这其中包括了「类」概念，它应当根据现有的 ES3 概念结合拟议的 ES3.1 扩展来实现。

8 月 13 日，Brendan Eich [2008b; Appendix M] 通过电子邮件向 es4-discuss 邮件列表发送了一份略为个性化的白皮书。8 月 19 日，Ecma 国际 [2008] 发布了一份简短的新闻稿，宣布 TC39 将把工作重点放在 ES3.1 上。8 月 15 日，Eich 录制了一个播客 [Openweb 2008]。他在其中解释了自己在技术层面和现实层面上对新版 ES4 失败的看法，以及他对 TC39 内部「和谐的未来」的希望。在播客开始不久，他说「通过命名空间来统一早期绑定和延迟绑定的尝试已经失败了。」后来他做了详细的说明：

首先我们把 ES4 的包给砍掉了，这是我们砍的。然后我们把 ES4 的命名空间也砍掉了，这也是我们砍的。我们这样做不是为了讨好 3.1。我们这样做是因为命名空间的问题。

……

这并不是让步，也不是对立斗争——这（新版 ES4）确实是个很好的尝试，它试着把事情统一起来，回到 Waldemar Horwat 的规范（也许甚至是 Common Lisp）去尝试命名空间和包，然后认识到它们不适合 Web。

插曲：认真对待 JavaScript

从 20 世纪 90 年代末开始，TC39 成员试图将 JavaScript 作为一种面向专业程序员的语言进行重新设计。到 2000 年代末，浏览器和其他相关平台的开发者们终于意识到，JavaScript 是他们平台中需要认真对待的工程部分。