Google Web Toolkitを使用しない場合
私は主要な社内Webアプリ開発プロジェクトでのGWTの使用を検討しています。つまり、私の目での主な利点は、Javascriptへのクロスコンパイルであり、これにより（少なくとも理論的には）チームが技術スタックのサイズを1つ減らすことができます。 。
ただし、以前に（ほとんどの開発者と同様に）焼き尽くされているため、特定の問題ドメイン内での使用を妨げる、または制限するGWTの問題に実際にそれを使用したプログラマーから連絡をもらいたいです。
GWTを使用することに反対する議論は何ですか？なぜですか？
私はこの質問に答えるのは良いことも悪いこともあります。以前に実際に使用したことがあるという点で良いですし、GWTで作業する前にHTML/CSS/JavaScriptでかなり経験を積んだという点でも悪いです。これにより、他のJava DHTMLを本当に知らない開発者がそうではなかったかもしれないような方法でGWTを使用することによって、私は頭を悩ませました。
GWTはそれが言うことを実行します-JavaScriptを抽象化し、ある程度HTMLをJavaに抽象化します。多くの開発者にとって、これは素晴らしいように思えます。ただし、Jeff Atwoodが述べているように、 すべての抽象化は失敗した抽象化です （GWTを検討する場合は一読の価値があります）。 GWTでは、これにより特に次の問題が発生します。
GWTでHTMLを使用するのは大変です。
私が言ったように、HTMLをある程度抽象化することさえあります。 Java開発者にとっては良さそうです。ただし、そうではありません。HTMLはドキュメントのマークアップ形式です。Javaオブジェクトを作成してドキュメントを定義するには、ドキュメントのマークアップ要素を使用しません。これは厄介なほど詳細です。また、十分に制御されていません。HTMLでは、基本的に<p>Hello how are <b>you</b>?</p>を記述する方法が1つあります。GWTでは、3つの子ノード（text、B、text）がアタッチされていますPノードに追加します。最初にPを作成するか、最初に子ノードを作成します。子ノードの1つが関数の戻り結果である可能性があります。多くの開発者による数か月の開発の後、HTMLの内容を解読しようとしましたドキュメントは、GWTコードをトレースすると、頭痛の種となるプロセスのように見えます。
最終的に、チームは、おそらくすべてのHTMLにHTMLPanelを使用するのが正しい方法だと判断しました。これで、Javaコードで簡単にデータにバインドするためのコードに要素を利用できるようにするというGWTの利点の多くを失いました。
GWTでCSSを使用するのは大変です。
これは、HTML抽象化にアタッチすることで、CSSの使用方法も異なることを意味します。私が最後にGWTを使用してから（約9か月前）は改善されたかもしれませんが、当時のCSSサポートは混乱していました。 GWTでHTMLを作成する方法により、注入されたことを知らないレベルのノードが存在することがよくあります（CSS開発者は、これがどのようにレンダリングに劇的に影響するかを知っています）。 CSSを埋め込んだりリンクしたりする方法が多すぎて、名前空間の混乱を招きました。その上、スプライトのサポートがありましたが、これも素敵に聞こえますが、実際にはCSSが変更されており、プロパティの書き込みに問題があり、後で明示的に上書きする必要がありました。 CSSをコーディングし、GWTがそれを台無しにしないように再設計する必要があるだけです。
問題の結合、利益の交差
どの言語にも、独自の一連の問題と利点があります。使用するかどうかは、それらに基づいた加重式です。抽象化を行うと、すべての問題の結合、および利点の共通部分が得られます。 JavaScriptには問題があり、サーバー側のエンジニアの間で一般に見過ごされていますが、迅速なWeb開発に役立つかなりの数の機能も備えています。クロージャー、シンタックスショートハンド、アドホックオブジェクト、JQueryによって実行されるすべてのもの（CSSセレクターによるDOMクエリのような）を考えてください。 GWTでの使用を忘れてください！
関心事の分離
プロジェクトの規模が大きくなるにつれて、懸念事項を適切に分離することが重要であることは誰もが知っています。最も重要なことの1つは、表示と処理の分離です。 GWTはこれを本当に困難にしました。おそらく不可能ではないでしょうが、私がいたチームが良い解決策を思いついたことは一度もありませんでした。
デスクトップ！= Web
@Berin Loritschがコメントに投稿したように、GWTが構築されているモデルまたはマインドセットは、アプリケーションが処理エンジンと密結合している生きたディスプレイを持つ生きたアプリケーション用に構築されています。これは、多くの人がWebに欠けていると感じているからです。しかし、2つの問題があります：A）WebはHTTP上に構築されており、これは本質的に異なります。上で述べたように、HTTP、HTML、CSS、さらにはリソースのロードとキャッシング（画像など）に基づいて構築されたテクノロジーが構築されていますforそのプラットフォーム。 B）Java Webで作業してきた開発者は、このデスクトップアプリケーションの考え方に簡単に切り替えることはできません。アーキテクチャこの世界ではまったく異なる分野です。おそらくFlex開発者は、Java Web開発者よりもGWTに適しています。
結論として...
GWTは、Javaを使用するだけで簡単にダーティAJAXアプリケーションを簡単に作成できます。ダーティが望みどおりに聞こえない場合は、使用しないでください。会社私が働いていたのは、最終製品を重視する会社で、ユーザーにとっては視覚的でインタラクティブな洗練された感覚でした。私たちのフロントエンド開発者にとって、これは、HTML、CSS、およびボクシンググローブを付けたままピアノを弾くようなGWTを使用したJavaScript。
使用量の多い大きなeGovernment Webアプリケーション（バックエンドのSOA）にはGWTを使用します。古いUIはDHTMLでしたが、ブラウザーの互換性、パフォーマンスの最適化、開発プロセスに問題があったため、代替手段を探しました。
私たちの要件は次のとおりです。
- サーバーの負荷を最小化するクライアント側のUIレイヤー
- ブラウザの互換性
- webベースのRIA
- 簡単なパフォーマンス最適化
- クライアントプラグインのインストールは必要ありません。通常のWindowsインストールで動作するはずです。
私たちはGWTを選択しましたが、後悔したことはありません。新しいチームはDHMTLの経験がほとんどないため、GWTのJava devプロセスは非常に役に立ちました。ボックスから得られるものは次のとおりです。
- ブラウザの互換性
- Javaベースの開発プロセスとコードの再利用
- リクエストの最小化が簡単（画像バンドルなど）
- 簡単なアグレッシブキャッシング（新しいアプリはクライアント側で完全にキャッシュされます）
- すべてのリソースの簡単な圧縮（古いバグのあるIEのjsでも）
- そして、もっとたくさん、ここで言及しておきます
アプリケーションは、起動時にサーバーに1つの要求のみを発行します。マイナス面としては、GWT（およびAndroid）の設計はそのままでは貧弱ですが、とにかく独自のルックアンドフィールを適用する場合は、CSSを適応させる必要があります。または、GWTのさまざまなコンポーネントライブラリを使用して、適切なスタイルとテーマを簡単に適用できます。
私にとっては、HTML DOMが手作りのものほど良くないかもしれませんが、これは決して問題ではありませんでした。 C++で開発する場合、生成されたアセンブラコードは表示しません。 GWTで開発するとき、JSコードを見る必要はなく、DOMを調べてリファクタリングを行う理由は一度だけでした。
私にとって、RIA開発に関してはGWTが唯一の選択肢であり、GWTに明るい未来があることを願っています。ミッションステートメントをご覧ください：
[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction
しかし、Googleが社内プロジェクトの多くでGWTを使用していないこと、そして現時点でGWTの将来についていくつかのうわさが存在していることは明記してください。
[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-Dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC