18. ES4 テイク 2

ES4₁ の策定作業は 2003 年に停止したものの、ウェブにおける JavaScript の利用は広がり続けた。それから一年もしないうちに、TG1 のメンバーは彼らが「ES4」と呼ぶ新しいバージョンの ECMAScript の設計について再び話し始めた。

18.1 TC39-TG1 の再始動

Macromedia は 2003 年 11 月に Ecma の会員となり、Jeff Dyer が TC39 における Macromedia の代表者の一人となった。ES4 仕様を作成する TG1 の一度目の試みが ActionScript 3 に大きな影響を与えたことを考えればこれは明らかな動きと言える。ActionScript の設計が将来の ECMAScript 仕様の策定作業と足並みを揃えること、そして ActionScript の要件と前例を TG1 に考慮させることが Macromedia にとって重要だった。

Mozilla Foundation は 2004 年の春に Firefox ブラウザの技術プレビューを公開しており、Firefox 1.0 は年内にリリースされる予定だった。当時 Mozilla の CTO だった Brendan Eich はオープンなウェブの将来について懸念を抱いていた。ブラウザによってホストされるウェブアプリケーションへの関心は急増していたものの、当時のブラウザ規格はリッチなアプリケーションを十分サポートできるとは言えない。さらに Microsoft の Windows Presentation Framework (WPF) と .NET、あるいは Macromedia の Flash といったクローズでプロプライエタリなアプリケーションプラットフォームが HTML/CSS/JavaScript というウェブ技術スイートを置き換えようと争っており、オープンなウェブを形作る責任のある標準化組織はこの困難に対応できていない。1998 年 W3C は XML ベースの技術を優先して HTML の進化を止めることを決定する [W3C 1998]。しかし XHTML は構文的にも意味論的にも HTML と互換性を持たず、ブラウザベンダーとウェブ開発者に広く受け入れられていなかった。Ecma TC39-TG1 でも同様に ECMAScript 仕様を進化させる試みが難航し、TG1 の注目は ECMAScript における XML 処理のサポートに向いていた。ウェブ技術コミュニティの中には「ECMAScript は死んだ」と噂する者もいた [Schulze 2004b]。

こういった状況を踏まえ、Brendan Eich [2004] は HTML の将来に関する取り組みに集中して取り組む組織 WHATWG (The Web Hypertext Application Technology Working Group) の設立に手を貸した [Hickson 2004]。彼はさらに TG1 の再編成も開始した。Eich は 2004 年 3 月に Ecma 事務総長と接触し、Mozilla Foundation は Ecma 会員になることを申請した [Marcey 2004]。2004 年 6 月、Eich は 1998 年 2 月以来初めて TG1 会合 [Schulze 2004a] に参加した。

6 月の会合 [Schulze 2004b] では TG1 会合の議長が Microsoft の Rok Yu から Macromedia の William Shulze に移り、Jeff Dyer が ECMA-262 の編集者になった。参加者は ECMAScript 第 4 版を完成させるための作業に集中すること、そして Waldemar Horwat の ES4₁ ドラフトを使わないことを決定した。Schulze の報告書には「[ES4₁ は] 変更があまりにも抜本的かつ広範すぎて、完成あるいは採用が見込めない」とある。メンバーはその代わり ActionScript を含む既存の実装に統合できるような「よりインクリメンタルなアプローチ」 [Schulze 2004a] を取ることに合意した。パッケージ、名前空間、条件付き属性、実行時の型検査、XML サポートが組み込まれる機能候補のリストに挙げられた。このリストには古い ES4₁ から引き継いだ非常に複雑な要素もいくつか含まれていたものの、メンバーは新しい第 4 版の作成サイクルは 12 か月を一つの単位とすることを確約した。Dyer は考えられる変更のドラフトを準備し、2004 年の 10 月に予定された会合でプレゼンテーションを行うことに合意した。

TG1 はこの新しい目標を達成できなかった。2004 年の残りおよび 2005 年の大部分で、TG1 の参加者は ISO ファストトラックプロセスの一環として行われた E4X 仕様の改訂に労力を費やし続けた [Schneider et al. 2005]。新しい ES4 に対する真剣な作業は 2005 年の 10 月まで始まらなかった。しかし、この合間に Brendan Eich は当時の ECMAScript 標準化活動の現在状態を察知し、カンファレスのトークやブログ記事で次世代の仕様に関する自身のアイデアを公開で表明していった [Eich 2005a, b]。2005 年 9 月の会合 [TC39-TG1 2005] で Eich は TG1 の議長となり、ES4 作成作業を進めることを主張し始めた。

18.2 ES4 の再設計

2005 年 10 月のブログ記事で、Brendan Eich [2005d] は ES4 作成の次ラウンドにおける目標を掲げた:

• 第 4 版を現在の言語に寄せて、プロトタイプベースの委譲が互換モードにだけ存在する痕跡器官ではなくオブジェクトシステムの動的な部分になるようにする。オブジェクトシステムにはクラスを持たせ、クラスには上書きや隠蔽のできない固定されたメンバーを持たせる。

• 言語のブートストラップ¹を可能にする。つまり「ネイティブ」なオブジェクト (ECMA-262 第 3 版の第 15 節) が利用するメタオブジェクトプロトコル的なマジック、例えば値の代入、値の設定、関数の呼び出し、構文の評価、あるいは列挙可能性といったプロパティ属性の制御を全て記述できるようにする。

• 既存の版と新しい版の相互運用性を壊すことなく型注釈を追加し、XUL² とモダンなウェブアプリケーションが必要とする大規模プログラミングをサポートする。

• ほぼ全ての JS ハッカーが遭遇する長年の問題を前述のように修正する。

彼は相互運用性をテストするための初期実装を含めて作業を 2006 年の末までに完了させるつもりだと述べた。

Brendan Eich は 2005 年 11 月のブログ記事 [2005c] で目標を次のように単純化した:

1. より強い型付けと名前付けで大規模プログラミングをサポートする。
2. ブートストラップ、セルフホスト^語、リフレクションを可能にする。
3. 少数の単純化を除いて後方互換性を保つ。

加えて彼は ECMAScript を Java などの他の言語に似せることや最適化しやすいように変えることは目標でないとも述べた。それに続くプレゼンテーションで、Eich [2006a] は宣言的な静的型やクラス宣言が必要なのかという疑問をはじめとしたオリジナルの ES4₁ に対する批判を取り上げた。彼の反論は、次の 10 年でウェブ開発者が作るアプリケーションがさらに複雑になると ES3 では上手くスケールしない、というものだった。特に、不変条件を強制でき、さらに省略可能な形で静的に検査できる型システムがそういったアプリケーションには必要だと彼は論じた。ただそういった変更は一度だけしか行えず、それを行うのが今だというのが彼の主張だった。

オリジナルの ES4₁ が抱えていた問題の一部はプログラミング言語仕様の記述テクニックと型システムの分野における現代的な研究を応用すれば解決できるだろうと Brendan Eich は楽観的に考えていた。2006 年の初め、彼は Dave Herman を TG1 の ES4₂ 設計チームに迎えた。Herman はノースイースタン大学の博士学生であり、ES3 の操作的意味論に取り組んだことがあった。Herman の勧めに従い、Eich はカリフォルニア大学サンタクルーズ校の教授 Cormac Flanagan もチームに迎えた。Flanagan はハイブリッド型システムの専門家である [Flanagan 2006]。これとほぼ同じ時期、ウェブブラウザ Opera を開発するソフトウェア技術者 Lars Thomas Hansen も TG1 の定期参加者となった³。Herman, Hansen, Flanagan の三人はノースイースタン大学のプログラミング言語研究コミュニティとのつながりを直接的あるいは間接的に持っている。

2005 年の後半、TG1 は ES4₂ プロジェクトに関して週ごとの通話会議と月ごとの対面会合を行うスケジュールを確立した。2006 年における ES4₂ のコア設計チームを図 26 に示す。会合に定期的に参加し、主要な決断に関与し、ドラフトに取り込まれる大きな貢献を行った人物の名前が挙げられている。他にも Adobe や Mozilla などの組織から会合に参加したり貢献を行ったりした人物はいたものの、プロジェクトへの参加はここに挙げた人物ほど活発ではなかった。

一度目の ES4₁ (JS2) を作成する試みでは、既存の ECMAScript プログラムと非互換な変更を行うことを何とも思っていなかった。ブラウザは HTML の <script> 要素の属性に含まれるバージョン情報を使って言語の異なるバージョンを選択できるから非互換になっても構わないだろう、というのが裏にあった考えである。新しい ES4₂ の取り組みでは起きかねない破壊的変更の存在をもっと意識することになった。ただ初期の JavaScript の設計ミスと TC39 が考えるものについてはバージョン付けを使って修正できるだろうとも考えられていた。Brendan Eich はこの可能性をブログ記事とプレゼンテーションで語ったものの、一部の TG1 メンバーからは反対意見もあった。2006 年 7 月の TG1 会合 [TC39-TG1 2006c] で Yahoo! を代表する Douglas Crockford は「後方互換性は困難かつ重要である」とした上で、TC39 にとって一番重要な問題はセキュリティであり、セキュリティ関連の問題を解決できるなら後方互換性は犠牲にできると述べた。Microsoft の Pratap Lakshman は「優先度 0 [最大の優先度] は後方互換性だ。後方互換性が壊れていいのはセキュリティ関連の修正をするときだけだ」と述べた。

ICFP'05 で行われた JavaScript の十周年を記念する基調講演の Q&A セッション [Danvy 2005] で、Brendan Eich は Python についてポジティブな意見を語った。彼は大規模なウェブスクリプトに対しては JavaScript より Python の方が優れた言語かもしれないとさえ述べた。その次の年を通じて、彼は Python からそのまま借用した機能をいくつか ES4 に導入することを働きかけた。例えばイテレータ、ジェネレータ、分割代入、配列の内包表記が提案された。また、変数を関数スコープで宣言する var の対となるものとして変数をブロックスコープで宣言する let および const というキーワードも Eich によって提案された。こういった機能は ES4₂ に向けて提案された「大規模プログラミング」(TC39 はこう呼んだ) 用の複雑な機能と大部分が直交しており、一部は何らかの形で SpiderMonkey ベースの JavaScript 1.7 エンジン [Mozilla 2006a] に追加され、2006 年 10 月に Firefox 2 ブラウザの一部として出荷された。しかしそういった機能は他のブラウザで採用されなかったので、XUL 以外の場所でまともに使われることはなかった。

Eich は ES4₂ で行われる JavaScript の改善を他のブラウザベンダー (特に Microsoft) がすぐに実装しないのではないかと疑念を抱いていた。また急成長する AJAX ウェブアプリケーションの需要を満たせるだけの性能向上が JavaScript エンジンにもたらされない可能性も懸念されていた。両方の問題を解決する一つの方法は、将来公開される ES4₂ 仕様をサポートするハイパフォーマンスなオープンソース JavaScript エンジンを公開することだった。これを達成するために Eich は Adobe に AVM 2 実装をオープンソースライセンスで Mozilla に提供するよう説得し、提供させることに成功した。こうして手に入れたコードベースを Mozilla は「Tamarin」と名付けた [Mozilla 2006b]。それからの数か月の間に Mozilla は二つのプロジェクトを発表した [Eich 2007a]: Tamarin のコードベースを使って SpiderMonkey を置き換えることを目標とした ActionMonkey と、Internet Explorer にサードパーティのプラグイン拡張機能として追加できる Tamarin ベースの JavaScript エンジン ScreamingMonkey である。どちらのプロジェクトも完成しなかった。

こういった産業の方向転換が起こっている間に、TG1 は新しい ES4₂ の設計に取り組み続けた。ES4₂ の主な目標は大規模なプログラムに含まれる複雑なデータ抽象化の正当性の検証に利用できるような型システムと型注釈記法を追加することだった。適切に型注釈が付いたプログラムに対しては静的な型検査をデプロイの前に行えるべきであり、その一方で以前の JavaScript で許されているようなオブジェクトの動的な構造的改変が含まれる型注釈を持たない既存のプログラムおよび新しいプログラムも扱えるべきとされた。2006 年、TC39 の時間の多くはこういった要件が意味することを理解し、要件を満たす型システムの設計を試みることに費やされた [TC39-TG1 2006a, d]。

TC39 での議論は ActionScript 3 の仕様で非形式的に記述された型システムがある状態から始まった [Macromedia 2005]。これはジェネリック型が追加される前の Java に似た、クラス型とインターフェース型を持つ名前的型システムである。ActionScript 3 は型注釈付きの宣言を持ち、明示的な型注釈を持たない宣言のための全称型を持っていた。ActionScript 3 の仕様は関数の部分型という概念を明示的に持たず、クラスとインターフェースの部分型付けに関する定義が不完全だった。また、宣言に付いた型注釈と制限のある型推論を使った実行前の静的型検査を行う strict モードと、実際のデータ値が型注釈と操作の要件と合っているかどうかを動的に検証する standard モードが存在した。

Dave Herman と Cormac Flanagan は、契約モデル [Findler and Felleisen 2002] を使えば型付き宣言と型無し宣言を保ちつつ上手く strict モードと standard モードを統合できるのではないかという趣旨の発言をした。作業が進行すると、オブジェクトリテラルと配列リテラルを扱うために構造型 (structural type) [TC39 ES4 2006d] が、配列型を扱うために被パラメータ化型 (parameterized type) が追加された。他にも多くの選択肢が検討され、TG1 のプライベート⁶ Wiki に掲載された [TC39 ES4 2007g]。2007 年の初めごろまでに、ES4₂ の設計は未完成ではあるものの関数型や共変性/反変性といった現代的な型付けの概念を含むまでに成長した [TC39 ES4 2007b]。レガシーな動的型付けのプログラムと省略可能な型付けをサポートしなければならない事情によって設計はとても複雑になった。

2006 年全体と 2007 年の大部分を通して、TG1 は新しい提案の作成と既存の提案の洗練に取り組み続けた。やがてプライベート Wiki には ES4₂ 仕様に取り込まれる予定の 44 個の承認済み提案が並んだ [TC39 ES4 2007e; 補遺 L]。これ以外に 26 個の提案 [TC39 ES4 2007f] が延期または削除された。

ES3 仕様の意味論を形式化する実験をまとめた Dave Herman のウェブページ [Herman 2005] を見つけた Brendan Eich は、彼を TG1 に招いた。2006 年 2 月の TG1 会合 [TC39-TG1 2006b] で Herman はプログラミング言語を記述するための形式的テクニックについてプレゼンテーションを行った。形式的な仕様は実装者向けの手引きを提供するのに加えて、仕様に含まれるバグの発見と修正につながると彼は説明した。そういった形式的な仕様は ECMAScript の実装者をはじめとした通常の仕様ユーザーが読めるものになるのかという疑問が呈されたが、Herman は可能である ── 意味論ベースの形式化は非常に読みやすくできる ── との考えを述べた。それから数か月にわたって Herman は ECMAScript の意味論を指定するときに使う言語として Maude [Clavel et al. 2003], Stratego [Visser 2001], PLT Redex [Matthews et al. 2004] を調査したものの、どれも今のタスクには不十分だと最終的には判断された。同じころ言語を参照実装で定義する選択肢についても議論があった。新しい ECMAScript 用の形式仕様言語を設計する選択肢も話題に上った。2006 年 10 月 [TC39-TG1 2006e] にそういった言語の構文と意味論が議論されたとき、Cormac Flanagan は ECMAScript の新しいバージョンとそれを定義する仕様言語という二つの言語に TC39 は本当に取り組むつもりなのか、と意見を述べた。その後グループは既存の言語を使って ES4₂ の定義的インタープリタ⁷を書くことにすぐに合意した。彼らが素早く採用した言語は SML⁸ だった。TG1 は 11 月中旬までに仕様の形式化のためのツールとインフラストラクチャを整え、メンバーは定義的インタープリタのコーディングに取り組み始めた。Herman と Flanagan [2007] はこの決断が TC39 のワーキングスタイルに与えた影響を次のように説明した:

定義的インタープリタに切り替えてから委員会の対話スタイルは大きく変化した。月ごとに一日半をかけて行われる議論中心の会合は三日間の「ハッカソン^語」となった。言語の設計や実装におけるコーナーケースが見つかってそれを解決する必要が生じるために、「ハッカソン」では散発的に技術的な議論が起こった。

18.3 反対意見

Microsoft は再始動された ES4₂ の取り組みにほとんど関与しなかった。Microsoft で JScript の開発を一貫して担当したのは開発ツール部門 (DevDiv) だったものの、DevDiv は Internet Explorer を担当する Microsoft Windows 部署から組織的に大きく離れていた。2000 年代の初めに組織的な改変があり、DevDiv は .NET 戦略のサポート役に位置付けられ、JScript .NET と Internet Explorer に含まれる従来の JScript エンジンは両方とも C# 製品ユニットの担当となった。これに伴い ECMAScript 標準化活動に参加する責務もこのユニットに移った。しかし JScript .NET を採用する顧客が少なかった上に Windows が組織として Internet Explorer の改善にほとんど関心を持っていなかったので、C# 製品ユニットにおいて JScript/ECMAScript に関する作業の優先度は低かった。

2000 年代の Microsoft は戦略的に重要な開発をメインのレドモンドとワシントンのキャンパスで行い、それより単発的なプロジェクトを世界中に存在する他のキャンパスで行うことが多かった。2006 会計年度 (2005 年 7 月から 2006 年 6 月)、Microsoft の DevDiv は JScript/ECMAScript の担当をハイデラバードのインド開発局 (IDC) に移すことを決定する。DevDiv は以前に Java 風の J# .NET という製品の担当を IDC に移行したことがあった [Prasanna 2002]。JScript/ECMAScript の移行は 2006 年の春までに完了し、TG1 での Microsoft の代表者は Pratap Lakshman が勤めることになった。Lakshman は J# チームに所属したことがあり、TC39-TG3 (C# の規格に取り組む Ecma の作業部会) にも関与していた。彼は 2006 月の 4 月にリモートで TG1 会合に初めて出席し、その後も電話会合や対面会合に何度か出席した。ただ彼は ES4₂ 策定作業の重要な貢献者ではなかった。

本稿の著者の一人 Allen Wirfs-Brock は新しい IDE のアーキテクチャを調査する探索的プロジェクトに取り組むソフトウェア技術者として 2003 年に Microsoft に加わった。Microsoft に移る前、彼はプログラミング言語 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 は Wirfs-Brock に JavaScript について知っているかどうかを尋ねた。それに対して Wirfs-Brock は次のようなことを答えたと記憶している: 「あまり詳しくは知りません。ウェブページで使われる動的言語で、Self と軽い関係があったと思います」 Liuson はモニタを彼に向け、ちょうど受け取ったばかりのメールについてどう思うかをさらに質問した。

そのメールは Pratap Lakshman が DevDiv の製品ユニットマネージャ全員に宛てて書いたもので、Ecma TC39 で作成中の新しい JavaScript 規格に対して Microsoft が取るべき態度について助言を求めていた。Lakshman のメールには新しい規格が Adobe Flash に基づいており、現在のブラウザにあるものから大きな変更になりそうだと記してあったと Wirfs-Brock は記憶している。TC39 が作成しているのは非常に強力な言語であり、おそらくウェブには複雑すぎるものになると Lakshman は語っていた。そのメールにはクラスベースの静的型付け^語、構造的型、被パラメータ化型、メソッドオーバーロードといった新しい機能からなる長いリストが記されており、改訂された言語は Standard ML で書かれた参照実装を通じて規定される予定になっていると説明されていた。

Allen Wirfs-Brock の Julia Liuson への返答は、これは完全な再設計のように思え、自身の経験から言うと静的型を追加することで動的言語を改善する試みが成功することはほとんどない、というものだった。彼は JavaScript やウェブ開発について十分知らなかったので、詳しいことは言えなかった。しかし Wirfs-Brock はさらなる調査を申し出た。

Wirfs-Brock は数日をかけて JavaScript に慣れ、ES3 仕様と公開されていた wiki のスナップショット [TC39-ES4 2007g] にあった TG1 提案を読み込んだ。さらに彼は Lakshman、Internet Explorer チームのソフトウェア技術者、そしてウェブベースのアプリケーションに取り組む Microsoft のエンジニアに話を聞いた。ここから彼はウェブにおける JavaScript の役割が Richard Gabriel [1990] の「悪い方が良い (Worse is Better)」という考え方に非常によく合致することに気が付いた。JavaScript は必要最小限の機能を持つものとして作成され、それからワールドワイドウェブという織物のいたるところに深く編み込まれるまでに成長したからである。これに対して ES4₂ は Gabriel が呼ぶところの「正しいことをする」プロジェクトであり、ES4₂ が完成する可能性は低く、仮に完成したとしてもウェブに非常に大きな問題をもたらすだろう、と Wirfs-Brock は感じた。彼は ECMAScript をインクリメンタルな進化の道に引き戻すのが技術的道義だと結論付けた。

Microsoft はウェブブラウザ技術に戦略的関心を持っていなかったので、DevDiv の経営層がウェブブラウザ関連の取り組みにリソースを割くことはないだろうと Wirfs-Brock は考えた。そこで彼は DevDiv 内部に向けた資料として、ES4₂ が成功したときに起こり得ることをまとめた資料を作り始めた。彼が抱いていた大きな懸念は Adobe が ActionScript 3 の言語定義と仮想マシンを TC39 の取り組みに提供していることだった。DevDiv が集中していたプロプライエタリ製品は .NET プラットフォームとそのフラッグシップ言語 C# であり、その主要な顧客はエンタープライズアプリケーションの開発者である。.NET の強力な競争相手は Sun の Java プラットフォームだが、DevDiv は ActionScript ベースの Flash と Flex という Adobe 製品も .NET の競争相手としてみなしていた。Wirfs-Brock は ES4₂ が成功すると ActionScript が機能やツールの点で C# や Java と肩を並べる最上級のエンタープライズ言語になるのではないかと予想した。加えてウェブ開発の主要な言語として標準化されるようなことがあれば、ActionScript は Microsoft の開発者向け製品および言語に対する強力な競争相手となる可能性がある。

Allen Wirfs-Brock はこういった懸念を伝えるメモを書いた。そのメモには、TG1 に積極的に関与して ECMAScript 規格を少しずつスムーズに進化させるように方向転換を行うべきだという Microsoft への進言も含まれていた。この進言は 2 月の中旬までに受理され、Wirfs-Brock はそれを実現させる担当者に任命された。2007 年 2 月 18 日、Pratap Lakshman は TG1 のプライベートメーリングリスト [TC39 2003] に TG1 の新しい Microsoft 代表者として Wirfs-Brock を紹介するメッセージを投稿した。

3 月の TG1 対面会合は Microsoft が主催だったので、Wirfs-Brock はこれを初めて出席する会合にすることを決めた。さらに彼は、Microsoft が ES4₂ の取り組みに手を貸したがっているという TC39 の誤解を早く解くことが重要だと考えた。彼はこのメッセージを 2 月の会合で伝えてもらうよう Pratap Lakshman に依頼し、Lakshman は会合でそれを伝えた上で TG1 のプライベート wiki に単純化された ES4 ブラウザプロファイルというアイデアを提案するページを作成した。Lakshman が受けた反応は非常に否定的だったものの、コーヒーブレイクのときに Douglas Crockford が近づいてきて、ES4₂ への反対について Yahoo! は Microsoft と同じ意見だと語った、と Wirfs-Brock は報告を受けた。

Allen Wirfs-Brock は Douglas Crockford と接触し、ES4₂ プロジェクトの代わりとなる提案を Microsoft と Yahoo! が共同で作成することに合意した。Crockford [2002d] は以前、オリジナルの設計に含まれるミスや不便な点を修正して言語を「少しだけまし」にするために ECMAScript 言語に対して行うべき改変をまとめた提言を公開していた。Wirfs-Brock と Crockford はその提言を共同提案の技術的側面のスタート地点とすることに合意した。Pratap Lakshman は自身のブラウザプロファイルのアイデアへのフォローアップとして、Crockford が提案した ES3 への改変の多くを取り入れたミニマリストなアプローチの提案 [Lakshman 2007b] を投稿した。こうしている間に、Wirfs-Brock は Crockford および Lakshman と協力して今までよりフォーマルな提案のドラフトを作成し、内部承認を受けるために Microsoft と Yahoo! 内に配布した。2007 年 3 月 15 日、彼らは 3 月 21–23 日の TG1 会合に先立つ形でその提案 [Crockford et al. 2007] を投稿し、Crockford は TG1 のプライベートメーリングリストを通じてそれを発表した。

この提案の完全なタイトルは「TC39-TG1 の焦点を ECMAScript 第 3 版仕様のメンテナンスに戻す提案」であり、最初の段落は次の通りである:

TC39-TG1 で現在策定中の仕様は現在の規格からの差異があまりにも大きく、事実上新しい言語であると我々は考える。策定中の仕様と ECMAScript 第 3 版の違いは C++ と C の違いと同程度に大きい。そういった根本的な変更は広く使われる標準化された言語の改訂として望ましくない。また ECMAScript 第 3 版が AJAX スタイルのウェブアプリケーションで広く採用されていることを考えれば、この変更は正当化できることではない。現在の言語設計の取り組みを続けて TC39-TG1 内でコンセンサスが得られると我々は考えない。しかし別の道を見つけることはできると考えており、解決へ向かう可能な道の一つとして本提案を提出する。

この提案は三つの作業項目を軸にした TG1 の再構成を提言した。一つ目の作業項目は仕様第 3 版で定義される当時最新の ECMAScript のメンテナンスだった。提案されたメンテナンス作業は、第 3 版で十分正確に規定されていない部分の明確化、Mozilla の JavaScript 1.6/1.7 が持つ機能をはじめとした新機能の取り込み、そして Crockford が指摘したものを含む細かな修正と改善だった。二つ目の作業項目は ActionScript の規格のドラフトを作成することで、三つ目の作業項目はブラウザ用の新しいプログラミング言語を ECMAScript との互換性に縛られない形で定義することだった。提案は二つ目と三つ目の作業項目を統合できる可能性を否定していない。二つ目と三つ目の作業項目を TC39 の TG1 とは異なる作業部会に割り当てることが提案された。

期待された通り、TG1 プライベートメーリングリスト⁹での反応は一般に否定的だった。ただ Apple の Maciej Stachowiak [2007b] も ES4₂ の向かう方向について疑念を抱いていたことが明らかになった。最も声高に反対意見を表明したのは Brendan Eich [2007b] で、彼は静的型付けをはじめとする ES4₂ の機能はパフォーマンスの改善と大規模アプリケーションの構築に不可欠だと擁護した。さらに Eich は Microsoft と Yahoo! が提案を作成した動機を疑問視した [2007b]。

メールでの議論は 3 月の会合が近づくにつれ白熱した。Pratap Lakshman は会合の二日目の多くを Microsoft と Yahoo! の提案に関する議論にあてることを提案したのに対して、Brendan Eich は一時間で十分だと主張し、彼と Jeff Dyer は会合の大部分を ES4₂ のハッカソンとして続ける要望を述べた。Eich と Dyer は ES4₂ の活動が Microsoft も設立に手を貸した長い歴史を持つ TG1 で得られたコンセンサスによるものであると主張し、今になって Microsoft と Yahoo! がコンセンサスを破るのは適切なのかと疑問をぶつけた。これに対する Allen Wirfs-Brock の返答は、TG1 に定期的に参加する Ecma 通常会員は三団体あり、Microsoft と Yahoo! で二団体なのだから、コンセンサスは既に存在しないというものだった。

3 月の会合 [TC39-TG1 2007c] の出席者はいつもより多かった。Microsoft からは Allen Wirfs-Brock と Pratap Lakshman に加えて Scott Isaacs と Chris Wilson も出席した。Isaacs は Microsoft の live.com ウェブアプリケーションを担当するフレームワーク技術者で、オリジナルの DHTML¹⁰ を開発したメンバーの一人である。Wilson は Internet Explorer を担当するプラットフォーム技術者で、W3C のウェブ規格策定に活発に関与していた。Isaacs と Douglas Crockford の二人はブラウザの ECMAScript 実装間で相互運用性が保証されない状態でウェブアプリケーションを開発する難しさについて語った。Crockford は ES3 に含まれる機能の仕様をさらに完全なものにすればウェブの安定性が増し、相互運用性の問題を解決するのに役立つと主張した。Isaacs が特に懸念したのは、新しい構文的な言語拡張によって新しいウェブページを古いブラウザで開いたときにパースエラーが発生するようになることだった。また Isaacs と Crockford の二人はウェブアプリケーションにおいてセキュリティとプライバシーに関する機能の重要性が高まっていることを強調した。これに対して Eich, Dyer, Graydon Hoare は、ES4₂ の型システムはブラウザプログラミング環境で安定性、堅牢性、性能を向上させる基礎だと反論した。Wirfs-Brock は現在の仕様を進化させた「ES3.1」仕様を策定すれば、ウェブの安定化に寄与する上に ES4 を実装して普及させるための時間も生まれると主張した。Eich はこういった主張が規格ベースの HTML/CSS/JavaScript プラットフォームの競争相手として .NET ベースのリッチインターネットアプリケーション用ウェブプラットフォーム¹¹を構築するのに必要な時間を稼ぐための Microsoft による時間稼ぎに過ぎないのではないかという疑念を抱いた。彼は ES4 には既にコミュニティから大きな注目が集まっており、Microsoft と Yahoo! が強引に策定を遅らせれば両社のイメージに傷が付くことになると警告した。

最終的には「ES3.1」の仕様策定にも一定の価値はあるかもしれないという合意があり、Microsoft と Yahoo! は TG1 の中で ES3.1 に取り組むことになった。これは Wirfs-Brock が会合の準備をする中で期待した通りの結果だった。ES4₂ の支持者は ES3.1 が ES4 の部分集合でなければならず、従って ES4₂ 用に作成されている仕様スタイルで執筆されなければならないと強く要求した。ただ Wirfs-Brock はこのときも ES4₂ が完成および公開まで至る可能性は低いと考えていたので、この制約を特に気にしなかった。

Pratap Lakshman, Allen Wirfs-Brock, Douglas Crockford は ES3.1 プロジェクトの立ち上げに取り掛かった。Wirfs-Brock と Crockford は 3 月 29 日に顔を合わせ、4 月の TG1 会合前に配布する予定の初期提案のドラフトに Lakshman が取り組むべきだということで合意した。Crockford は設計指針をいくつか提案し、さらに 3 月の会合での合意に反するのを承知で ES3.1 仕様を ES3 仕様と同じスタイルで執筆することを提案した。ES4₂ 仕様の最終形がまだ固まっていないときにその仕様と同じ定式化を使うのには問題があった。

4 月 15 日、Pratap Lakshman は「ES3.1 提案の作業ドラフト」という名前で wiki にいくつかページを作成した [Lakshman et al 2007]。そこには目標のリスト、後方/前方互換性の要件、そして設計指針が含まれていた (図 27)。また追加候補とされる 20 個ほどの修正、変更、新しい機能の説明が載っていた。その多くは Douglas Crockford による「推奨される ECMAScript への変更」という文書から取られたものだった。彼は 4 月の初めにその文書を更新し、以後 ES3.1 への貢献を通してさらに二回更新する [Crockford 2007b, c, d]。

ES3.1 の作業ドラフトは 4 月の会合で議論された [TC39-TG1 2007a]。ES4₂ グループの大きな懸念は ES3.1 と ES4 の関係だった。彼らは ES3.1 の取り組みが ES4 と同じく ML による参照実装を通した仕様記述テクニックを使うことを望んだ。ES3.1 グループは反対し、仕様のメンテナンスリリースで記述テクニックを変えるのはあまり役立つことだとは思わないと主張した。最終的には Jeff Dyer が ES3.1 の人々は違う視点を持っているのだから彼らは今していることを続ければいいと提案した。ただ Dyer は ES3 仕様に関連して行われることは他のグループにほとんど関心を持たれないだろうと警告した。4 月の残りと 2007 年の夏にわたって、二つのサブグループは自分たちのプロジェクトにほぼ独立して取り組んだ。ES3.1 グループは既存の ES3 仕様と実装を調査し、仕様が曖昧だったり実装が仕様に従えていなかったりするために生じている相互運用性の問題を洗い出した [Lakshman 2007c; Wirfs-Brock 2007b; Wirfs-Brock and Crockford 2007]。ES4₂ グループは様々な提案を具体化するツールとして ML の参照実装を使い続けた。

ES4₂ プロジェクトは依然として非常に挑戦的なスケジュールを立てていた。2007 年 5 月の初めに提出された Ecma 調整委員会への報告書 [Miller 2007] では 12 月の Ecma 総会で承認を受けられるよう ES4₂ の最終ドラフトを 2007 年の 10 月までに完了させるとしている。2007 年 6 月 8 日、Dave Herman [2007; 補遺 K] は Lambda the Ultimate¹² で ES4₂ 参照実装の「M0¹³」リリースが利用可能になったことを発表した [TC39-ES4 2007d]。

6 月の会合 [TC39-TG1 2007b] では ES4₂ の「仕様執筆プロセス」をすぐに開始しようという呼びかけがあった。しかし大きな技術的設計の問題が解決されずに残っており、新しい問題も頻繁に見つかっている状態だった。例えば 7 月の会合 [TC39-TG1 2007e] では、実行時における構造型の型検査に重大な問題が発見された。

9 月 7 日の会合の TG1 議長報告書 [Eich 2007d] には、2007 年中の完了は現実的でないので完了予定を 1 年延期して 2008 年 9 月に変更したと記されている。Lars Hansen が ES4₂ の編集者となることも報告された。この報告書は Yahoo! と Microsoft が抱いていた ES4₂ に関する疑念や当時作業が進んでいた ES3.1 について言及していない。

9 月 の会合 [TC39-TG1 2007d] での目標は ES4 wiki に残っている未解決の ES4₂ 提案の全てに対して受理、破棄、将来の版に延期のいずれかを決めることだった。ES4₂ ワーキンググループの視点で言うと、解決すべき提案の中には ES3.1 の取り組みをまとめた「ES3 のメンテナンス」という名前の提案も含まれていた。会合に出席した Jeff Dyer はその日の終わりまでにその提案の受理または破棄を決定する (そして wiki でそのようにマークを付ける) 必要があると考えていた。もし破棄されれば、それは TG1 の作業項目から削除される。会合の議事録を見ると、「ES3.1 のメンテナンス」提案の受理はあり得ないと彼が考えていたことがはっきりと分かる。Brendan Eich の立場はこれより複雑だった。ES4₂ の主導者として Eich は ES3.1 の取り組みを邪魔に感じており、Microsoft がそれに関与する動機を強く疑っていた。彼は ES4₂ と競争する形での ES3.1 の策定を望まず、グループ内での分裂を防ぐために ES3.1 の支持者は TG1 を去って、彼らのための新しい TG の設立を TC39 に頼んでみてはどうかと提案した。しかし TG1 の議長として彼は ES3.1 グループの分裂を避ける手立てを見つけることを望んでおり、ES3.1 の取り組みを Ecma 技術報告書のようなフォーマルでない、ISO と関係のない、標準化過程とは別の文書としてまとめることも提案した。こういった議論は白熱し、ES4₂ 支持者と ES3.1 支持者の双方にとって不愉快なものになった。その中で Pratap Lakshman は、イラ立ちながら「現在の ES4 の提案を一部であれ全体であれ我々は支持しないし、合意もしない。我々は関心のある TG メンバーと共に現在の仕様を ES4 よりインクリメンタルに改訂する提案の策定作業を続けるつもりだ」と発言した。これは特に政治的な発言ではない上に「ES4₂ の全体」という点が少し不正確ではあったものの、Microsoft の立場をよく表していた。最終的に「ES3 のメンテナンス」提案のステータスという目下の問題は、ES3.1 のページを「提案」という wiki の名前空間から「ES3.1」という新しい名前空間に移すことで解決された。しかし ES3.1 支持者と ES4₂ 支持者の双方が思い描く目標が衝突している問題は解決されず、この対立はすぐに広く知られることになった [Kanaracus 2007]。

18.4 Harmony の模索

2007 年の間、活発な TG1 参加者の数は増えていった。この理由の一端は ES3.1 と ES4₂ の両グループが新しいメンバーや活発に参加していなかったメンバーに参加を呼びかけたためである。活発に参加していなかった IBM と Apple が定期的に TG1 会合へ代表者を送り、オンラインの議論に参加するようになったのも同年の春だった。Google は通常会員として Ecma に加わり、Waldemar Horwat を Google の総会代表者および主任 TG1 代表者として任命した。Dojo Foundation は非営利メンバーとして加わり、代表者は Alex Russell と Chris Zyp だった。Allen Wirfs-Brock と Douglas Crockford の二人はオブジェクト機能¹⁴ (OCAP) 言語の専門家 Mark S. Miller [Miller 2006] に参加を促し、Google で働いていた Miller は Google の代表者として会合に参加し始めた。何人かの新しい参加者は言語設計者とエンジン実装者が占めていたグループにウェブ開発者の視点をもたらした。

2007 年の初め、TG1 の目標は完成した ES4₂ の仕様を 10 月までに手に入れることだった。この目標は達成されなかったものの、10 月に Lars Hansen [Hansen 2007e] は初期のドラフト [Hansen 2007b] に「ECMAScript 第 4 版言語概要」という題名が付いていた文書を完成させた。これは詳細な仕様ではなく、ES4₂ の主要な機能をまとめた 40 ページの文書である。要旨の第一段落は ES4₂ を次のように説明している:

ECMAScript 言語の第 4 版 (ES4) は、Ecma が 1999 年に ECMA-262 規格として承認した第 3 版 (ES3) を大きく進化させたものである。ES4 は ES3 と互換で、大規模プログラミング (クラス、インターフェース、名前空間、パッケージ、プログラムユニット、省略可能な型注釈、静的な型検査と型検証)、進化的なプログラミングとスクリプティング (構造型、ダックタイピング、型定義、マルチメソッド)、データ型構築 (被パラメータ化型、ゲッターとセッター、メタレベルメソッド)、制御抽象化 (適切な末尾呼び出し、イテレータ、ジェネレータ)、イントロスペクション (型メタオブジェクト、スタックマーク) の重要な機能を持つ。

この文書は最終的に ES4₂ の構想を最もよく説明する文書となった。しかし Allen Wirfs-Brock [2007c] と Douglas Crockford [2007a] はこの文書が「ECMAScript 第 4 版」という名前を勝手に使っており、Ecma 規格としての承認が目前に迫った言語を説明しているような印象を与えることに異議を唱えた。加えて文書の導入部には言語の設計が Ecma TC39-TG1 のコンセンサスを表すと書かれており、TG1 内に存在した ES4₂ の設計への反対意見には全く言及が無かった。いくらかの交渉の後、Lars Hansen はタイトルの最初に「提案された」を付け足し、文書が提示する設計の標準化に反対する TG1 参加者が何人かいることを説明した段落を導入部に加えることに合意した。この文書と参照実装のコードを配布するために ES4₂ チームのメンバーが立ち上げていたウェブサイト [TC39-ES4 2007c] に対しても同様の問題が指摘された。こういった事件により、ES4₂ 支持者は ES3.1 の取り組みを無視あるいは軽視したまま ES4₂ をどう一般に宣伝していくのかという ES3.1 支持者の懸念は強くなった。

Allen Wirfs-Brock は Microsoft 社内の標準化グループと定期的に連絡を取っており、そのグループには Ecma 調整委員会 (Co-Ordinating Committee, CC) のメンバーだった Isabelle Valet-Harper が属していた。CC [Ecma International 2007b] は TG1 が文書と会合議事録の保存に使っていたプライベートな wiki が外部でホストされており、Ecma 事務局および一般の会員からアクセスできない点を問題視した。また事務局は議事録や会合報告書、そして重要文書のコピーが Ecma 内部の会員限定ウェブサイトに投稿できるフォーマットに整形されることを要求した。これを受けて TG1 は、要求に応じる最も簡単な方法は TG1 の wiki 全体を一般に公開することだと判断した [TC39 2007a]。

2007 年 10 月の CC 会合 [Ecma-International-2007a] では TC39-TG1 の運営に関する議論があった。2001 年以前、TC39 の設立趣意書は ECMAScript のみに触れていた。しかし 2001 年に設立趣意書は他のプログラミング言語やプラットフォームを含むよう拡張され、それぞれの標準化の大部分は独立した TG が担当することになった。Ecma 事務局は一般に TC レベルの活動を監督することに集中し、TG レベルの活動はあまり気にかけていなかった。2007 年まで TG1 の運営は TC39 や事務局からの監督が無くても自走できていたものの、現在の TG1 は Ecma のポリシーおよび手続きに従っていないのではないかという懸念が CC メンバーの一部から表明された。また当時行われていた取り組みに関するコンセンサスが TG1 から報告されていないことも話題に上がった。TC39-TG1 を完全な TC に昇格させて事務局の監督が行き届くようにすることも解決策の一つとして意見が出た。当時の Ecma プレジデント John Neumann は状況をはっきりさせるため 2007 年 11 月の TG1 会合に参加することに合意した。

その会合 [TC39 2007b] の大部分は CC が抱いている懸念の周知と、ES3.1 および ES4₂ におけるコンセンサスの明らかな欠如に関する議論に費やされた。John Neumann は TG1 から Ecma の他の部局への開催地や議題の通知、あるいは会合の報告書や重要文書といったコミュニケーションが欠如していることへの懸念を強調し、変化が必要だと強く主張した。また彼は、Ecma の視点からすると TG1 はオープンすぎることがあるという注意も行った。特に Ecma の上層部は TG1 メンバー間の不和がウェブログやフォーラムを通して公開で議論されていることを問題視していた。Neumann は ECMAScript 関連の活動を TC39 の単一の焦点にすることを提言するつもりだと伝えた。これは事実上 TC39-TG1 から TC39 への改名である。この改名を行えば ECMAScript の取り組みが Ecma 内でよく見渡せるようになり、Ecma 事務局からの直接的な監督が可能になる。現在活動中の TC39 内の TG は新しく作成される TC49 の TG に移される。この再編成は 2007 年 12 月の Ecma 総会で承認され、2008 年 1 月をもって TC39-TG1 は再び単なる TC39 となった。

この 11 月の会合では TC39 のこれからの活動に関する議論も行われた。Douglas Crockford はマッシュアップ^語やセキュリティセンシティブなアプリケーションをサポートできる Secure ECMAScript^語 を策定するための新しいプロジェクトを立ち上げるべきだと提案した。Allen Wirfs-Brock [2007] は Microsoft としての新しい意見書を配布した。この意見書では現在進行中の ES4₂ の取り組みを続けるのではなく、ES3 の言語と仕様を進化的に前に進めるアプローチを取るべきだという意見が述べられた。Crockford は Yahoo! がこの意見を支持することを表明した。Lars Hansen は「3.1 提案は難航しており、ちょうど 9 月に脇に追いやられたところだ。我々がここで取り組むのは ES4 であって 3.1 ではない」と主張した。Brendan Eich は ES3.1 に関して 4 月から特に進捗が無いこと指摘した。Wirfs-Brock は ES3.1 が脇に追いやられたことを否定し、 ES3 における相互運用性の問題を調査した複数の文書 [Lakshman 2007c; Wirfs-Brock 2007a, b; Wirfs Brocks and Crockford 2007] が ES3.1 策定の足掛かりとして作成されていると反論した。

今後 TC39 が行う活動の選択肢に対する関心を調査するための投票が行われた。9 つの組織を代表する出席者全員は ES4₂ の取り組みの続行を支持した。ES3.1 の取り組みの続行は Microsoft, Yahoo!, Apple, Google, Mozilla によって支持され、Secure ECMAScript の取り組みの開始は Microsoft, Yahoo!, Apple, Google によって支持された。Ecma の視点からすると、これだけの支持は新しい TC39 内でこういった活動を行うのを正当化するのに十分だった。Microsoft が ES4₂ の続行を支持しているのは意見書の記述と矛盾している。この点について Allen Wirfs-Brock は、このときも ES4₂ は最終的に失敗すると予想していたので、わざわざ衝突を起こす必要はないと考えたと記憶している。

2007 年 12 月の Ecma 総会会合の後 Isabelle Valet-Harper は新しい TC39 の議長を誰にすべきかを Allen Wirfs-Brock と話し合った。当時の Ecma 規則は通常会員の代表者が TC の議長でなければならないと定めていたので、非営利会員の Mozilla に所属する Brendan Eich は議長になれなかった。Wirfs-Brock と Valet-Harper は ES4 と ES3.1 および TC39 が手を付ける可能性のあるプロジェクトに関して強い意見を持っていない人物が望ましいということで意見が一致した。Valet-Harper は Microsoft と Adobe が手を組んでそれぞれ John Neumann に働きかけ、協同で彼を TC39 の議長に推薦することを提案した。Adobe はこのアイデアに賛成した。この方針は 2008 年 1 月の TC39 会合で告知され、2008 年 3 月の会合 [TC39 2008c] で Neumann は TC39 の議長として選出された。

2007 年 11 月、Lars Hansen [2007c] は「編集者による報告書」を準備した。そこでは 2008 年 10 月に ES4₂ のドラフトを完了させ 2008 年 12 月に Ecma 規格として公開することを目標に据えた新しいスケジュールが示された。また彼は ES4₂ が持つ意図的な ES3 との非互換性をまとめた論文 [Hansen 2007a] と、漸進的型付けがどのように進化的プログラミングをサポートするかを説明したチュートリアル [Hansen 2007d] を執筆した。2008 年 2 月、Jeff Dyer [2008a] は取り組みの新しい計画を提示した。そこでは依然として 12 月が目標とされ、5 月、7 月、9 月 の中間ドラフトが予定された。また Hansen と Dyer [2008] は「提案された ECMAScript 4 の中で遅らせるべき機能」と題された意見書を提出した。この意見書では、当時の ES4₂ の計画が「奇妙、有用性が不確か、あるいはコストの高い」機能をいくつか持っており、それらを遅らせれば次の効果が得られると主張された:

2008 年中に仕様を完成させられる可能性が大きく高まり、コミュニティの賛同が得られ、実装の複雑さが管理しやすくなり、規格について後悔するリスクが低くなり、そして ── 非常に運がよければ ── TG1 メンバー間の不和が解消される。

遅らせるべきと提案された機能は、数値変換、int と uint、十進算術、演算子オーバーロード、総称関数、wrap¹⁵、ジェネレータ、適切な末尾呼び出し、nullable、プログラムユニット、構文が変わった with、復活した eval、そして名前空間フィルタだった。こういった機能を遅らせるべき理由をそれぞれ正当化した後、意見書は ECMAScript が今後どのように進化すべきかに関する Adobe の新たな考えを説明した:

ES はこれまでの ES4 で我々が経験したよりも段階的に進化する必要があると我々は考える。E262-3 [ES3] の公開から E262-4 [ES4] の公開までに 9 年の間が空いているという事実それだけでは、大量の新しい機能を一気に追加する正当な理由にならない。それぞれの機能はその役割を持たなければならず、経験が我々を導かなければならない。ただそうは言っても、本稿は「ES3.1」 (正確には「ES3.01」と呼ばれるべきもの) のような骨抜きの仕様を提唱したいのではない。我々が提唱するのは、80% の解決案「ES3.8」を今は採用しておいて、近い将来、必要性が明確になったときに新しい要望に沿って言語を成長させようということである。

Adobe の立場を表明したこの文書に関する実質的な議論の記録は TC39 会合の議事録あるいはプライベートおよびパブリックの TC39 メールチャンネルに存在しない。唯一記録された反応は IBM が十進算術の削除に反対したことだけである。同じ時期、ES4₂ の設計、方法論、プロセスの様々な側面に対する批判がメーリングリスト es4-discuss^語 に数多く投稿された。影響力を持つフレームワーク開発者からの批判もあれば、Apple と Google の ECMAScript 実装者からの批判もあった。2008 年 3 月、ES4₂ 設計グループはモジュールの定義に利用されるパッケージの抽象化に基礎的な意味論的問題があることを発見する [Dyer 2008b]。さらに 5 月には名前空間に関する問題が発見された [Stachowiak 2008b]。

2008 年の春を通じて、Lars Hansen はフィードバックを受けるために ES4₂ 仕様の初期ドラフトを節ごとに投稿していった。5 月 16 日、Hansen [Hansen 2008] は仕様の第 1 ドラフト [Hansen et al. 2008a, b, c] を発表した:

添付ファイルは ECMAScript 第 4 版提案仕様の非常に不完全な第 1 ドラフトだ。このドラフトは簡単な紹介、表層構文、そして中心的な ── 値、ストレージ、型、名前、スコープ、名前解決の ── 意味論の説明から構成される。これ以外の部分は準備ができたら追加される。おそらくは月に二度 (程度) のスケジュールになる。

これと同じ時期、ES3.1 サブグループは ES3 仕様を継承した仕様の作成を開始した。参加者は増加しており、Google, IBM, Dojo Foundation, Apple といった組織の代表者が参加していた。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 Simth¹⁶, Adobe の Ecma 総会代表者 David McAllister が参加する通話会議を開催した。そこで McAllister と Smith は、Adobe が ES4₂ 活動のサポートを取り止める意思を持っており、割り当てられたスタッフは別の活動に移る予定であるという発表を行った。これが ES4₂ の終わりであり、この事実を広く知らせるときは注意深い調整が必要になることを出席した全員が理解した。彼らは次回の 7 月の会合で TC39 の全メンバーにこの事実を伝え、その会合で一般への公表について考えることに合意した。Adobe の決断に対して事前に警告していた Eich は Adobe に異議を唱えることなく、TC39 の労力を ES3.1 の取り組みを完了させることに注ぎ、将来への共通計画を過去の ES4₂ の設計判断に制約されない形で策定することへの期待を述べた。次回の会合でその考えを発表することに彼は合意した。新しい取り組みの第一歩として、オスロで 7 月 23–25 日に開催される会合 [TC39 2008f] の議題に「ECMAScript の調和」が追加された。

2018 年にメールで行われた議論で、Jeff Dyer と Lars Hansen は ES4₂ からの撤退は彼らのマネージャ Dan Smith と相談した上での決断だったと語った。彼らは ES4₂ は完成しないと確信するまでになっていた。ES3.1 ワーキンググループのメンバーからの反対が ES4₂ を失速させており、ES3 に修正を加えるという現状重視のアプローチが TC39 内で優勢になるにつれ ActionScript 3 の静的な機能を取り込む余地が失われていったと彼らは感じていた。

Cormac Flanagan は 2019 年の個人的な会話で、Adobe が撤退したのは実際には ES4₂ の問題を認識していたからではないかと推察した。彼は ES4₂ を振り返りながら次の点を指摘した:

• ES4 で計画されていた大きな言語拡張は (今になって考えれば) リスクが高く、非保守的なアプローチだった。
• 標準化プロセスに最先端の言語[技術] (特に静的型システムの追加に関するもの) が含まれていた (10 年以上が経過した現在 [2019 年] でさえ、未解決の研究課題やパフォーマンスの問題が存在する [Greenman et al. 2019])。ES4 におけるパフォーマンスの懸念に触発された論文 Space-Efficient Gradual Typing が TFP'07 で公開された [Herman et al. 2011] ことは、この取り組みが研究に近い性質を持っていたことを示しているはずだ。
• ES4 は「(コミュニティの) 賛同」を得られないのではないかという懸念が TC39 内に存在した。これは確かに問題ではあったものの、致命的なものでは決してなかった。
• ML による参照実装は以降の版で採用されなかったものの、実行可能な悪くないアイデアだった。今になって考えると、ES3 に対する参照実装から始めた方が良かったかもしれない。

Douglas Crockford [2008c] はブログ記事で、ES4₂ の失敗は有用性の証明されていないイノベーションを過度に取り込み過ぎたことによるものだと指摘した:

標準化団体はイノベーションに適した場所ではないということだ。イノベーションには研究所やスタートアップがある。規格はコンセンサスによって形作られなければならず、論争と無縁でなくてはならない。ある機能が固まっておらずコンセンサスを得られないなら、その機能は標準化の候補になるべきでない。「委員会による設計 (design by committee)」という言葉に悪い意味があるのにはきちんとした理由がある。標準化団体は設計の仕事に手を出すべきではない。標準化団体は注意深く仕様を作成するという意義深く難易度の高い仕事に集中するべきである。

Allen Wirfs-Brock は Adobe が ES4₂ からの撤退を発表したときに安堵したことを覚えている。Internet Explorer を担当する Microsoft 上層部が Internet Explorer の軽視は戦略的ミスだと理解したことを Wirfs-Brock は認識していた。IE のマーケットシェアが Firefox に大きく奪われており、さらに Google が新しいブラウザを準備していることを上層部は知っていた。当時 Web 開発者の間には Microsoft がウェブの技術的進歩を妨げているという認識があり、Microsoft はこれに苦慮している状況だった。この認識は Microsoft が ES4₂ に反対したこと、特に Brendan Eich と Microsoft の Chris Wilson の間で非常にパブリックな形で交わされた議論 [Kanaracus 2007] によってさらに強まった。2008 年 6 月の時点で Wirfs-Brock は、Microsoft が ES4₂ に表立って反対するより賛成に回った方が良いと全くのビジネス上の理由から判断するのではないかと心配していた。

オスロで開かれた TC39 会合 [TC39 2008g] の大部分は達成可能な目標の共通集合を中心とした TC39 の調和という考えの説明と周知に費やされた。全体的な計画は 2009 年内に ES3.1 リリースを完了させることに TC39 が一体となって集中し、それと同時に大きな変化を見据えた ES3.1 の次の版についても協調して立案するというものだった。「Harmony調和」というコードネームが付けられたこの計画は、これまで 10 年にわたって行われた ES4 の設計判断に縛られないことになった。どの機能が「調和的」でどの機能が「調和的でない」かについては会合で議論があったものの、基本的な計画に対する真剣な反対意見は会合および会合に出席できなかったメンバーとのメールを通した議論で表明されなかった。この計画のステップは会合の後に作成されたホワイトペーパー [Eich et al. 2008] にまとめられた:

1. 全ての団体が完全に協調して ES3.1 に取り組み、来年の初めに相互運用可能な二つの実装を完成させることを目標とする。
2. ES3.1 が完成した後の次のステップに協調して取り組む。このステップには構文的な言語拡張が含まれることになるものの、その意味論的および構文的なイノベーションは ES4 の提案より控えめになるだろう。
3. ES4 に存在した「パッケージ」「名前空間」「事前束縛」の概念は検討対象から外す。
4. ES4 に存在するこれ以外の目標やアイデアについても、委員会のコンセンサスを保つために書き換えを行う。例えば、提案されている ES3.1 の言語拡張と ES3 に存在する既存の概念の組み合わせをベースとしたクラスという考え方など。

8 月 13 日、Brendan Eich [2008b; 補遺 M] はいくらか個人的なバージョンのホワイトペーパーを es4-discuss メーリングリストに投稿した。8 月 19 日に Ecma International [2008] は短いプレスリリースを行い、今後 TC39 は ES3.1 の取り組みに集中することを発表した。8 月 15 日に録音されたポッドキャスト [Openweb 2008] で Eich は ES4₂ の失敗を招いた技術的および実用的要因に関して自身の意見を説明し、調和の取れた TC39 の将来に関する期待を語った。ポッドキャストの冒頭で彼は「名前空間を通して事前束縛と事後束縛を統一する試みは失敗した」と述べ、終盤で次のように説明した:

まずパッケージが我々 ES4 によって切られた。あれは我々が切った。次に名前空間が我々 ES4 によって切られた。あれは我々が切った。3.1 の機嫌を取るために切ったのではない。名前空間に問題があったからだ。

...

これは我々と彼らの対決における譲歩ではない ── これ [ES4₂] は実際には Waldemar [Horwat] の仕様まで (あるいは Common Lisp にまで) さかのぼる様々なアイデアを統合する良い試みだったのだが、ウェブでは上手く行かないと分かったということだ。