Java、HTML、JS、およびCSSを使用してWebアプリケーションを開発した経験があります。この時点で、私は学ぶ/ GWTを試してみたいが、私はので、私は次のように明確に感謝しないの前に：より多くの時間がかかるが、GWTでどのくらいの伝統的なHTML/CSS/JSの開発に比べてHTML/JSからGWTへの移動
ありがとうございます。
1）モジュールのサイズがかなり大きくなった場合、フロントエンド（またはデプロイメント前にコンパイルする）を少しだけリフレッシュするのはかなり時間がかかることがあります。しかし、Firebugやこれに類するツールをいつもと同じように使うことができますし、もっと興味深いのは、デバッグが簡単で強力です。しかし、JavaとJavascriptベースの正規表現の間の非互換性のような小さな問題があります。
2）たとえば、 Photoshopなどのデザイナーが提供する「意図したスクリーンサンプル」（これがどのように呼び出されているかわからない）をHTML/js GWTベースのフロントエンドに変換します。これは本当の欠点です。
3）あなたは何をしているのかを知る必要があります。実際には非常に容易に利用可能です。 GXT/SmartGWTまたは類似のライブラリを使用すると便利です。フロントエンドでJQueryのプラグインをすべて組み込むことも難しいです。
4）これがGWTを強力にします。バックエンドのものと、フロントエンドからの通信の容易さがあります。私の見解では、多くのビジネス（主にバックエンド）ロジックが必要な場合は、GWTを使用して効率的に使用する方法を学ぶと後悔することはありません。 BE部分との通信により、ビジネスロジックもクライアントに書くのがはるかに容易になります。フロントエンドで美しく、標準ではなく、簡単にカスタマイズ可能なものを欲しがるのであれば、それほど多くのロジックではなく、あまり複雑ではないデータ転送など、「標準的な」非GWTアプローチを使うほうが良いです。 GWTを扱う多くの人にとって大きな利点の1つは、JSでコードを記述する必要がなく、GWTによって生成されたJSコードが高速で効果的でクロスブラウザであることです。フロントエンドをhtml/jsで書いてもいい（適切なデバッグ制御を見逃してはいけない）場合は、Javaを使用してBEを書きたいと思うなら、DWRやその他の軽量Ajaxライブラリが面白いかもしれません。
GWTは、スケーラビリティと管理性が向上するように設計されていますが、もちろんコストがかかります。小規模なチーム（つまり1〜5人）の小さなサイト/アプリでHTML/CSS/JSで直接作業することに慣れている場合、GWTは価値がある以上に複雑になる可能性があります。
大規模な環境にあり、繰り返しやプロジェクト内でのさまざまな人の移動が多い場合、おそらくフレームワークを使用する価値があります.GWTはかなり良いです。
GWTをカスタマイズするのは難しいですが、大変な変更があった場合には大変です。すべてのコンポーネントがどのように適合するかを理解するために、GWT APIとアーキテクチャについて学ぶことはたくさんあります。
GWTでカスタマイズを実装するのは難しくありません。あなたはjsで翻訳されるJavaでコードを書くことを検討しなければなりません。
もちろん、別のjsライブラリと統合する可能性はありますが、それでも普通の古いhtml/css/jsよりも難しいです。
また、あなたがSEOをやろうとしている場合、GWTは扱いにくいという事実も考慮してください。