InfoQは先日、電子メールによるバーチャルパネルで、RIAおよびAjax技術の現在と将来の状況についてディスカッションを行いました。このパネルは、多数の貴重なコミュニティ貢献者を特集しています。
- Dion Almaer氏 - Mozilla Corporationの開発者ツールのディレクター
Jnan Dash氏 - Curl Inc.の最高戦略責任者
Didier Girard氏 - SFEIRのCTO、OnGWT.comの著者
Peter Pilgrim氏 - Java Web Users Groupの設立者
Tim Sneath氏 - Microsoft Corp.のクライアントプラットフォームエバンジェリズムのディレクター
Ryan Stewart氏 - Adobeのリッチインターネットアプリケーション（RIA）エバンジェリスト
下記では、質問の内容と各参加者の回答を掲載しています。
1. RIA技術の登場にもかかわらず、Webは「アプリケーション」ではなく「ページ」が大部分を占めています。しかしこの1年、ビデオ、インタラクティブ探 索などの「ミニアプリケーション」を呼び物とするWebサイトへの急速な移り変わりを目にしてきました。この変化を考えると、RIAはついに「成功」に到 達したのでしょうか。
Almaer氏: - Webページの場所はこれからも存在するでしょうが、私も同感でWebアプリケーションの時代になると思います。もちろん、Webアプリケーションは常に存在していましたが、我々は時代の変化を経験してきました。
- 技術は応答性の良いWebアプリケーションの実現にはあまりに不十分でした。
- Ajaxはハックや標準と共に少しずつ進行し、ようやく開発者に、適正なアプリケーションを構築するのに辛うじて足りるだけのツールを提供しました。
- 現在。Ajaxは最初の飛行機のようなものでした。少しずつ進行し、いくらか機能していましたが、理想からは程遠いものでした。偉業の実現を目にして驚きましたが、今やジェット機の時代です。実際に求めるのはクリーンで有用な、リッチなソフトウェアです。
Girard氏: - インターネットは膨大なページの集合体です。長年このような状態が続いています。しかし、この2年間に私は企業の開発者の大きな変化を目にしてきました。 現在、新しいアプリケーションの多くは、RIAが中心のSingle Page Application（単一ページアプリケーション）です。
Dash氏: - コンシューマスペースにははるかに多くのRIAがあると思います。静的なリフレッシュ可能ページ（つまり潜在）から動的な対話型アプリケーションへの移行 の必要性が強いからです。エンタープライズRIAについては、対話型のステートフルなトランザクションアプリケーションを提供する他に選択の余地がありま せん。それがクライアント/サーバーモデルで使用されているものだからです。しかし、エンタープライズRIAはまだ米国を離陸していません。日本では Curl RIAプラットフォームの使用をはるかに多く目にします。
Sneath氏: - 「RIA」という用語の業界標準の定義と見なされるので、それは答えにくい質問です。強力なインターネットアプリケーションフレームワークはずっと前から 存在しています。たとえば、我々がASPを発表してから12年近くになります。ページ間の状態、リッチなコントロール、および比較的シームレスなクライア ント/サーバー開発をサポートするために基本的なHTML上に抽象化レイヤを提供しました。AJAX自体は来月で10年目です。IE5の出荷時がまさに最 初の実装であり、その後はある種の標準として採用されるようになりました。
ここ2、3年で、SilverlightやFlexのようなフレームワークを通じて利用可能なグラフィカルなリッチさには大きな進展がありました。それと共に、より強力なプログラミングツールとコンストラクトが、HTMLやJavaScript単 独では進みにくい場所へと導いてくれます。ついに、設計者と開発者の両者のためにインターネット配信やリッチなツールでメディア、コントロール、グラ フィックス、およびコンパイル済みコードを組み合わせることができる状態にたどり着きました。こうした技術はすべてまだどうなるか分かりませんが、広く採 用されるのに十分に市場が成熟していることは確かです。
Pilgrim氏: - 私は、JavaFX RIAがここ1年でついにデスクトップに到達したと思っています。私はデスクトップという言葉に限定します。我々には携帯電話および携帯機器向けの JavaFX Mobileの最初のリリースしかありません。概念実証となるいくつかのWebサイトがありました。たとえば、Adobeには少なくとも1年間、Flex アプリケーションのダッシュボードがありました。SilverLightは、 NBCのオリンピック放送のリッチアプリケーションとしてMicrosoftによって提供されました。これは、オバマ大統領の就任式にも採用されたと思い ます。JavaFXは、他に適当な言葉がないのでこう言いますが、RIAのスターをまだ生み出してしていません。私が知っている最大のRIAは、 Adobe AIRアプリケーションであるTweetDeckです。私は現在、毎日TweetDeckを使用していますが、そのユーザーインターフェイスには、誰かがそのJavaFXバージョンを構築するのを妨げるようなものは何も見つかりません。
Stewart氏: - RIAが「成功」に到達したかどうかはまだ分かりません。カテゴリを拡大して、ウィジェットや、ビデオ、よりリッチなデスクトップアプリケーション、リッ チなブラウザアプリケーションといったものを含むようになったため、RIAの方向にかなりの勢いがあることは明確ですが、まだそのエクスペリエンスの価値 を知らない企業が多く存在していると思います。しかし、設計側のツールが設計者の想像に追いつき始めているため、我々は興味深い場所にいると思います。そ うなると、設計者と開発者が開発側で何も犠牲にすることなく見た目の素晴らしいRIAに協力して取り組むことができるため、RIAははるかに容易に至る所 で本当に定着するようになるでしょう。
2. RIA技術が取り入れられるようになって、移植性が重視されています。しかし、ユーザーの要求は、ファイルシステム、ドック/タスクバー、カレンダリン グ、およびその他のOSレベルのアイテムとのネイティブな統合を推進しています。RIAプラットフォームは今後数年でそのような統合により重点を置くよう になると思いますか、それとも代わりに相互運用性に向けて努力し続けると思いますか?
Stewart氏: - それは非常に面白いことになるでしょう。ブラウザに関してまだ多大なエネルギーと興奮があります。Webの多くの部分で、人々は基本的にデスクトップを死 んだも同然と見なしていると思います。しかし、ファイルシステムにアクセスするようなことを行い、基盤のオペレーティングシステムに関して我々がすでに 知っているものや持っているものを活用するエクスペリエンスを与える（通知など）ことができるというのは、とても価値のあることです。そして、それはより 重要性を増していくだけだと思います。ブラウザとデスクトップ間のギャップを埋めるものを我々は目にし始めるでしょうが、セキュリティが大きな懸念事項に なるでしょう。当面、私は、優れたWeb開発言語を使用していくつかのデスクトップ機能を利用させることができるAIRやAppceleratorのよう な技術のアプローチを好みます。
Sneath氏: - ユーザーが得られる最良のアプリケーションエクスペリエンスを望むことは、必然であると思います。私の母はWebとWindowsアプリケーションとの区 別を理解しないで、ローカルまたはインターネットベースのリソースを利用する必要があるか否かに関係なく、ただ仕事を終わらせたいと望みます。少なくとも 今は、ここで行うべき選択があります。適している唯一のものは「ネイティブ」なローカルアプリケーションであるというアプリケーションシナリオはいつも存 在します。同様に、移植可能な方法で提供できる多くのシナリオがあります。両方を同時に提供することは難しく、今まで試みたあらゆるプラットフォームは、 ソリューションがネイティブなアプリケーションのようでなく、残りのシステムと十分に統合することもない、非標準の、最小公分母のアプローチを押し付ける 傾向にありました。
Microsoftクライアントプラットフォームスタックの強みの1つは、両方のニーズをターゲットとしたコンパチブルなソリューションがあるとい うことです。Silverlightでは、複数のプラットフォームにわたって優れたソリューションを提供するよう最適化されている軽量なランタイムがあり ます。また、WPFもあります。WPFは、基盤のオペレーティングシステムにフルアクセスできてネイティブなハードウェアの機能を利用できる Windowsアプリケーションの構築にうってつけの、Silverlightのスーパーセットです。SilverlightからWPFまで自然にスケー リングするソリューションを構築することが可能なため、大体において一挙両得となります。
Dash氏: - 再び、コンシューマRIAとエンタープライズRIAを区別させてください。我々は統合のニーズよりも相互運用性のニーズを多く目の当たりにしています。我 々がどこでクライアントOSの恩恵を受けようと（ビデオレンダリング用ドライバの活用など）、Curlはそれらを高速なパフォーマンスを得るために使用し ます。そのアプローチは、クライアント側の統合とサーバー側の相互運用性であるように思えます（ちなみにCurlにはサーバー側のコードは一切ありませ ん）。
Pilgrim氏: - これは良い質問です。私は、RIAソリューションはWebブラウザユーザーにより良いエクスペリエンスをもたらすために開発されたと思いました。Webと デスクトップ間の境界は現在かなりあいまいにぼやけています。Java 6 Update Nシリーズは、Javaアプレットをブラウザからデスクトップにドラッグすることを可能にしました。AdobeにはAIRがあります。もしここで可能性に ついてじっくりと考えたら、我々は突如として保有争い（Estate Battle）になります: 誰がデスクトップを所有するのか? どのアプリケーションがこれを実行できるのか? または、ユーザーや企業はどのアプリケーションをデスクトップに組み込むことを認めるのか?
このレベルでRIAを見ると、OS GUI、プライバシー、およびセキュリティモデルとの相互運用性のアイデアが最も重要となります。すでに、WidgetFXと呼ばれるプロジェクトがあり ます。この理論は、組織がGoogleデスクトップまたはWindows Live環境のスタイルでガジェットを構築することを可能にします。それは、多数のフレームワークやポータルアプリケーション（JSR 186、286およびWSRP）などのJava Enterprise Web APIを使用しないでエンタープライズアプリケーションを開発する、非常に興味深い方法であるかもしれません。
ユーザー（コンシューマ）はTweetDeckなどの成功したアプリケーションを適用するだろうと思います。アプリケーションをバンドルのエンタープライズRIAまたはガジェットとして販売するには、JavaFX側で間違いなくさらに多くの労力が必要になります。
Almaer氏: - 両方とも必要です。我々はinteropを支持してきましたが、それは開発者に崖を作ります（DLLなどに容易にリンクできなかった初期のJavaの頃に そうでした）。崖とは、あなたが「ふむ、この技術でそれはできないと思うので、Desktop APIプラットフォームに戻らなくてはならない」と言うことを意味しています。今こそ、ネイティブなプラットフォームができることを我々ができるように、 Webを押し進めてデスクトップサービスAPIを得るときです。
我々はセキュリティのベールに隠れてきました。「私たちはそれをできません。Web上にいるのです。」しかしこれは偽りです。機能性をユーザーに提 供するために、我々は結局ネイティブなプラットフォーム上でアプリケーションを記述し、ユーザーにそれをダウンロードしてインストールしてもらいます。こ の時点でユーザーはまったく安全ではありません! ユーザーは、システムを完全に制御するバイナリファイルを実行していて、望むことを何でも実行できます。困った事です。我々は、Webアプリケーションの 優れた、煩わしくない、信頼できるモデルを構築する必要があります。私は以前、これについて論じています
（http://almaer.com/blog/application-trust-models-expanding-web-applications-out-of-the-sandbox）。
3. 現在のところ、ビデオはRIAの導入を促進している最大のアプリケーションタイプです。今後12～18カ月でRIA技術の導入を促進すると思う他のアプリケーションタイプは何ですか?
Dash氏: - 我々はCurlで、高い拡張性、信頼性、セキュリティ、パフォーマンス、および予測可能性を要求するWebベースのエンタープライズアプリケーションに焦 点を合わせています。動機は、ここ15年間のクライアント/サーバーアプリケーションから、TCO（総所有コスト）を大幅に削減するWebベースのアーキ テクチャに切り替えることです。率直に言って、ビデオはこれらのアプリケーションにとって最優先であるとは思えません。ですから、Curlはミッションク リティカルなビジネスアプリケーションを実行する顧客として400もの大企業を抱えているわけです。ビデオを展開している顧客は1社もありません。
Pilgrim氏: - 他のメディアについては、明らかにオーディオだと思います。昨年2008年、JavaFXは、驚くほど成功を収めました。初めて、開発者はシンプルなビデオプレーヤーを記述し、それをアプレットとして展開することができました。
JavaFXに関して私が見込んでいる他のアプリケーションは、モバイルアプリケーションです。ゲームやコンシューマモバイルアプリケーションを見込むことができます。特に、現在JavaFX MobileはJavaMEスタックを基盤としています。
Sneath氏: - ビデオは依然として重要です。現在、配信されているビデオコンテンツのほとんどは、まだ「HD品質」からは程遠いものです。ビデオ分野にはバックエンドと フロントエンドの両方に関して多くの革新があり、我々は確実に今後数カ月間それをSilverlightの大きな機会と見なします。
さらに、今後数年にわたり多くのAJAXエクスペリエンスがクライアントフレームワークへのよりリッチな依存性を受け取ることに移行していくと思います。人々がHTMLとJavaScriptか ら引き出すことができるパワーの大きさに私はいつも驚かされていますが、GmailやOutlook Web AccessやFacebook などのハイエンドのエクスペリエンスを作り出すために必要なスキルは、たとえjQueryやASP.NET AJAXのようなフレームワークが出現したとしても、依然として非常に限られた開発者しか保持していません。Silverlightのようなフレームワー クは、開発者がエクスペリエンス自体の構築に集中できるよう不要な複雑さを取り除くことで、リッチインターネットアプリケーションの構築プロセスを民主化 します。
Almaer氏: - この技術を使用してWeb上で行えることへの期待は一転するという一般的な傾向があります。Webベースの電子メールクライアントを構築するなんて正気で はない、と人々が思っていた時がありました。現在は、大勢の人がGmail/Yahoo!メール/などを実行しています。マッピングについても同じことが 言えます。我々がBespinを構築し始めた理由は、単なる安っぽいテキストエリアではない、リッチなWebコードエディタの構築をどれだけ進めることが できるかを判断するためでした。私はこの傾向は継続すると予想しているおり、あっという間に本当にWeb上でビデオエディタやPhotoshopのような アプリケーションを目にするようになるでしょう。iWork.comのようなアプリケーションを見れば片鱗がうかがえます。
Girard氏: - 私の分野では、企業開発はRIA導入を促進しています。企業のニーズに合う高性能のアプリケーションを求める企業はますます増えています。
Stewart氏: - ビデオは依然として重要です。しかしもっと重要になるだろうと思うことは、リアルタイムのコラボレーティブアプリケーションです。Webはリアルタイムで 進行し始めています。我々はいつもチャットを行っていますが、そのリアルタイム速度で他のことが行うことはできていません。人々はより多くの時間をオンラ インで過ごし、Facebookのようなサイトが発展しているため、同僚や友人とのリアルタイムのコラボレーションに対する要求が大きくなるでしょう。 RIAは、ビデオ、オーディオ、およびリッチインターフェイスの組み合わせにより、そのニッチを満たすことができるところに唯一位置付けられていると思い ます。そして、AdobeとMicrosoftの両方に、RIAフロントエンドの一部としてこれを可能にする優れたバックエンドソリューションがありま す。
4. ご自分のターゲットフレームワーク/言語を考えて、今の段階で他の分野と比べたその最大の強みは何ですか（Ajax、GWT、Curl、Flex、Silverlight、JavaFxなど）?
Sneath氏: - 1つしか選べないのですか?!
Silverlightの主要な強みの1つは、小さなパッケージで非常に多くのパワーを提供するということです。メディアプレーヤーを探している場合は、 Silverlightはスムーズなストリーミング、デジタルコンテンツ保護、および真のHDサポートを提供します。次のビジネスアプリケーションを構築 するためのプラットフォームを探している場合は、Silverlightは、すべて.NET FrameworkとVisual Studioツールのフルパワーによって支えられた、数十ものコントロール、データ結合、Webサービスサポートを提供します。驚くべきコンシューマエク スペリエンスを創出したい場合は、Silverlightは、DeepZoomな どの革新的な新しいエクスペリエンスを伴う驚くべきグラフィックスとメディア統合を、Adobe Illustratorから独自のExpressionデザインスイートに及ぶツールと統合するXMLベースのマークアップ言語と共に提供します。すべて 含めて4MBちょっとで、VB、C#、JavaScript、Ruby、およびPythonをサポートし、PCとMacの両方について無料で入手可能です。
Dash氏: - Curlの最大の強みは、開発者の生産性（1つの言語がオブジェクト指向のタイプとクラスのほか、テキスト、グラフィックス、グリッドの領域全体をカバー します）、ランタイムの拡張性の利点、膨大な量のデータ処理、クライアント側のマシンコードへのコンパイルによる高速パフォーマンス、および高いセキュリ ティ機能です。これらは、すべての大企業のビジネスのミッションクリティカルなアプリケーションの基本的な要件です。
Pilgrim氏: - 最大の利点は、JavaFXがJavaと互換性があることです。そのため、Apache Software Foundation、Codehaus、SpringSourceなどのソースコードリポジトリを利用できます。
2つめの利点は、開発者用の標準のシーングラフAPI、アニメーションが言語およびプラットフォームに組み込まれたトリガおよびバインディングがあることです。
Almaer氏: - 私の世界はOpen Webです。Ajaxなどです。強みは、最初に会社名が付いていないことです。MICROSOFT Silverlight、ADOBE Flexは最初に企業名が付いていますが、これは単にAjaxです。単にOpen Web Platformです。つまり、我々は開発者がプラットフォームをコントロールするという機会を持っています。そのため、今日はうまく連携しているが明日 はどうか分からないといった会社の気まぐれで存在するのではありません。しかし、ただ「open matters!」のメッセージを売り込んで生きていることは不可能であり、プラットフォームレベルで競争する必要があります。そして、やるべき仕事はあ りますが、共通点にかなりエキサイトしています。
Girard氏: - GWTはエコシステムにとってあまり破壊的でない技術です。
- java言語を知っている開発者は大勢います。彼らは皆、自分自身を無視するRIA開発者です。GWTへの切り替えは、java開発者にとって約1日かかります。
- ブラウザはGWTアプリケーションのランタイムです。これは最も広く普及しています: GWTアプリケーションはiPhoneやAndroid上でさえすべてのブラウザで動作可能です。
Stewart氏: - 参入障壁はとても低いですが多くの利点があるため、Flashの普及はもちろん重大だと思います。Flexは最も成熟した技術です。我々はフレームワーク のバージョン4に取り組んでおり、Flexはエンタープライズ環境から生まれたため、フレームワークは安定していて普及が広まっています。私は、 Adobeの設計コミュニティもそれに優位性を与えているのだと思います。設計はRIAの中核部分の1つであり、Adobeは誰よりも上手にそれを行いま す。我々は、その精神を開発者コミュニティに注ぐことに取り組んでいます。また、ActionScriptも強みであると思います。これはバージョン1から大きな進歩を遂げており、JavaScript開発者にとっては容易なジャンプアップであり、C#またはJava開発者にとっては非常に選択しやすい、完全なOOP言語です。
5. ご自分のターゲットフレームワーク/言語を考えて、今の段階で他の分野と比べたその最大の弱点は何ですか?
Almaer氏: - 他のプラットフォームにはホームがあります。統合ドキュメンテーションがあります。あなたは、どこに進み、何をすべきかが分かります。Ajaxでは、切り 抜けることが非常に困難な「共有地の悲劇」があります。我々は2009年以降、この件について（大規模コミュニティとして）対処したいと思っています。
Pilgrim氏: - 1つ目の大きな弱点は、複雑なシーングラフベースのコンポーネントが欠如していることです。コンポーネントはSwingを使用しません。たとえば、純粋なシーングラフSplitPaneコンポーネントも、TabbedPaneも、JTableの同等物もありません。記述時に自分でこれらをプログラミングする必要があります。私はSplitPane.fxおよびBorderLayoutPanel.fxコンポーネントを記述しました。しかし、JFXtrasプロジェクトにより、助けは身近にあります。さらに、私はSunが自ら行っていることが何なのかよく分かりません。高度なコンポーネントスペースにおいては、FXはSilverLightとFlexにかなり後れを取っています。
2つ目の大きな弱点は、JavaFXメディアには現時点でレコーディング機能がないということです。つまり、クライアントを使用してメディアをエンコード することができません。現在のところ容易にSims-On-Stage（Electrionic Artsが買収した人気のWebカラオケサイトbought by）のJavaFXバージョンを記述することはできません。Java Media Component APIを拡張する必要があります。ストリーミングレコーディング機能が本当に必要な場合は、JavaSound APIを使用して技術的に高度な多くのプログラミングを行う方法があります。この際、FXはAdobeに後れを取っています。JavaおよびJMCは、も し実際にサブピクセルレンダリング（ビデオ）に本腰を入れて取り掛かり、レコーディングや処理など、オーディオ効果（リバーブなど）を提供することを可能 にしたら、Adobeを上回ることができるでしょう。
JavaFXは現時点で金融アプリケーションに最適です。比較的シンプルなGUIで市場データに関するストリーミングのビジネス情報をクライアント に提供できます。特別なパフォーマンスレベルの表形式データを持つJavaFXアプリケーションの構築はもう少し待つ必要があるかもしれません。
Dash氏: - Curlの最大の弱点はあまり世に知られていないことです。我々の顧客の多くは、Curlが高いパフォーマンスとセキュリティのニーズを解決できるという ことを発見する前にAjaxとFlexを試して失敗しています。また、ビデオレンダリングは、決してターゲットではなかったため、我々の強みの1つではあ りません。
Sneath氏: - 競合会社からよく耳にする反論の1つは、Silverlightはまだコンシューママシンに広くインストールされていないということです。むしろ、我々は Silverlightが市場に示している牽引のペースに喜んでいます。Silverlight 2の公開からちょうど5カ月経ちましたが、インストール数は何億にものぼり、SilverlightはFirefoxとGoogle Chromeを足したよりも多くのマシンにインストールされている状況です! 当然、現在の栄光に満足しているわけではありません。我々は、プラットフォームに投資し続ける必要があります。しかし、Netflix、March Madness、Sky UK、AOLのような大規模なショーケースサイトで、継続的なインストールを促進し続けるだろうコンテンツがあります。
Stewart氏: - 認識に関する点です。Flashは依然として対処すべき認識の問題を多く抱えています。Flashがアプリケーションではなく煩わしい広告媒体の提供方法 として見られているためです。幸い、ビデオがある程度この認識を変えるのに一役買いましたが、まだ多くの「悪いFlash」は存在しています。他の弱点 は、私が思うに、FlashはWebエコシステム内でより良く適応する必要があるということです。SEO、リンク、解析などの多くのものはすべてHTML モデルを中心に構築されるため、Webがいかに稼働して収益を出すかの大部分は本当にHTMLとJavaScriptに依存しています。そういう点でFlashがより良くなり得る方法を目にし始めていますが、結局いつも少し違いを感じるようになり、それが私が埋めたいと思っているギャップです。
Girard氏: - GWTの弱点はブラウザの弱点です。最も重要なのは確実に2Dグラフィックスについてです。ブラウザのCanvasやSVGのサポートはもっと良くなる可能性があります。
6. ほとんどのRIA言語はクライアントとサーバーどちらの開発にも使用されていません。一般にバックエンドの動作はPHP、Java、.NETなどで行われます。RIAに影響するこの多言語プログラミング(リンク)モデルについてどう思いますか?
Dash氏: - 多言語（Polyglot）という表現を気に入りました。率直に言って、それは混乱です。世界は2言語の体系（C#とXAML; ActionScriptとMXML; Java FXとJavaなど）に分極化しているのが分かります。2は4より良くて4は6より良いといえます。しかし、Curlでは1つの言語がプレゼンテーション 類とロジック類の両方をカバーすると我々は信じています。そのため、MITの研究者らは領域全体を扱う1つの統一言語を設計しました。これは、とてつもな い「プログラマ節約」、我々がRIA世界で重視しているとは思えないもの、につながります。に思えるような、に見えない何かをもたらします。カスタマーエ クスペリエンスはこの利点を大いに実証しています。Curlはリッチなクライアントアプリケーションを構築するための優れたマルチパラダイム言語です。我 々は、皆が言語のレパートリーにCurlを追加することを願っています。
Stewart氏: - 私はそれが採用の促進に一役買ってくれることを願っています。新しい言語を学ぶことは、解釈次第で困難なものにも面白いものにもなり得ることです。しかし この記事で指摘するとおり、アプリケーションのために異なる言語を組み合わせることはほぼ不可欠になっています。結局、それによって開発者は、自分達に最 適に動作して生産性を最大限に高めることができる言語の組み合わせを自由に使用できると思います。皆がその理論に同意したなら、すべてのRIAベンダーが 採用とアプリケーションの上昇を目にするでしょう。それこそ、我々皆が奨励していくべきものです。
Almaer氏: - 私はRESTfulな世界が好きです。分離（decoupling）を持つことはすばらしいと思います。しかし、我々はJavaScriptの場合で、統一されたフロントエンドとバックエンドの概念を探っています。ブラウザのJavaScriptと深く関与した、リッチなサーバー側のJavaScriptプラットフォームで、昔のSmalltalkのような面白いソリューションを実現できるでしょうか? 探ってみたいと思います。
Girard氏: - GWTの場合、この件は当てはまりません。クライアントとサーバーに同じ言語を使用します。とてもうれしいことです。
Sneath氏: - これは間違いなくSilverlightの独自の利点です。.NET開発者の方なら、すでにSilverlightを知っています。プログラミングモデル は同じで、単に完全な.NET Frameworkのサブセットです。実際、ASP.NETベースのサーバーで動作するように今日記述した同じソースコードを取って、たいていは変更を加 える必要なく、それをSilverlightベースのクライアントアプリケーション内で使用することができます。.NETの普及のおかげで、Xboxから モバイル機器、Webブラウザ、Windowsクライアントアプリケーション、データセンターサーバー、クラウドまで、多様なデバイスクラスにわたり、 コードだけでなくスキルを共有することができます。
Pilgrim氏: - JavaFX開発者の場合、汚れ仕事（dirty work）についてはJavaでも記述する必要があると思います。特に、EJB、JMSを使用しているか、ネットワーク上でXMLを投入するようなクライ アントサーバープロトコルを使用している場合はそうです。JavaFXがサーバー側で役に立つとは思えません。ユースケースを示してくれますか?
JavaFXコードを動的に生成し、それをコンパイルし、その後、動的に生成されたJARファイルを参照するJNLPファイルに返送する、 Grailsアプリケーションを記述できると考えるかもしれません。はい、技術的には可能ですが、この途方もない労力のビジネスケース（投資対効果検討 書）はどのようなものでしょうか? つまり、いわゆる貸し渋りの最中、それは時間とお金の無駄です。むしろ、言語を使用してビジネスの問題を解決することが、革新への本当の道になるでしょ う。この関連で、JavaFX、Flex、およびSilverLightはすべて実行可能なアイデアとプラットフォームであると思います。