Adam Klein氏は、 TC39ミーティングの検討からObject.observeプロポーザルを撤回することを発表した。
彼の考えを説明する投稿の中で、Klein氏は「世界は変化している」と言う。
3年以上前、 Weinstein氏、Erik Arvidsson氏と私は、MDV ("model-driven views")のデータバインディングシステムの原始的な基礎を設計と実装を検討しました。3年経ち、世界は様々な方向に変化しました。(EmberやAngularのような)他のデータバインディングフレームワークが興味を持ちましたが、[Object.observe]とマッチさせるように彼らの既存のモデルを進化させることが困難でした。
InfoQのインタビューにおいてKlein氏は、Object.observe"は、[様々なフレームワーク]のすべてで使うことができる低レベルでプリミティブな本質的な部分に昇華させる試みでした。しかし、共通のプリミティブを様々なプログラミングモデルに完全に一致させるのは困難でした。"
Object.observeの約束は簡単なものだったが、実際の実装において問題が判明した。ある時Angular 2チームは、変更の検出にObject.observeを実験したが、パフォーマンスの問題があり断念した。AngularチームのIgor Minar氏は、InfoQに"ランタイムコストは小さくなかった"と話した:
O.o()はV8の多くの最適化パスを無効化した結果、変更通知の非同期伝達は、フレームワークとブラウザの間で多くのコンテキストスイッチが必要になり、フレームワークでマクロ最適化を実行可能にすることが難しいため、observedじゃないものに比べて大幅に遅くなります。
GoogleのPolymerチームのリードであるMatt McNulty氏は、Object.observeから距離を置くことに対して同様の理由を表明した。 複雑なアプリは最終的に"数万回のO.oを呼び出すことになる"と彼はInfoQに話した。"これはデバッグが面倒で、奇妙なパフォーマンス特性を持っていました。Chromeにおいては、セットアップ時間が長かったが、実行時間は短かったのです。Polyfillされたブラウザでは、その逆でした。"
不変データ構造がJavaScript開発者の中で一般的になったように、オブジェクトの変異が議論になる余地を注視しておく必要がある。Minar氏は、"人気が上昇した不変データ構造、関数型プログラミング、一方向のデータフロー、O.o()でのレンダリングは、最初に考えられた時よりもインパクトが小さい"と言う。
TC39標準化プロセスごとにプロポーザルは、ステージ3に進む前に"大量の使用量と外部フィードバック"を集める必要がある。Object.observeは現在、ステージ2である。 Klein氏によるとObject.observeは、"Chromeページビューの0.0169%"しか使われておらず、ChromeとOperaのみがサポート (どちらもBlinkエンジンをベースにしている）だけである。プロポーザルの撤回は標準化プロセスが機能していることを表している。McNulty氏は、"最先端のプラットフォームで、私たちは変革を恐れてはいけません。提案された機能は、吟味され、システムの稼働において本当にすべきことがキャッチできていない場合には、計画段階に戻されます。"という。
Klein氏はInfoQに同意する:
TC39プロセスは、完全なECMAScript仕様にマージされるまでのアイディアを培養するためのプロセスです。プロセスは各段階で追加のフィードバック、必要な場合には言語に含めるべきではないフィードバックも集めるように設計されています。慎重な検討の結果、O.oがTC39から撤回され、公式言語から機能を非推奨にしたことは、プロセスの成功であると考えるべきでしょう。
V8からObject.observeが削除されるとき、JavaScriptエンジンに依存するNode.jsに破壊的変更を強制する。 Node.js FoundationのコミュニティマネージャーであるMikeal Rogers氏はInfoQに対し、長期サポート(LTS:Long Term Support)バージョンのNode.jsは心配する必要がないと語った:
将来のメジャーリリースでは破壊的な変更が発生します。LTSのV8はメジャーアップグレードしないため、LTSには影響しません。
TC39は、ECMAScriptプログラミング言語の標準化を進める標準化委員会である。