TC39 規範制定フロー

一.JavaScript の誕生

1995 年 5 月、Brendan Eich という人物が 10 日間で JavaScript を創造しました

二.JavaScript 言語の標準化

当初 JavaScript 言語には 2 つの標準がありました：

• ECMA-262：主標準。ECMA 国際組織（Ecma International）が管理を担当

• ISO/IEC 16262：第二標準。国際標準化機構（ISO、International Organization for Standardization）と国際電気技術委員会（IEC、International Electrotechnical Commission）が管理を担当

商標版権の理由により、規範標準中ではこの言語を ECMAScript と呼んでいます。したがって原則的に JavaScript と ECMAScript は同じものを指しますが、時には区別することもあります：

• JavaScript：言語とその実装を指す

• ECMAScript：言語標準および言語バージョンを指す。例えば ES6 は言語（標準）の第 6 版を表す

P.S.ECMAScript 中の ECMA は主標準を管理する ECMA 国際組織から取られたもので、この組織は当初ヨーロッパコンピュータ製造業者協会（European Computer Manufacturers Association）と呼ばれていましたが、後に影響範囲がヨーロッパに限定されなくなり、ECMA 国際組織（Ecma International）に改名されました

三.ES 規範バージョン履歴

• ECMAScript 1（1997 年 6 月）：規範第一版

• ECMAScript 2（1998 年 6 月）：ISO 標準と同期するため、いくつかの小更新を導入

• ECMAScript 3（1999 年 12 月）：正規表現、文字列処理、制御文（do-while、switch）、例外処理（try-catch）など多くの核心特性を追加

• ECMAScript 4（2008 年 7 月廃止）：本来は大規模アップグレード（静的型、モジュール、名前空間など）でしたが、飛躍が大きすぎて意見の相違が生じ、最終的に普及使用されませんでした

• ECMAScript 5（2009 年 12 月）：変化は大きくなく、いくつかの標準ライブラリ特性と厳格モードを追加

• ECMAScript 5.1（2011 年 6 月）：もう一度の小更新。ISO 標準と同期するため

• [ECMAScript 6](/articles/es6 学习笔记 13 篇/)（2015 年 6 月）：一大波の更新。当年 ES4 の多くの構想を実現し、正式に年份で規範バージョンを命名するように変更

• ECMAScript 2016（2016 年 6 月）：最初の年度バージョン。ES6 と比較して、リリースサイクルが短く、新特性も比較的少ない

• ECMAScript 2017（2017 年 6 月）：2 番目の年度バージョン

• 以後の ECMAScript バージョン（ES2018、ES2019、ES2020 など）はすべて 6 月に正式に批准生效

四.TC39 標準制定フロー

ES6 から見ると、リリースサイクルが長すぎることで 2 つの問題が存在しました：

• バージョン間の時間間隔が長すぎる。早期に確定した特性は非常に長い時間待たなければならず、規範が正式にリリースされるまで（実装和使用できない）、後半の特性はしばしば最終リリース期限の前にようやく確定し、リスクが存在する

• 言語特性の設計と実装和使用が隔たりが長すぎる。実装和使用段階になって初めて設計欠陥を発見しても手遅れ

そのため、TC39（ECMA 国際組織第 39 号技術委員会）は新しいフローを開始しました：

P.S.ECMA 国際組織には多くの技術委員会が設置されており、TC39 ECMAScript の他に、TC43 Universal 3D (U3D)、TC45 Office Open XML Formats などがあります。詳細は Ecma template for minutes - Ecma International を参照

主な変化は：

• ECMAScript の各特性は独立して設計され、5 つの段階を経て、Stage 0（Strawman、初稿）から始まり、Stage 1（提案）、Stage 2（草案）、Stage 3（候補提案）を経て、最後に Stage 4（Finished、審査通過提案）で終了

• 後半のいく��かの段階でプロトタイプ実装と実際テストを行うことを要求（Test 262 が担当）。設計と実装の間にフィードバックループを形成するため

• ECMAScript は毎年 1 版をリリースし、最終リリース日期之前にすべて第 4 段階に入ったすべての特性を囊括

したがって、ES2016 から（新しい TC39 フロー施行以来）、ES バージョンの概念は大幅に弱化されました。関心を持つべきは特性提案が第幾段階にあるかで、第 4 段階に入ればすでに標準特性とみなされ、次の 6 月に正式に標準に組み込まれます

P.S.TC39 フロー文書 によると、毎年 7 月にリリースすべきです：

July: Approval of new standard by the ECMA General Assembly

しかし実際のリリース時間は毎年 6 月です。歴史上の那些 6 月にリリースされた元老バージョンを記念するためかもしれません

五.後方互換原則

ES 規範の各版は常に完全に以前のすべての特性と互換性があることがわかります。例えば ES6 は let、const を提案しましたが var を削除しませんでした。これは互換性のない新版本を推出すると、いくつかの問題を引き起こすためです：

• JavaScript エンジン、IDE、構築ツールはすべて膨張します。新旧 2 版の規範をサポートする必要があるため

• 開発者はバージョン間の差異を知る必要がある

• 既存のコードをすべて新版本に移行するか、（異なるプロジェクト）複数のバージョンを混用するかのどちらかで、リファクタリングが非常に面倒になる

• 甚至各段コードの所属バージョンを标注する必要がある。ES5 が手動で厳格モードを开启するのと同じで、当時流行しなかった一つの理由はファイルまたは関数の先頭にディレクティブを追加するのも面倒だったため

これらの問題を回避するため、ES6 はOne JavaScript という戦略を採用しました：

• 新版本は常に完全に後方互換（ただし時々軽微で目立たないクリーンアップがある可能性あり）

• 旧特性は削除も修復もせず、より良いバージョンを導入。例えば let は var の改善版

• 言語の某些方面に変化がある場合、新しい構文構造内でのみ生效。つまり暗黙的に選択。例えば、yield は generator 中でのみキーワード、モジュールとクラス中のすべてのコードはデフォルトで厳格モードを开启

参考資料

• History and evolution of JavaScript

• ES2016 | 四。なぜこのバージョンはこんなに小さいのか？

• The Real Story Behind ECMAScript 4

• TC39 と ECMAScript 提案