JavaScripterから見たJSX

私は2001年からJavaScriptを専門にして実装をしており、かなり長い間JavaScriptを使い続けてきました。ExGameをはじめとして、異常なほどにJavaScriptを使い倒したプロジェクトを何個か完遂させています。前の会社﹁ブロードテイル﹂がDeNAに買収されたのは、JavaScriptのプロダクトだけでなく、私たちのJavaScriptのスキルを生かしたいという側面も大きくあったと感じています。

そんな私ですが、正直に言うとJSXの開発にはほとんど関わっていません。JSXは基本的に一穂さんが主導し、gfxがフォローし、a_bickyがドッグフードを食べる︵自分たちのプロダクトをまず自分たちで率先して使う︶という形で進んできました。私が強くかかわったのは、主に3月の言語仕様を決めるときの議論程度です。なのでJSXについてそこまで詳しい訳ではないのですが、そばで開発を見てきたいちJavaScriptrの立場として、JSXのメリット・デメリットについてお話をしたいと思います。

JSX: a faster, safer, easier alternative to JavaScript

まず、以前のブロードテイルと現在のDeNAでは、JavaScriptを利用した巨大なプロジェクトというものが何本も走っていました。前述したExGameというのはJavaScrptでFlash Playerを作るというプロジェクトですし、現在のDeNAにはそれ以上の規模のJavaScriptプロジェクトが何個かあります。そうなってくると、JavaScriptスペシャリスト以外の開発要員が必ず必要になってきます。

大規模な開発になると、途端にJavaScriptは弱さを発揮します。例えばthisの付け忘れ、例えばタイプミスなどなど、つまらないところで数時間判明しないバグを生み出したりします。また、多人数開発のためには読みやすいコードを書く必要があるのですが、一般的に抽象化を進めれば進めるほどJavaScriptは意外なほど遅くなります。何も考えずにsetter/getterなどを作ってしまうと、かなりの実行時コストになります。

JSXはその問題を綺麗に解決してくれます。強い型付けによるコンパイル時のコードチェックがあるために、タイプミス等の問題はすぐに発覚します。比較的強いインライン展開等の最適化があるので、実行時のコストを気にせずに抽象化を行うことが出来ます。大人数での開発において、これらの機能は生産性を大きく上げる特徴となるでしょう。

手でインライン展開すればいいじゃないか、と思う人もいるかもしれません。実際、私がJSXに移植したbox2d jsは、まさにクリティカルな部分は手でインライン展開をしていました。その部分はコメントで﹁ここからインライン展開﹂﹁ここまでインライン展開﹂というような形でマークアップし、涙ぐましい努力をしていましたが、それを構造を変えずにそのまま移植したJSX版は、それよりも数%さらに速くなっています。

ただ、ここでの重要な点は﹁速くなった﹂ことではなく﹁決して遅くならない﹂ことです。もし変換に際して何かしらのオーバーヘッドが発生してしまうと、﹁それなら最初からJavaScriptで書いた方が速い﹂ということになってしまいます。私たちの主戦場はスマートフォンのJavaScriptなので、数%であれ遅くなることは、まず許されません。それならばJavaScriptで最初から書け、ということになるのです。

JSXの言語設計の前後で、別の言語︵例えばJavaなど︶から移植する方法はないかと考えました。しかし既存の言語は当然ながらJavaScriptへの移植を前提にしておらず、変換でどうしてもオーバーヘッドがかかってしまうのです。既存の言語を流用出来れば、既存のライブラリや開発環境もそのまま流用できるので非常に大きなメリットになったのですが、この点で断念せざるを得ませんでした。

よってJSXは、企画の段階から﹁絶対に遅くならない﹂ことを念頭に設計されています。今のところ、大規模開発が可能で、かつJavaScriptに変換しても絶対に遅くならない言語はJSXしかないだろうと考えています。そういう意味で、私はJSXの誕生を非常に喜んでいます。

﹁遅くならない﹂だけであればGoogle Closure Compiler︵以下GCC︶があります。これも非常に良いプロダクトで、私は今も必要に応じてよく使っています。ただ、アノテーションベースだと大規模開発には向かない︵アノテーションが必須でない︶のと、ちょっと変なコードを書いてアノテーションを失敗した場合、GCCを通すと動かなくなることがあります。しかし自由奔放なJavaScriptを最適化しようというからには仕方のない話であり、GCCはJavaScriptを自由に使いながら最適化をかけるにはとても良い解です。

そう、JSXのデメリットとして、型安全な書き方を強制されてしまう点があります。その場の思いつきでオブジェクトのプロパティを追加したり、prototypeの拡張によって広く使える新しい機能を導入したり、といったJavaScriptならではの書き方は出来ません。小さなプロジェクトだと、むしろJSXを使うと開発効率は下がるかもしれません。実際HelloWorldに必要な行数はJava並となっています。もちろんJSXはあえてその手法を切り捨てたのですが、手軽に開発を進めるプロジェクトの場合にはデメリットになるでしょう。

これらのメリット、デメリットはプロジェクト次第です。JSXはJavaScriptの何もかもを解決する言語ではありません。ただ明確な目的として、﹁多人数での開発に向いた言語にする﹂、﹁JavaScriptの変換で遅くなることがないようにする﹂ということを掲げており、その点では実に良い解になると思います。

もう一つのデメリットとしては、私のようなJavaScript専門家の才能を発揮する余地が少なくなってしまうことですね。保守性を保ちつつ可能な限りの高速化をするために四苦八苦することが出来るというのが大きな価値だったのですが、JSXによりその優位性は徐々に失われていくのでしょう。自分の持つ価値が失われるのはとても残念ですが、しかし私は個人的なこのデメリットよりも、今後JSXを利用した大規模なWebアプリが多数登場し、それによりインストールレスな世界がより広がるメリットの方がうれしい話だと感じます。

JSXは今後も機能が継続的に拡張されていき、今以上の応用性が生まれてくることでしょう。また言語仕様的にはEclipseのプラグインなどの作成も容易であり、IDEもすぐに充実すると思います。私は今後も必要に応じてJSXを開発に利用し、その環境の改善にも自分なりに協力していきたいと思っています。