カレンダーシステムのカスタム（特定の種類のイベント）を持つデータベースバックアップ対話型AJAX webappを作成したいと考えています。これにはかなりのJavaScriptとAJAXが含まれていて、インタフェース用のGoogle Web Toolkitとサーバー側のRuby on Railsについて考えました。新しいWebアプリケーションにGoogle Web Toolkitを使用する必要がありますか？
Google Web Toolkitは信頼性が高く、優れていますか？ Google Web Toolkitを選択した場合の隠れたリスクは何ですか？ Ruby on Railsをサーバ側で簡単に組み合わせることはできますか？または、jQueryのようなJavaScriptライブラリを直接使用する必要がありますか？
私は経験豊富なプログラマー（C++、java、c＃）ですが、このプロジェクトでは無料のツールのみを使用したいと思います。
実際には、RESTを正しく使用している限り、RoRはGWTがうまく動作するように作られています。 Google Web Toolkit Applicationsの書籍にあります。この種のアイデアを使って本のデモを見ることができます。hereそれはあなたが何の問題もないと言っているわけではありませんが、私はサポートが間違いなくそこにあると思います。
here（MITライセンス）を見つけるためのRoR/GWTを簡単に作成するためのすてきなプロジェクトがあります。私はまだ試してみる機会がありませんでしたが、それにはかなりの量の思考が入っているようです。 1つの捉え方は、まだ2.1のRailsで完全にテストされておらず、わずか2.0であるため、いくつかの（おそらく軽微で修正可能な）エラーに遭遇する可能性があるということです。
GWTを使用してJavaですべてをコーディングすることができます。また、既存のサードパーティのJavaScriptライブラリを統合することもできます。これはとてもいいです。私はRoRを使ったことは一度もありませんでしたので、それについて何も言えません。
Javascript/CSSではなく、Javaでの経験がある方は、GWTは賢い人になるでしょう（もちろん、それらを学びたい場合を除きます）。 CSSには非常に多くの細かいことがあります。 IE6でのみ発生する2ピクセルのミスアライメントを半日修正するのは珍しいことではありません。
バックエンドにRORを使用するのは簡単ではありません... GWT ajax通信はサーブレットなので、可能です。しかし、Javaオブジェクトを前後に渡すための優れた機能を提供しています。これは、サーバーがJavaも使用していない場合には利用できなくなります。
また、（ "Groovy on Rails"）を使用すると、RailsフレームワークとJava VMの利点が得られます。
JAVAを知っていて、TomcatやGlassfishコンテナのようなホストがあれば、私はバックエンドにRubyを使用するよりもはるかに多くのことをお勧めします。主な理由は、すべてのオブジェクトを共有し、RPCメカニズムを組み込むことができるということです。私は非常に多くのプロジェクトでこれをやったことがあります。また、Javaオブジェクトを何かに変換してからやり直すことはないので、コードのエラーが起こりにくいことは言うまでもありません。
Railsでto_json関数を使用してGWTをRailsにリンクしてから、GWTでJSONを読み込んでいます。すべてサポートされていますが、JAVAでバックエンドを行うよりもはるかに面倒です。
もちろん、安価なホスティングがあれば、Javaコンテナはほとんど問題になりません。その場合、Railsが次善のものになると思います。
GWTは素晴らしいコミュニティーを備えた非常に高品質です。しかし、もしあなたが望むなら、CSSはレイアウトの多くをやり遂げることができます。普通のウェブと同じように、あなたは見た目を調整したいと思うなら、CSSを知る必要があります。GWT-extやExtGWTのようなライブラリは、見た目にはまったく見えないが、価格（あなたのアプリに余分なサイズ）のためにちょっとした助けになるかもしれない。
GWTをROR、PHPなどのJava以外のバックエンドと統合する場合は、GWT 1.5がJavaScriptオーバーレイタイプをサポートするようにしてください。この機能を使用すると、ネイティブJavaScriptオブジェクトの上部にマップできるクラスを作成して、それらのオブジェクトのプロパティやその他の拡張機能のアクセサメソッドを簡単に提供できます。
詳細については、このリンクを参照してください： JavaScript Overlay Types
ですから、AJAX経由でバックエンドからJSONエンコードされたデータを返すことができます呼び出して、JavaScriptのオブジェクトにそれを解析し、オーバーレイを使用して、GWTのJavaコードを介してデータにアクセスしますあなたが作成したクラス。また、ページをレンダリングするときに、静的な設定データをJavaScriptオブジェクトとしてレンダリングし、データを取得するためにAJAX呼び出しを行う必要はなく、このメカニズムを使用して読み込むことができます。
最近、the disadvantages of GWTについて書きました。主に、欠点は、アプリケーションの一部の変更に対する長いデプロイサイクルとかなり急な学習曲線です。経験豊富なJavaプログラマは、2番目の問題はあまり問題にならないはずです。別個のバックエンドを使用すると、1番目の問題も緩和されます（アプリケーションの 'サーバー'部分を変更すると、完全な再デプロイが主に必要になります）。
GWTは、多くの可能性を秘めた素晴らしいフレームワークです。しかしそれはまだかなり新しいことであることを覚えておいてください。実際にあなたに迷惑をかける可能性のある未解決のバグがあります。通常、過去には醜い回避策が必要です。コミュニティは素晴らしいですが、あなたはおそらく、Googleがまだ答えることができないいくつかの問題が遅かれ早かれで終わるでしょう。
しかしねえ、私はそれのために行くと言う。 GWTの可能性はすばらしく、将来は明るいものになると確信しています。
新しいプロジェクトには必ずGWTを使用するべきです（古いプロジェクトでも使いやすいです）。
私の経験では、学習して使用するのが非常に速いです。コンパイルされたjavascriptコードは、あなたが手で書くことができるものよりはるかに優れており、速く動作します。
もう一つの利点は、あなたが（単独で、JavaScriptで地獄です）コードしているデバッグする機能です
このブログは、GWTの多くの経験豊富なユーザからの入力を持っており、いくつかの素晴らしい議論のポイントを持っています。個人的には、さまざまなUIフレームワークの経験があります。私は2セントを追加します。 基本利点とGWT
GWTはJAVAへのWeb層のプログラミングを要する
基本的な利点の欠点を見てみましょう。したがって、Javaの明白な利点が活気づき始めます。オブジェクト指向プログラミングを提供します。また、優れたデバッグとコンパイル時間のチェックを提供します。 HTMLとJavascriptを生成するので、ジェネレータ内の複雑さを隠すこともできます。
基本的な欠点は
欠点は、同じ文から始まります。 GWTはWebレイヤーのプログラミングをJAVAに引き継ぎます。もしあなたがJAVAを知っていれば、ビジネスロジックを書くための代替言語を探すことは決してありません。それは自給自足で十分です。しかし、それは、Javaアプリケーションの構成を書くことになると思います。プロパティファイル、データベース、XMLなどを使用します。設定をJAVAクラスファイルに保存することはありません。考えてみてください、どうしてですか？
これは、構成が静的なデータであるためです。それはしばしば階層を必要とする。それは可読性があると考えられています。コンパイルは必要ありません。 JAVAプログラミング言語の知識は必要ありません。つまり、それは別のボールゲームです。今問題は、それが私たちの議論にどのように関係しているかです。
今、ウェブページについて考えることができます。あなたはビジネスロジックを書くWebページを書くときはどう思いますか？絶対違う。 Webページは単なる設定です。これは、階層的なコンテナおよびフィールドの構成です。 Webページから取得して表示するデータ用のビジネスロジックを記述し、Webページ自体を作成しないようにする必要があります。
前の段落は、非常に強い声明を出しています。これは、HTMLとXMLベースのWebページが依然として最も一般的なWebページである理由を説明します。 XMLは、ビジネスにおいて構成を記述するのに最適です。フレームワークは、ビジネスロジックからのWebページの明確な分離を可能にする必要があります（MVCフレームワークの目標）。これを行うことで、Webデザイナーは、XMLを設定するだけでプログラミング言語の複雑さに悩まされることなく、鮮やかな見た目のWebページを作成するために、視覚化と芸術性の彼のスキルを適用することができます。開発者はビジネスロジックを記述するためにビジネスJavaで最高の性能を発揮できます。
最後に、影響について直接話しましょう。 GWTはこのプリンシパルを分割し、失敗するようにします。 GWTアプリケーションを開発するためのコストは非常に高くなります。なぜなら、Webページを書くためにマルチキープログラマーが必要となるからです。必要なルック・アンド・フィールは、達成するのが非常に困難です。不必要な編集のために、ウェブページを修正するためのターンアラウンドタイムが非常に高くなります。最後に、あなたがJavaでWebページを書いているので、ビジネスロジックでWebページを破損するのは非常に簡単です。知らないうちに、避けなければならない複雑さを導入します。
私たちのチームは最近、同じ質問をしました。特に、デザイナープラグインがGWTと協力してチームのJava以外のエキスパートにもっとアクセスしやすくなったため、GWTに参加しました。誰でもこの選択をしますが、GWT Designerプラグインを使用しないでください！ IE8と互換性のあるGWTアプリケーションを作成するために更新されていません（少なくとも1年は明らかです）。
私たちのチームは、Chrome、FF、Safariで完全に機能するアプリケーションレイアウトをほぼ完了しました。その後、彼らはIEで爆発した。 IE 7は部分的なページをロードしますが（コンポジットインクルードは含みません）、IE8はアプリケーションをロードすることさえできませんでした。それはちょうど掛かった。
デザイナープラグインには、IE互換ではないCellTableウィジェット（CellTable、DeckPanel、Horizontal Panel、Vertical Panelなど）を追加できるボタンがあります。デザイナーの助けを借りずにJavaでレイアウトをやり直す必要がある場合、これらは激しい痛みを引き起こします。
経験豊富なGWTユーザーが好きですが、デザイナープラグインがあなたを殺します。
これは壊れた英語であなたの技術を叩く場所ではありません – Yarin
大きなプロジェクト、ビジネス環境でGWTを6ヶ月使用していたので、私は強く同意します。 GWTはFAILです。 – rapadura