進化する ECMAScript

Article
12/26/2011

本記事は、マイクロソフト本社の IE チームのブログから記事を抜粋し、翻訳したものです。

【元記事】Evolving ECMAScript 2011/11/23 3:08 AM

Web および Web アプリケーションが進化し続けるためには、Web プログラミング言語の不断の改善が必要です。

今日の JavaScript 標準には、リッチでグローバルな Web アプリケーションを構築するために不可欠な、いくつかの基本オブジェクトとライブラリヘルパーが含まれていません。

クパチーノにある Apple 本社で先週行われた ECMA TC39 の会合で、マイクロソフトは、Math 、 String 、および Number オブジェクトの機能ならびにグローバリゼーションの強化を提案し、その参照実装を提供しました。

他のコミュニティメンバーも意見できるように、これらの参照実装は HTML5 Labs で公開中です。ぜひプロトタイプをダウンロードし、使用法のデモを示すサンプルの Web ページをいじってみてください。試していただいて、ご意見やご提案があればコメント欄にお寄せください。

この提案で追加されるオブジェクトとライブラリヘルパーは、以下のように少数ですが、これらにより、対応が待たれていた数多くの機能が提供されます。

Math	String	Number
cosh, sinh, tanh acosh, asinh, atanh log2, log10, log1p, expm1 sign trunc	startsWith, endsWith contains repeat toArray reverse	isFinite isNaN isInteger toInteger

Number Format	Date Format	Collator
format ( number )	format ( date )	compare ( x , y )

このプロトタイプ実装は、Windows 7 で実行する場合、363 のロケール、18 の数体系、多くの日付パターンのほか、グレゴリオ暦、イスラム暦、ヘブライ暦、仏暦、韓国暦、および和暦もサポートします。

HTML5 Labs で公開された過去のすべてのリリースと同様、これは無期限に有効なサポート対象外のコンポーネントです。評価目的のみに使用し、実稼働アプリケーションでの使用は避けてください。

提案の詳細

コンピューティング資産を大量に消費する Web アプリケーションを構築しようとするとすぐに気付くことですが、JavaScript に組み込みの Math ライブラリには、C++、.NET、Java、および Python といった他のプログラミング言語プラットフォームでは長年提供されている cosh や log10 などの基本的機能が欠けています。また、String および Number についても、今日のプログラミング言語プラットフォームに共通の基本機能である、String が特定の文字列で始まるかどうかの検証や、Number の型が整数かどうかのチェックをサポートする必要があります。これらについては、Math、String、および Number API への機能追加提案で言及されています。

これまで Web アプリケーションのグローバル展開がネイティブアプリケーションよりも困難であった理由は、JavaScript が OS 標準の日付形式および通貨形式に対応していなかったためです。

上の参照実装で提供されているグローバリゼーション API を使用すれば、アプリケーションは、ロケール固有の数値形式と日付形式ならびに他言語の文字列を正しく処理できます。このライブラリによって、開発者は特定のロケールの日付と数値を表示し、文字列の並べ替えおよび検索を目的とした照合オプションを設定できるようになります。また、日付形式および数値形式を設定して、イスラム暦のカレンダーを使用したり中国元通貨に合わせて数値を表示したりすることができます。

こうした改善により、JavaScript アプリケーションで、ロケール固有の日付や数値を正しく表示するためにサーバーへのラウンドトリップを実行する必要がなくなり、エンドユーザーへの応答速度が向上します。

Web 環境改善における JavaScript の役割

これらの提案は JavaScript の進化という大きな流れの一部にすぎません。1998 年の時点では、複雑な JavaScript アプリケーションといってもコードの行数は数十行程度でした。2008 年になると、Hotmail、Gmail、および CNN.com など、当時最先端の Web アプリケーションで数十万行が実行され、今日では 100 万行もの JavaScript コードを使用した Web アプリケーションが存在します。

これらの Web アプリケーションはデスクトップで実行するアプリケーションに近づいています。すなわち、ページの切り替えが減り、クライアント側での処理が増え、頻繁にサーバーとのラウンドトリップを繰り返すのではなく、データの不定期な急増のみサーバーで対応するようになっています。

JavaScript はこれらのニーズに応えるように進化しています。ここで重要なのは、開発者がこれまで各自の Web サイトに投じてきたすべての投資とスキルセットを尊重し、新機能の互換性を重視した段階的な導入を行っているという点です。

この原則の管理団体である TC39 が推進するコミュニティプロセスを、私たちは強く支持しています。

TC39 の ECMAScript 5 に対する取り組みは、Web プラットフォームにおける Javascript の着実な前進と言えます。ES5 の設計に用いられた原則の一部 (以下を参照) は、JavaScript 標準の将来のバージョンが準拠すべき指針を示しています。

“text / javascript” の基本的な構文を保持して、開発者のスキルセットを引き続き利用可能にし、今日と将来の JavaScript のシームレスな互換性を提供する。
必要に応じて追加可能な機能を提供し、開発者が最小限の努力や学習でより多くの価値を得られるようにする。
ローカルで検出可能な機能を提供して、開発者が幅広い種類のブラウザーで正しく機能するアプリケーションを構築できるようにする。
可能な場合は、機能をサポートしていないブラウザーに対して、より低速な代替ライブラリ (‘Polyfill (ポリフィル)’) を使用可能にする。

マイクロソフトは TC39 と協力して、次期 ECMAScript 標準に向け、上記のアプローチをできる限り広範囲に適用すべく尽力しています。

JavaScript ランタイムの推進

将来に目を向けると、JavaScript のコアランタイムをさらに進化させるのに絶好のチャンスが到来しようとしています。私たちは、HTML5 Web サイトを構築する開発者との議論から、最も重要なのは以下の領域であると認識しています。

ネイティブブラウザープラットフォームと円滑に統合。 HTML5 で File API、Canvas Pixel Array、および XHR2 などの最新 API が導入されたことにより、JavaScript でも、バイナリデータストリームとの相互運用性を強化する必要性が高まっています。この喫緊の課題に対処するため、多くの Web コミュニティからたくさんの提案 (Khronos 案、CommonJS 案、TC39 案) がなされ、バイナリデータ案として 1 つにまとめられつつあります。バイナリデータ案は、上記ユースケースでの使いやすさと表現力を高めることを目的としています。
サイトの読み込み時間の短縮 ( 特に大規模なサイト ) 。グローバルスコープに影響を与えず、予測可能な読み込み順序で、一貫性のある形でコード単位を読み込む標準化パターンにより、今日の JavaScript が強化されます。ソリューションはランタイムに統合され、他のブラウザーサブシステムとの連携による効率的なページ読み込みを実現します。モジュールおよびモジュールローダーに関する提案は、その有望な出発点と言えそうです。私たちは、重大な変更を加えることなく、“text/javascript” 内のスクリプトでこれらの機能を使用できるようにすることを目指しています。
パフォーマンスと応答性の強化。 引き続き、JavaScript の組み込み型に対する操作用ライブラリを充実させていく必要があります。String および Math の拡張案が示すように、startsWith や contains のような組み込みの文字列検索や、他のクライアントプラットフォームに対応する Math 機能の追加導入は JavaScript の強化につながります。また、文字列内の変数を置き換える format 機能も有用です。ES5 と同様、これらの機能をランタイムに統合することにより、最小限の開発労力で、多くの実稼働 Web サイトのパフォーマンスを目に見えて向上させることができます。

大規模な JavaScript

大規模なアプリケーションを構築する場合、高品質なオーサリング機能やツールの活用が不可欠になります。

そのような場合は、クラスなどの高度な抽象化およびその他の一般的なプログラミングパターンを基盤として、ツール利用のエクスペリエンスを向上させることができます。

数十万行の JavaScript コードから成る Office Web アプリケーションは、主に Script# をベースに記述されており、JavaScript にコンパイルされ、今日の各種ブラウザーで実行できるようになっています。Google Web Toolkit などのツールセットも同様のアプローチを採っています。最近では、Traceur や CoffeeScript などの変換コンパイラライブラリによって、JavaScript への追加構文や、完全な代替構文も、今日のブラウザーでランタイムへの変更なしに処理可能なことが実証されています。

JavaScript には基本的な欠陥があり、これらのシナリオをサポートするには JavaScript の構文およびランタイムからの “決別” が必須であると予告する向きもあります (Dart の例など)。私たちはこうした見解には同意しません。TC39 委員会の参加者として、標準ランタイムを拡張し、大規模な JavaScript 開発のサポートに必要な構文機能を既存の JavaScript 標準の上に構築できると確信しています。

ECMAScript 標準プロセス

過去数年間、TC39 は、ECMAScript 標準に対するさまざまな新機能の追加案を採用してきました。TC39 の現在の取り組みは、次の 2 分野が中心になっています。

JavaScript ランタイムに対する取り組み。 この取り組み (バイナリデータ、private name オブジェクト、グローバリゼーションなど) により、新しい有用な機能がプラットフォームに提供されます。既存の JavaScript スクリプトタグ内部で機能検出可能な形で提供されるため、導入を短期間で円滑に行うことができます。
JavaScript 構文に対する取り組み。 この取り組み (let、分割代入、イテレーター、オブジェクトリテラルなど) により、JavaScript 言語の表現力が強化されますが、新しいスクリプトタグのオプトインなど開発者向けの大規模なバージョン管理が必要になります。

私たちは JavaScript ランタイムの改善を優先しています。Web の機能を根本的に左右する要素であるためです。TC39 を通じて、私たちは上記のような機能が開発者の基本ツールとなるよう働きかけています。

Web の未来に向けて

Web が Web サイト主体から Web アプリケーション主体に移行し、Web 開発者が HTML5 で新しいエクスペリエンスを構築しているなかで、JavaScript もシンプルさ、柔軟性、パフォーマンスを犠牲にすることなくこうした移行を実現する必要があると私たちは理解しています。それを成功させる最善のアプローチ方法は、Web 開発者コミュニティによる広範かつ段階的な導入を促進することです。

コミュニティで提案されるアイデアの多くは、こうした考え方を支持しています。マイクロソフトは ECMA TC39 標準化団体において、JavaScript のコアランタイムの改善に向けたより適切な提案の作成に、引き続き取り組んでいきます。そして、何よりも重要な点として、標準化は、Web プラットフォームで最も必要なものは何かに関する Web 開発者との議論をもとに進める必要があります。

どうぞご意見をお寄せください。皆さんがこの議論に今後も参加してくださることを期待しています。

—Shanku Niyogi、Amanda Silver、John Montgomery、Luke Hoban、Steve Lucco - JavaScript チーム