2010年のJavaScriptと題しまして、JavaScript周辺の「これまで」と「これから」についてまとめてみたいと思います。

2009年までのJavaScript

JavaScriptは各ブラウザベンダなどが個別に実装するという特殊性から、ブラウザ（実装）ごとの非互換性の問題に悩まされ続けてきた言語です。まず、そのJavaScriptの歴史を簡単に振り返ってみます。

ECMA-262 3rd editionとスピードコンテスト

JavaScriptはNetscape社によってLiveScriptという名前で誕生し、その後ECMAScriptとして標準化が進みました。1999年12月にECMA-262 3rd editionが策定されてから、Internet ExplorerのJScript、MozillaのSpiderMonkey（TraceMonkey⁠）⁠、SafariのJavaScriptCore、OperaのLinear A/Linear B/Futhark、そしてGoogle ChromeのV8と、いくつものJavaScriptエンジンが誕生し、現在も改良が加えられ続けています。

JavaScriptの言語としての仕様は10年前から変わっていないにも関わらず、各エンジンが更新を続けているのは、多く分けて2つの理由があります。1つはDOMサポート、もう1つは高速化です。特には2008年の6月頃から各エンジンの競争が白熱化しました。JavaScriptCoreとSpiderMonkeyにはJITコンパイラが搭載され、従来のインタプリタ方式に比べて大幅な高速化を実現しました。また2008年9月にGoogle Chromeが登場し、スピードコンテストを盛り上げました。

この流れには遅れてしまいましたが、Operaも2009年12月に10.50のプレアルファ版を公開し、新しいJavaScriptエンジンのCarakanを搭載しました。このCarakanはSunSpider、Peacekeeper、V8 Benchmark Suite、Dromaeoなどの各種ベンチマークで軒並みトップかそれに近いスコアを叩きだしています。また、Internet Explorerも「Professional Developer Conference（PDC⁠）⁠ 2009」において、開発初期段階のInternet Explorer 9のJavaScriptエンジンが大幅に高速化していることを発表しています。

HTML5周辺技術のサポート

HTML5周辺技術として、以下の仕様がJavaScriptと連携する部分として策定が進められています（それぞれの進捗はJavascript Interfaces Current Status - W3Cを参照してください⁠）⁠。

• Web Storage
• Web Workers
• The Web Sockets API
• Web SQL Database
• Selectors API Level 1
• Server-Sent Events
• XMLHttpRequest(Level 2)
• File API
• WebSimpleDB API
• DataCache API
• API for Media Resource 1.0
• Geolocation API Specification
• Cross-Origin Resource Sharing
• Web Forms 2.0

これらの仕様に対して、2009年年末時点での各ブラウザのサポート状況は下記の表の通りです。

この表で下に行くほど仕様・実装が進んでいない項目になっています。最後のWeb SQL DatabaseはSafariを筆頭に実装こそ進んでいますが、標準化に当たって各ベンダの意見がまとまらず、Indexed Database APIにその機能・役割が託されたこともあり、このまま策定がストップする見込みが強くなっています。

ECMAScriptの改訂

2009年のJavaScriptに関する最大のニュースといえば、なんといってもECMAScript 5th editionがEcma Internationalで承認されたことです。このECMAScript 5th editionに至るまでは色々と紆余曲折がありました。まずはその流れをざっくりと紹介します。

元々、Mozillaを中心にJavaScriptの大幅なバージョンアップに向けた準備がかなり早くから進められていました。その成果の一つとしてAdobeによりActionScript 3というECMAScript実装が生まれ、またそのスクリプトエンジンがTamarinという名前でMozillaに寄付されました。これにより、ECMAScript 4の標準化が大きく前進するはずでした。しかし、従来のECMAScript3から大きく仕様を変えることにほかのベンダから同意を得ることができず、ECMAScript 4の標準化はストップしてしまいました。代わりに、ECMAScript3からのマイナーチェンジとしてECMAScript 3.1の標準化がスタートしました（ECMAScript Harmonyと呼ばれるプロジェクト⁠）⁠。そして、このECMAScript 3.1が今回ECMAScript 5と名前を変えてリリースされることになりました。

つまり、3rd editionから5th editionへバージョンは2つ上がっていますが、実質的にはマイナーアップデートとなったため言語仕様としては大きな変化はありません。5th editionの主な特徴は次の通りです。

• JSONサポート（JSON.parse、JSON.stringifyなど）
  既にIE8、Firefox 3.5、Safari 4.0.2、Google Chrome 2、Opera 10.50（pre-alpha）でサポートされています。

• 配列操作メソッドの追加（forEach、filter、mapなど）
  Firefox 1.5以降（reduce/reduceRightはFirefox3以降⁠）⁠、Safari 3.1（reduce/reduceRightはSafari4以降⁠）⁠、Chrome 1（reduce/reduceRightはChrome3以降⁠）⁠、Opera 9.50以降（reduce/reduceRightはOpera10.50 pre-alphaから）

• getter、setterのサポート
  IE8はDOM要素のみサポート、Firefox 1.0、Safari 3.1、Chrome 1、Opera 9.50以降で利用可能

• オブジェクトに対して、キーの一覧を取得したり、列挙されないプロパティを作ったりといった操作が可能になる
  WebKitやChromiumではObject.keysやObject.createなどが実装されています。

• Strictモード（変数宣言が必須になる、withの使用制限などの厳密なモードに切り替えることが可能になる）

上記の通り、既に実装が進んでいる仕様が多くなっています。StrictモードはJavaScriptでミスになりがちな記述を発見できる効果的な仕様です。こちらは後述します。

2010年からのJavaScript

さて、いよいよ本題の2010年からのJavaScriptですが、結局のところ「これから」は「これまで」の続きです。当然、HTML5周辺技術のサポートの充実、ECMAScript 5th editionの実装が2010年のメインとなることは間違いありません。

その中でも注目するべきものとしてStrictモードがあげられます。Strictモードは、script内に "use strict"; という一文を書くことで有効になります。この一文はある関数の中に書けばその関数内だけで、script要素の直下に書いた場合はそのscript内だけで有効になります。

Strictモードでは、変数宣言が強制される、8進数のリテラルやwithが使えない、thisが暗黙的にグローバルオブジェクトになることがないといった特徴があります。

thisについて少し詳しく解説します。JavaScriptでは関数内のthisがその関数の呼び出され方によって決まります。そのルールは3つあります。

• あるオブジェクトのメソッドとして呼び出された場合、thisはそのオブジェクト自身になります。
• 関数をnewして呼び出された場合は、その関数から作られるオブジェクト（インスタンス）がthisになります。
• 関数がcall、apply、bind（ECMAScript 5以降）で呼び出された場合は、引数で指定されたオブジェクトがthisになります。

この3つに当てはまらない場合、従来はthisは暗黙的にグローバルオブジェクト（windowオブジェクト）になりましたが、Strictモードではundefinedになります。

"use strict";
function Point(x, y){
   this.x = x;
   this.y = y;
}
var point1 = new Point(1, 2);//(1)
var point2 = Point(2, 1);//(2)

従来のJavaScriptでは、関数宣言で定義された関数Pointを呼び出すときにnewをつけなかった場合 (2)、thisはグローバルオブジェクト（window）になるため、window.xに2、window.yに1を代入してしまうことになります。このように暗黙的にthisがグローバルオブジェクトになる現象はバグの原因の特定を難しくする要因としてよく挙げられる問題の1つでした。

Strictモードでは、上記の (2) でのthisはundefinedになるため、明らかなエラーとなって問題の箇所を容易に特定できるようになります。今後は、"use strict"; を書くのが定番になるかもしれません（そうするべきだ、と言いたいところですが "use strict"; が実装されていない現状ではなんとも言えません⁠）⁠。

JavaScriptとブラウザ拡張

HTML5やECMAScript 5と新しい仕様の実装は着々と進んでいますが、古いバージョンのブラウザも依然として使われているため、そういった新機能は使う機会がないと思われるかもしれません。

そこで注目するべきなのがブラウザ拡張です。特に、Google Chrome 4から搭載される拡張機能はChromeのHTML5関連の実装をフルに使ったアプリケーションを作成することができます。FirefoxもFirefox 4から搭載される予定のJetpackではより手軽に拡張を作ることができるようになります。OperaもOpera UniteやOpera WidgetsなどをHTMLベースで作成することができます。

ブラウザ拡張は一般ユーザー向けでない、マニアックなもので市場規模が小さいと思われるかもしれません。しかし、そもそもインターネット自体にまだまだリーチできていないユーザー層が存在しています（パソコンは持っているけど、めったに起動しないといったライトユーザーにも満たないユーザーは意外なほど多く存在しています⁠）⁠。そういったユーザーにリーチしたり、大きなイノベーションを起こす可能性は、パソコンで動くアプリ・サービスよりも、iPhone／AndroidなどのスマートフォンやChrome OSなどの新しいデバイスのほうが高くなります。

より自然に、より多くのユーザーがスマートフォンやChrome OSなどで拡張を使うケースが、思いのほかすぐに実現するかもしれません。

もう1つのJavaScript：サーバーサイドJavaScript

さて、最後にサーバーサイドJavaScriptを取り上げておきたいと思います。サーバーサイドJavaScriptはまだまだ馴染みのないジャンルだと思いますが、着々とその実装は増え、環境が整いつつあります。

なぜサーバーでもJavaScript使うのか、1つにはJavaScriptがシンプルで柔軟な言語であること、もう1つにHTML5の流れでブラウザ側に処理させる割合が増えているため、サーバー側とブラウザ側で共通のコードを使うことが大きなメリットになります（具体的には入力値のバリデーションを行うコードなど⁠）⁠。そしてなにより、HTML／CSSとの親和性の高さはウェブアプリを作る上で非常に大きなアドバンテージとなります。

サーバーサイドのJavaScriptのエンジン

サーバーサイドJavaScriptのエンジンとしてよく使用されるのは、Rhino（Javaで実装されたオープンソースのJavaScriptエンジン）とSpiderMonkey（Firefoxにも搭載されている、Cで実装されたオープンソースのJavaScriptエンジン）の2つです。最近ではV8を使用するサーバーも登場しています。どのエンジンも近年の大幅な高速化で、サーバーとして十分に機能するレベルになってきています。

サーバーサイドJavaScriptはCommonJSとして、CommonJS グループを中心に標準化が進められています。すでにサーバーサイドJavaScript用のライブラリはいくつか種類があり、Narwhalやnode.jsなどがメジャーになりつつあります。特にNarwhalベースのWebフレームワークJackはRubyのRack、PythonのWSGIに基づいたスマートなAPIを提供しています。

また、開発環境込みで提供されているAptana JaxerはサーバサイドJavaScriptを始めるきっかけとして最適な素材となっています（参考：Aptana JaxerでサーバサイドJavaScriptを始めてみよう！⁠）⁠。

まとめ

最近のJavaScript関連のトレンドをざっくり眺めてみましたがいかがでしたでしょうか？なるべく広く触れてみるようにしましたが、iPhoneやAndroidなどのモバイル向けJavaScriptなども今度より面白くなりそうなジャンルです。また、HTML5のcanvasなどもあえて省略しています。

この記事がJavaScriptの面白さを（再）発見するきっかけとなれば幸いです。ありがとうございました。