[筆者: Péter Halácsy]
編集者注記: Péter HalácsyはPreziの協同ファウンダでCTOだ。Twitterで彼をフォローするには、@halacsyで。
スタートアップはJavaScriptが好きだ。あなたが駆け出しの若造なら、ダイナミックであることが必要だ*。柔軟性も必要だ。とりあえず動くプロトタイプを素早く作れることも必要だし、コードをコンパイルせずにその場で書き換えられる能力も必要だ。JavaScriptはかつて、ブラウザ戦国時代のスタートアップだった。やがてJavaやFlashを圧倒してしまったが、それはスタートアップが市場をディスラプトして既製勢力を追ん出したのと同じ理由からだ。すなわち、アジリティ（敏速性）と柔軟性。〔*: ここでのdynamicとは、コードを書いたらそれが即動くという言語…インタープリタ言語やJIT言語…の使用の意。〕
今日、JavaScriptはもはやスタートアップではなく、またそれを使っているのはもはやスタートアップだけではない。あらゆるサイズの企業が、Webアプリケーションを作る腕前の上手下手を問わず、どこでも/誰もがJavaScriptでアプリを作っている。かつてはC/C++やJavaのような言語に殺到した需要が、今ではJavaScriptに集まり、そして需要のこのようなシフトは言語の限界を露呈している: パフォーマンスとメンテナンス性だ。
最新世代のJavaScriptエンジンはパフォーマンスがすごく向上しているが、でもまだ十分ではない。YouTubeやHuluのようなサイト、それにFacebookやEAのゲームプラットホームを見てみよう。高いパフォーマンスを要求されるマルチメディアのアプリケーションでは、いまだにFlashが使われている。Steve Jobsのご神託がFlashの命運を告げても、JavaScriptのパフォーマンスが劣るかぎりは、使い続けざるをえない。〔PreziはFlashベース。〕
あなたのコードベースが数十万行のオーダーに達し、しかもそれがすべて、JavaScriptのようなダイナミック言語で書かれていたら、開発のペースは牛歩する。コードベースのどこかを書きかえたとき、それが別のところにバグを導入していないか、それは実際にアプリケーションを動かしてみないと分からない。事前の試験には限界がある。ありとあらゆる、予期せぬ事態が起こりえる。バグが累積し、納期は延びる。
誰かがこれらの限界や制約を解決して、Webアプリケーションのこれからのイノベーションを導く必要がある。誰が、どうやって、それをやるのか？
JavaScriptは自分が作った鉄の三角形に囚われている。
PreziとLogMeInとUstreamが、JavaScriptをどうやってスケールするかをテーマとするカンファレンスMLOC.jsを開催した。GoogleやFacebookやMozillaやGrouponなどで毎日のように、問題解決に苦闘している連中が三日間、ブダペストの会場に集まり、JavaScriptの限界/制約対策について話し合った。彼らの努力で、JavaScriptは未来の言語として生き残るだけでなく、Webアプリケーションの書き方も今とは違ったものになるだろう。
今のぼくの見方はこうだ: JavaScriptは自分が作った鉄の三角形に囚われている。ぼくらはJavaScriptの柔軟性と自由に慣れてしまって、それを捨てたくない。しかし同時に、それは爆速であったほしい。JavaScriptは、コードが何百万行にもなると、その柔軟性ゆえにメンテナンスが困難になる。柔軟性とパフォーマンスとメンテナンス性、この三つは互いに入り組んでいる。一つを進歩させたら、他の二つのどちらか、あるいは両方が苦しむ。
たぶん特効薬は一つではなく、複数の組み合わせだろう。JavaScriptはダイナミック言語として、Webのための優れた糊だ。そのことは、変わるべきでない。
コード以前に、ビジネスロジックが正しくないとだめだ。またDartやTypeScriptなどの静的分析ツールは、アプリケーションのいちばん難しい部分が…今後のアップデートにもめげず…正しく動くために欠かせない。静的分析ツールは、もっと進化してもいい、とぼくは感じている。ただしその技術を幅広く、ブラウザがネイティブでサポートするのは、まだまだ先の話だろう。
ブラウザが新しい言語をネイティブでサポートすることは、必ずしも必要ではない。MozillaのAlon Zakaiが紹介したASM.jsはJavaScriptのサブセットで、現代的なブラウザの上で何も変更せずにものすごく高速に動く。スピードが重要なら、ASM.jsで書こう。Cで書いてコンパイラがASM.jsを作りだす方式でもよい。このテクニックは、パフォーマンス以外のほかの方面にも応用できそうだ。デベロッパたちはすでにそれをやっているし、彼らの努力はatl.jsにまとめて載っている。
さて、メンテナンス性の良いコードを書く最良の方法は、なるべく少なく書くことだ。bacon.jsのようなライブラリやElm言語は、複雑なデータ依存性を簡潔に表現し、デベロッパがデータの形をライブラリに合わせる努力をなくす。その結果、コードの量が少なくなり、メンテナンス性の良い高品質なアプリケーションになる。
JavaScriptは、消えてなくなりはしないが、今、変身中だ。デベロッパたちはこの言語の変種や、表現力の豊かなライブラリを作って、特定のユースケースをより扱いやすくしている。パフォーマンスへの要求も含めて。ツールと静的分析も、進歩している。これらのトレンドが全部合わさって、Webアプリケーションの書き方を変えつつある。MLOC.jsが終わったら、いよいよ本格的に始動する。
JavaScriptを毎日のように書いている大企業のみなさまもぜひ、この言語の柔軟性とパフォーマンスとスケーラビリティを大きく増すために、貢献していただきたいと思う。
[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）
