あけましておめでとうございます。昨年に引き続き、今年もJavaScriptの近い未来についてちょっとだけお話させて頂きます。

最初に昨年の予想を見返しておきましょう。昨年は次の3つを2010年の鍵として取り上げました。

• ウェブ標準
• ブラウザ拡張
• サーバーサイドJavaScript

この3つを軸に2010年を振り返ってみます。

2010年のJavaScript界隈でのニュース

ウェブ標準

2010年最初のビッグニュースはなんといってもIE 9のPlatform Preview版の登場でした。これまでの独自実装路線から一転して（正確にはIE 8の時点でJSONやWeb Storageのサポートなど、その徴候はあったのですが⁠）⁠、HTML5などのウェブ標準のサポートを進めることを表明しました。そして実際に8週おきにPlatform Preview版をアップデートして、ECMAScript5・SVG・Canvas・CSS3などの実装とそのデモを公開していきました。

それまでは、Canvasなどの新しい仕様については実装の足並みが揃わなくては部分的にしか使うことができないので、IEがサポートしないのでは片手落ちという見方が少なからずありました。そのIEがウェブ標準への準拠を積極的に行うことがはっきりしたため、各ベンダーの足並みが揃うことへの期待感が一気に高まりました。つまり、2010年はまさにウェブ標準において重要なターニングポイントとなった一年でした。

IE以外にも、Google Chrome 4～8、Safari 5、Opera 11などのバージョンがリリースされ、それぞれHTML5関連のAPIの対応が進んでいます。FirefoxはFirefox 4のリリースが遅れており、HTML5関連では遅れを取っている印象があるかもしれませんが、Firefox 4はHTML5のサポートだけでなく、ECMAScript5のサポートも進んでいます。特に、昨年取り上げたstrict modeを含めて、ECMAScript5のAPIをフルサポートしているのは（2010年末時点で）Firefox 4だけなので、Firefox 4のリリースには注目です（strict mode自体はWebKitのnightly版もサポートしています⁠）⁠。

ブラウザ拡張

次のニュースは6月にSafari 5がリリースされ、Chromeの拡張によく似た機能拡張という仕組みが導入されたことです。さらに、12月にリリースされたばかりのOpera 11にも似たような仕組みの拡張機能が導入され、ウェブ標準技術を使ってブラウザを拡張する環境が一気に広まった一年となりました。

また、Googleはウェブ標準ベースで作成したアプリケーションを配布・販売できるChrome Web Storeを開始（日本では2011年前半にスタート予定）しました（AppleもMac App Storeを2011年1月6日から開始する予定ですが、こちらはウェブ標準ベースというわけではありません⁠）⁠。つい一年前まではまだまだ将来のことという認識が強かったHTML5・CSS3・ECMAScript5などの新しい仕様が実際に使われる局面に差し迫っています。利用ケースが増えればそれだけフィードバックも豊富になり、仕様が洗練され、安定していくことが期待できます。

サーバーサイドJavaScript

そして、もう一つのニュースはNode.jsブームの到来です。Node.jsはサーバーサイドJavaScriptのフレームワーク群で、シングルスレッドでノンブロッキングなAPIで、JavaScriptの長所を最大限に生かしたフレームワークです。折角なので、Node.jsのどこが注目を集めているのか簡単に説明しましょう。

と、まずは既存のウェブサーバーの問題点を整理しておきます。多くのウェブサーバー（具体的にはApache HTTP Server）はマルチスレッドであり、複数のアクセスを処理するためにスレッドをたくさん作って対処します。サーバーは、ひとつのスレッドで一度に複数のリクエストを処理できないのです。スレッドを新たに作るのは重い処理なので、あらかじめ同時アクセス数を予想してスレッドを起動しておくのが（特にアクセスの多いサイトでは）一般的です。

また、アクセスの多いサイトでは、ウェブサーバーの内側を、アプリケーションサーバーや（memcachedなどの）キャッシュサーバー、データベースサーバーなど、それぞれに役割を分担させます。この分担の調整が難しく、アプリケーションサーバーは高速だけど、データベースが混雑して全体のレスポンスが遅くなるといったこともよくあることです。

実際のサービス運用では、アクセス数が予想外に増減したり、データベースに予想外の負荷がかかるといったことは珍しくありません。しかも、サーバーは簡単に増やしたり減らしたりできるものではないので、調整は困難です。そのため、柔軟にサーバーリソースを調整できる仮想化技術やクラウド環境に注目が集まっていることはご存知のとおりかと思います。

それに対し、Node.jsはシングルスレッドで動作するので当然スレッドを増やす必要がありません。しかしそうすると、1台のサーバー（アプリケーション）では一人ずつしか対応できないように思えます。実際、Node.jsは一度にひとつのタスクしか行いません。しかし、実際に複数人のリクエストを並列で処理することができます。重要なのは、リクエストとタスクの違いです。ここで言うタスクとはリクエストを細分化したもので、例えばリクエストの解析や、キャッシュサーバーやデータベースサーバーへの問い合わせ、レスポンスの作成といった個々の処理を指します（もしくはイベントといったほうが適切です⁠）⁠。Node.jsはリクエスト（コネクション）という単位に縛られることなく、細分化したタスクを順番に処理していきます。より具体的に言えば、一人目がデータベースに問い合わせている間に二人目のリクエストの処理を行い、データベースから結果が返ってきたら一人目の処理へ戻り、といった具合です。データベースやファイルI/Oに問い合わせている間に何もすることがない、といったことが起こりません。

Node.jsがなぜ注目を集めているのか、ポイントはこの効率の良さにあります。もちろんNode.jsの方式にも色々と問題があり、特にNode.js内のどこかで例外的に処理が重くなってしまったときの影響範囲が大きい（多くの場合、全体が落ちてしまう）といった問題を抱えています。Node.jsはまだ2年とたたない新しいプロジェクトなので、今後の改良が期待されています。

もうひとつ、Node.jsと直接は関係しないのですが、昨年注目を集めたBigPipeというテクニックがあります。BigPipeはFacebookのパフォーマンスを改善するための試行錯誤の中から生まれ、Facebookで実際に使われています。FacebookのようなSNSは、ユーザーごとに異なるレスポンスを返さなければいけないため、パフォーマンスが問題になります。そこで効率的なキャッシュなど、色々と工夫してみるわけですが、当然そのユーザー固有のデータなどキャッシュできないもの（どうしても取得に時間がかかるもの）があります。そこがボトルネックになって結局のところレスポンス全体が遅くなってしまうということが起こっていました。そこで、結果を取得できたものからレスポンスして表示してしまおうというのがBigPipeの発想です。

当然このBigPipeは非常にトリッキーな仕組みになっていて、まずレスポンスとして空のdiv要素を返しておいて、後からそのdivの中に用意できたコンテンツを差し込んでいくという実装になっています。詳しい実装方法はBigPipe: Pipelining web pages for high performanceで解説されているので、興味があれば是非チェックしてみてください。

Node.jsとBigPipeは技術的にはまったく別物ですが、「⁠待機動作を減らす」ことに注目している点でよく似ています。Node.jsはアプリケーションサーバーの待機動作を減らし、BigPipeはユーザー（ブラウザ）の待機動作を減らす仕組みになっているわけです。

2011年の予想

前置きがだいぶ長くなってしまいましたが、2011年のJavaScript界隈がどうなっていくのか、少しだけ予想してみましょう。

まず、なんといってもウェブ標準、HTML5関連は引き続きは注目すべき重要な要素です。先ほどChrome Web Storeのようにウェブ標準ベースなアプリケーションの普及が始まっていると書きましたが、実際のところChrome Web Storeで販売されているゲームの多くにはFlashが用いられています。なぜFlashなのかは単純な話で、元々Flashで開発していたゲームをChrome Web Storeにも展開しているケースが多いためと考えられます。ゲームに限らず、HTML5関連の技術が実際に活用されているケースはまだまだ珍しいのが実情です。

では、JavaScriptベースのアプリケーションが増えていくためのキーとはなんでしょうか？　その答えは開発環境とテスト環境ではないかと考えています。

JavaScriptの開発環境

JavaScriptはエディタとブラウザという標準的な環境で開発ができるというのがメリットの1つですが、同時に開発環境がブラウザという環境に縛られているというのがデメリットでもあります。FlashやEclipseのような統合開発環境が必要になることもあるでしょうし、デバッグを助けるツールが必要とされています。

もっとも、デバッグのためのツールはFirebugを草分けに、Safari（WebKit）のWebInspector、ChromeのDeveloper Tools（WebInspectorと同じ物です⁠）⁠、OperaのDragonfly、IEの開発者ツールと、各ブラウザごとに揃いつつあります。また、スマートフォンでのデバッグ環境についてもデバッグ用のアプリや、WebInspectorやDragonflyでのリモートデバッグなどの環境が整いつつあります。

また、そもそもJavaScriptを書かずに開発しようというアプローチもあります。具体的にはGoogle Web Toolkit（通称GWT、グウィットと発音します）やCoffeeScriptなどがあります。GWTはJavaScriptをJavaベースで開発できるようにするフレームワークで、大規模開発での利用を想定しています。対してCoffeeScriptはPythonの影響を強く受けており、JavaScriptをよりモダンなLL言語らしい文法で開発できるようにするフレームワークです。特にGWTのような大規模開発を助けるフレームワークは今後重要性を増して行くと思われます。

JavaScriptのテスト環境

もう一つ、開発環境と並んで重要なのがテスト環境です。JavaScriptはブラウザ上で実行されるという都合から、テストが軽視されがちな傾向がありました。最近ではSeleniumなどを使うことで、ブラウザ上でテストを走らせて結果が出力されるといった仕組みは珍しくはありませんが、ブラウザを起動するテストは日常的に行うにはリソース（時間的にも、CPU／メモリ的にも）を使い過ぎるのでなかなか継続的に使用するのは難しいのが現状です。いわゆるCI（継続的インテグレーション）に適していないところがあります。

そこで注目されているのがEnv.jsやHtmlUnitのようなブラウザ無しでDOMを扱えるライブラリです。ちなみにブラウザなしで実行するテストをHeadless JavaScript Testingなどと呼びます。Env.jsを使ったBlue RidgeやHarmony、HtmlUnitを使うCulerityなどがその一例です。

しかし、エミュレーションはあくまでエミュレーションでしかなく、実際にブラウザで動かしたときは予想外のバグが発生しがちです。もちろん、想定可能な範囲でのバグを回避するためにエミュレーション環境でのテストを行うことは十分に有意義ですが、それだけでは足りない点があることも事実です。

そこで有力なのがJsTestDriverです。JsTestDriverではテスト用サーバーにブラウザを起動させておき、クライアントのコマンドラインからブラウザでのテストを実行させてその結果を見ることができます。テスト環境を用意できるなら、JsTestDriverを継続的インテグレーションに組み込むことも可能でしょう。

こういったテスト環境の進化は目を見張るものがあり、今後HTML5関連のAPIを使ったアプリケーション開発が活発になればそれに比例して需要が上がっていくので、要注目のトピックです。

まとめ

最近のJavaScript界隈のトレンドから環境をキーに注目のトピックを選んでみましたが、いかがでしたでしょうか？　まだまだ書ききれなかったトピックは色々とあり、JavaScriptの（非同期）読み込み（LABjsやControlJS、RequireJSなど）について、Canvas／WebGLのライブラリ（Processing.jsやEaselJS、three.js）について、WebSocketについて、ECMAScript harmony／strawmanについて、などなどホットな話題はたくさんあります。それらについても機会があれば解説してみたいと思います。

この記事をきっかけに何かしら興味を持って頂ければ幸いです。ありがとうございました。