Google が開発しているという新言語「Dart」を覚えていますでしょうか。来月の GOTO Aarhus 2011 Conference にて発表があるということで数日間は話題に登ったものの、その後は続報もなく忘れ去られているようです。

実はこの Dart に関連して、 2010 年 10 月に書かれた Google の内部文書 (?) が注目されています。その中では、 JavaScript の次期版である Harmony と平行して新たな言語「Dash」を開発することが示唆されており、それが来月発表される Dart の正体ではないかと言われています。また、 Google が新言語の開発を決断した理由や今後のオプション、そして僅かながら関連するプロジェクトについてなども語られており、なかなか興味深い内容です。

そこで、本日はこの文書のハイライトをご紹介したいと思います。いつもながら翻訳は超適当なので、正確な情報を得たい方はぜひ原文も参照してください。もっとも、原文も正しい情報である保証はまったくないですけどね。

新言語 Dash とは

原文と順番は前後しますが、まずは注目の新言語 Dash (Dart) について。文書では、 Dash は以下の 3 点に留意して設計されていると説明しています。

• パフォーマンス -- すべての EcmaScript VM が必ず持つパフォーマンス問題を回避して VM を作成できるように、 Dash はパフォーマンスを意識して設計されている。
• 開発者の利便性 -- Dash は、 Web プラットフォームが趣味の開発者から圧倒的に支持される理由となった JavaScript の性質（動的、簡単に始められる、コンパイルの必要がない）を維持するように設計されている。
• ツールが作りやすい -- リファクタリングやコールサイトの検索といったコード解析機能を必要とする大規模プロジェクトのために、 Dash はそれを容易にするように設計されている。しかしながら、それは必須ではない。小規模な開発者はテキストエディタだけでじゅうぶんであろう。

JavaScript の利点を残しつつ、その欠点を根本的に改善するものであることが伺えます。とくに静的なコード解析を容易にするような性質は、一定以上の規模を持つアプリケーションの開発には非常に有用です。ただし、 Java や C/C++ のような固い言語ではなく、あくまで LL の範疇に入るものみたいですね。変数の型も「optionally-typed」だそうなので、その点では ActionScript のような感じになるのかな。

Dash の実行環境としては、以下の 3 つが挙げられています。

• ブラウザのVM -- 我々が熱望するのは、Dash が最終的に、すべてのブラウザで最適なネイティブ・クライアントサイド言語として JavaScript の代替となることである。
• フロントエンド・サーバー -- Dash は Google スケールのフロントエンドまでカバーするサーバーサイド言語としても使えるように設計されている。これは大規模アプリケーションのクライアントとフロントエンドコードをひとつの言語で統一することを可能にする。
• Dash クロスコンパイラ -- Dash はその大部分をレガシーな JavaScript にコンパイルできるように設計されるので、 Dash を使用するチームはそのリーチを大幅に制限されることはない。 Dash VM を持つプラットフォームではトランスレーションなしにオリジナルの Dash コードを実行でき、パフォーマンス向上の利点を得ることができる。 Harmony を進化させるひとつの方向は、コンパイルされた Dash コードのよりよいターゲットとすることである。

最初の 2 つは現在の JavaScript とおもいっきりかぶりますね。 Google が Dash を JavaScript に代わる Web の主要言語として位置付けているのがわかります。また、文書の他の部分では、変数が型付けされた JavaScript コード（おそらく Closure Compiler のアノテーションを指しているのでしょう）を Dash コードに変換するコンパイラの提供も示唆されています。 Closure Library でアプリケーションを書いておけば、 Dash へスムーズに移行できるかもしれません :)

なぜ Dash を開発するのか

Dash を開発する理由については、文書の冒頭で説明されています。

現在の Web 上で素晴らしいアプリケーションを構築することはたいへん困難である。イノベーションの旋風は Web から徐々に iOS などのクローズド・プラットフォームに移りつつある。 JavaScript は登場以来ずっと Web プラットフォームの一部だったが、 Web はそこから逸脱し始めている。 Web 開発コミュニティーは主にプラットフォームの機能不足を補うために JS を多く利用している。複雑な Web アプリケーション -- Google が専門とする種類の -- はこのプラットフォームと奮闘し、そしてツールによる開発支援が難しく本質的なパフォーマンス問題を抱える言語で開発されている。趣味の開発者による小規模なアプリケーションであったとしても、フレームワークの迷宮と調和のないデザインパターンに導かれる。

主にそのリーチを強みとして、 Web は歴史上ある程度成功した。 iOS のような強力な競合の出現は、 Web プラットフォームがそのリーチだけではなくメリットで競争していかなければいけないことを意味している。現在のような JavaScript は有望な長期的ソリューションとはなり得ないだろう。なにかを変えなくてはいけない。

なんだかよくわからない訳になってしまってますが orz 、 JavaScript による大規模アプリケーション開発の難しさに悩まされ、 iOS のようなプラットフォームの台頭に危機感を持ったのが大きな理由というところでしょうか。 Web のライバルとして iOS を名指ししているのが印象的ですね。

Closure Tools や GWT など、大規模 Web アプリケーションを開発するためのさまざまな取り組みを行なっている Google ですが、さすがにもう限界ということなのでしょう。

JavaScript コミュニティとの関係

前述の問題を解決するために、文書では (1) TC39 （ECMAScript 標準化を行なっている委員会）へのコミットを継続し、 JavaScript を進化させる、 (2) 新しい言語 (Dash) を開発する、という 2 つの戦略を平行して推し進めることが必要であると述べて、その理由を以下のように説明しています。

どちらかの戦略を単独で遂行すると失敗するだろう。 JavaScript を進化させる戦略を単独で実行した場合、 Web は両足を縛られ、オープン性を欠くプラットフォームによる侵食に対抗できない。 Clean break 戦略（JavaScript と決別して Dash を開発する）を単独で実行し、それが失敗した場合、我々のサポートを失った JavaScript の進化は停滞し、我々は依然として基本的な欠陥を抱えたままになる。そして最悪なことに、 Web での Google の指導的立場は致命的なダメージを受ける。

内部文書だけになかなか利己的な表現がならんでいます。当然 JavaScript コミュニティからは反発があるようで、そのあたりは Axel Rauschmayer 氏のブログ にまとめられていました。とくに Android などで見られる Google の Delayed-open アプローチ（開発がほぼ終了してからソースを公開する）に対する懸念が強いようで、 Mozilla の Brendan Eich 氏は以下のように述べています

オープンな革新、そして標準化母体に早期に、頻繁に提案することは素晴らしい。標準化母体に提案せずに単一ベンダーによるプロプライエタリなコードを積み重ねていく（オープンソースかどうかは関係ない）ような Delayed-open 手法はそうではない。

Google には独占的な力はなく、そしてリークされたメモの標準化戦略の欠如から、 Dart は他のブラウザには採用されないだろう。これは分裂である。

早くも暗雲が立ち込めているような… ^^;

ちなみに他のブラウザからの支持が得られなかった場合のオプションも、 FAQ のところで語られています。

しかしながら、他のブラウザが追随しない場合でも、 Dash は依然として成功できる。 Chrome のみをターゲットにする開発者は Dash VM を利用でき、そして他のブラウザもターゲットにする開発者は Dash コンパイラが使える。その場合、広い意味での Web は JavaScript を標準言語とする状態に留まる。これがまさに我々が JavaScript の進化への投資を続けなければならない理由である。

Dash が Google 内部（および Chrome apps などの開発者）でしか使われない言語にとどまったとしても、開発する意味はある、という認識ですね。まあ、 Google の製品はたいてい Google 内部で使うのがひとつの目的だったりするので、 Google らしいといえなくもない。

その他の情報

文書の後半では、他のプロジェクトとの関係などが FAQ 形式で語られています。その中から面白いものをピックアップしてご紹介します。時間がなくなってきたので、引用は原文でご勘弁ください orz

「Brightly」というクラウド IDE を開発中？

「How does this affect our cloud IDE (Brightly)?」という項目があり、以下のように語られています。

Brightly will enable building any web application in V1 using today’s Javascript plus the additions in Harmony. As soon as it is ready, Brightly will support Dash as well. We expect that the more prescriptive development aspects of Brightly that will come on line in the future will be more Dash focused. We expect Brightly itself to be the first application written in Dash.

「Brightly」というクラウド IDE を開発中であり、まず最初に現行の JavaScript ベースの Web アプリケーションをサポートし、さらに続けて Dash もサポートするとのことです。これはなかなか興味深いですね。とりあえずは内部で使用するための開発ツールなのでしょうが、最終的には、ぜひ我々も使えるように公開してほしいところです。

MVC フレームワークを開発中？

「Joy」という MVC フレームワーク (?) に関する記述もあります。 Dash 上で構築されるとのこと。

The Joy templating and MVC systems are higher-level frameworks that will be built on top of Dash.

Joy templating っていうのは Closure Template (Soy template) とは別物なのかなぁ…？

Go 言語との関係

Google 発の言語といえば Go 言語ですが、それと Dash の関係も説明されています。

Go is a very promising systems-programming language in the vein of C++. We fully hope and expect that Go becomes the standard back-end language at Google over the next few years. Dash is focused on client (and eventually Front-end server development). The needs there are different (flexibility vs. stability) and therefore a different programming language is warranted.

Go 言語は C++ に代わるシステムプログラミング向けの言語であり、クライアントサイド（およびフロントエンド・サーバー）向けの Dash とはニーズが異なると。まあ、そりゃそうですね。この理屈でいくと、 GAE の言語としては Go よりも Dash (Dart) が使われるようになるのかなぁ。個人的には Go 言語好きなんだけど。

Chrome への Harmony の実装に関する問題

「How will we get Harmony related changes into Chrome?」という項目にはこんな回答が。

Very carefully ;-). V8 is carefully tuned for speed with the current Javascript standard rather than flexibility--this makes it very difficult to make experimental changes. We are considering pre-processors and a number of other options, but ultimately the precise solution is still an open question.

V8 エンジンが現行の JavaScript のためにカリカリチューンされているので、実験的な変更が難しいとのこと。たしかに Chrome は ES5 / Harmony 対応に関してパッとしませんが、このあたりに理由があるんですかね。

Google 内部での開発の方向性 (?)

「What will Google developers be using?」という項目では、以下のように回答されています。

We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives us the best end user experience. However, for some apps this will not make sense, so we are building a compiler for Dash that targets Javascript (ES3). We intend for existing Google teams using GWT and JSCompiler to eventually migrate to the Dash compiler.

最初の一文はちょっと気になりますね。 Google の開発者に対して、 Chrome に特化したアプリケーションの開発を奨励しているように読めます。通常の Web アプリケーションで実現できない分野に関して Chrome アプリで対応するのはわかりますが、 HTML5 の標準機能で実現可能なことは、ちゃんとクロスブラウザでやってほしいものです。例えば Gmail のオフライン対応なんかも本来は HTML5 の App Cache でやるべきなのに、なぜか Chrome アプリだったりしますよね。そうした事例が今後増えていくとしたら、困ったことです。

そんなことをしていると、「Web での Google の指導的立場」はそれこそ深刻なダメージを受けてしまいますよ :p

個人的な感想と期待

最後に、私の個人的な意見を少し。

私は以前から、クライアントサイド（Web ブラウザ）で使える言語が JavaScript のみ、という状況はおかしいと思っていました。サーバーサイドでは多彩な言語が使えて、プロジェクトのニーズによって適切なものが選べます。それなのに、クライアントサイドでは Web サイトのちょっとしたエフェクトから複雑な Web アプリケーションまで JavaScript というひとつの言語で賄わなければならない。これはちょっと無理があります。 JavaScript が悪いというのではなく、ひとつの言語ですべてのニーズに対応しようとするのがナンセンスなんです。

Dart の話が出てくるまでは、この状況を改善する技術として Native Client (NaCl) に期待していました。 C/C++ によるネイティブコードをブラウザ上で安全に動かせるので、言語処理系をポートすることも可能なはず。 NaCl によってさまざまな言語が Web ブラウザ上で使えるようになれば、ある程度は幸せになれます。

ただ、 NaCl は所詮プラグインなので、 DOM を直接操作できない（JavaScript ブリッジを通して行う）など、やはり不便な点は残ります。それを考えると、ブラウザがネイティブサポートする言語を増やすという Dart のアプローチは理想的です。 JavaScript をリプレースするとかではなく、 JavaScript が苦手とする大規模アプリケーションの分野をフォローするための新言語であれば、それを熱望している開発者は多いのではないでしょうか。

ということで、個人的には Dart にすごく期待しています。現行の Web 開発の限界を打ち破る画期的な技術となる可能性はじゅうぶんにあるでしょう。それだけに、 Google はもっと慎重に物事を進めていただきたい。某 M$ 的な横柄な態度ではなく、 Google 外のコミュニティともきちんと協調する形で進めていくべきでしょう。内部文書で Google 自身が指摘しているとおり、 Google のリーダーとしての資質が問われることになるのかもしれません。