ECMA、TC39、JS新语法都怎么来的

BreadBear
719 阅读7分钟

我们经常看到一些这样的文章：js终于支持includes了再也不用（~）indexOf了；??真香；#、static真tm帅之类的。那这些标准都是谁制定呢，整个制定过程又是如何的，之前写babel的时候，stage-1/2/3奇奇怪怪奇奇の都是啥？带着这些shit问题，开启一段奇妙之旅吧... ...（wait wait...这两天肚子疼，先去chua塞，回来再来搬运）

ECMA、TC39

ECMA:

是ECMA国际组织，全称是Ecma International （以前叫 ECMA - European Computer Manufacturers Association - 欧洲计算机制造商协会）是个行业标准组织，它所通过的标准都是 ECMA-nnn 这样进行编号。

TC39:

是ECMA 国际组织第 39 号技术委员会（ Technical Committee ），它是一个推动 JavaScript 发展的委员会。它是 ECMA 的一部分， ECMA 是 “ ECMAScript ” 规范下的 JavaScript 语言标准化的机构。

TC39 由各个主流浏览器厂商的代表构成，当然国内一些大型的科技公司比如阿里和字节都已经加入了 TC39 。他们的主要工作就是制定 ECMAScript 标准，标准生成的流程，并实现。

每两个月，TC39 都会召开会议，成员指定的代表和受邀的专家参加。 这些会议的记录在 GitHub 存储库 中公开。

除 TC39 外， ECMA 国际组织还有有众多其他的技术委员会，比如 TC43 Universal 3D (U3D)、TC45 Office Open XML Formats 等等。

最初 JavaScript 语言有 2 份标准：

ECMA-262:

是主标准，由 ECMA 国际组织（Ecma International）负责管理（为了让最初的JavaScript 与最初的 JScript 能遵循同一套标准发展而诞生的 ECMAScript ，正好排到了作为 Ecma 的 262 号标准，所以得到 ECMA-262 编号。）

ISO/IEC 16262:

是第二标准，由国际标准化组织（ISO，International Organization for Standardization）和国际电子技术委员会（IEC，International Electrotechnical Commission）负责管理

出于商标版权的原因，规范标准中将这门语言称为 ECMAScript，所以原则上 JavaScript 与 ECMAScript 指的是同一个东西，但有时也会加以区分：

  • JavaScript：指语言及其实现
  • ECMAScript：指语言标准及语言版本，比如 ES6 表示语言（标准）的第 6 版

拉个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 月）：第二个年度版本

TC39规范制定新的流程是怎么样的呢？

咦...,为啥使行的流程呢？难道之前有其他的流程吗?

是的，之前还真有，但是之前的流程有两个不太好的地方，所以被废除掉了。

是什么问题呢？我们来看看：

了解上边的版本发布时间线，我们知道， 在 ES3 出来之后，他们花了十年时间，几乎没有任何改变，使其达到规范。之后， ES6 又花了四年才能实现。发版周期过长存在 2 个问题：

1.版本之间的时间跨度太长，提早定稿的特性要等待非常长的时间，一直等到规范正式发布（才能被实现和使用），而靠后的特性往往赶在最后发版期限之前才定稿，存在风险

2.语言特性的设计与实现和使用相隔太久，在实现和使用阶段才发现设计缺陷为时已晚

针对这些问题，TC39 制定了新的 TC39 流程（ The TC39 Process ）：

  • ECMAScript 功能是独立设计的，并经历了从 0（“稻草人”）开始到 4（“完成”）结束的阶段。
  • 尤其是后期阶段需要原型实现和实际测试，从而使得功能在设计和实现之间有反馈环节。
  • ECMAScript 版本每年发布一次，包括在发布截止日期之前已达到第 4 阶段的所有功能。

流程如下：

image.png

  • stage0 strawman： 任何讨论、想法、改变或者还没加到提案的特性都在这个阶段。只有TC39成员可以提交。
  • stage1 proposal:
  • （1）产出一个正式的提案。
  • （2）发现潜在的问题，例如与其他特性的关系，实现难题。
  • （3）提案包括详细的API描述，使用例子，以及关于相关的语义和算法。
  • stage2 draft:
  • （1）提供一个初始的草案规范，与最终标准中包含的特性不会有太大差别。草案之后，原则上只接受增量修改。
  • （2）开始实验如何实现，实现形式包括polyfill, 实现引擎（提供草案执行本地支持），或者编译转换（例如babel）
  • stage3 candidate:
  • （1）候选阶段，获得具体实现和用户的反馈。此后，只有在实现和使用过程中出现了重大问题才会修改。
  • （2）规范文档必须是完整的，评审人和ECMAScript的编辑要在规范上签字。
  • （3）至少要在一个浏览器中实现，提供polyfill或者babel插件。
  • stage4 finished:
  • （1）已经准备就绪，该特性会出现在下个版本的ECMAScript规范之中。
  • （2）需要通过有2个独立的实现并通过验收测试，以获取使用过程中的重要实践经验。

新流程使用 HTML 的超集来格式化提案，使用 GitHub pull requests 的模式来增加社区参与度

从 ES2016 开始（新 TC39 流程施行以来）， ES 版本的概念被大大弱化了，需要关心的是特性提案处于第几阶段，只要进入第 4 阶段就已经算是标准特性了

干货 - TC39都有啥

此外，TC39 拥有很多仓库,其中的 ecma262 仓库主要维护 ECMAScript 规范文档

工具

提供两个小网站，查看兼容性：

caniuse.com/#

kangax.github.io/compat-tabl…

TC39 with Babel

如果你在别人的代码里或者网络上发现一个你没见过的 JS 代码语法你应该怎么办呢？

首先你应该尝试通过搜索引擎找到这种语法的正式名称。然后你就可以去 TC39 的 github 中找一下，你可以在 ecma-262 正式文档中找（不过这个文档太长了）也可以在 proposals 列表里找一下，别遗漏了 finished proposals 和 inactive proposales 列表，最终你就会找到这个语法的介绍和用例。

接着你会想看一下这个语法在不同环境下的支持程度，所以你需要打开兼容性表格查询页面查找这个语法。

接着你也许会想尝试着编写一个用例并运行一下，那你需要在 Babel 的官网里查一下 plugins 列表里是否支持该语法，如果是新的 API 那就需要在 core-js 列表里找一下。

接着你就可以配置好 Babel 并编写用例，编译成浏览器兼容的代码，在浏览器里运行了。

avatar
文章
阅读
粉丝