GWTは、JavaコードとJavaランタイムのクラスライブラリのサブセットをJavaScriptコードに変換するソフトウェアスタックです。
JavaScriptツールキットと比較すると、GWTは本質的にも使用法によっても疎外感があり、JavaScriptを直接使用することで得られるきめ細かな制御の多くを奪い、非常に複雑で単純なこともできます。
Web開発者が、純粋なJavaScriptおよびJavaScriptフレームワークとツールキットを使用する代わりに、もともとWebを対象としていない言語を使用するGWTのようなツールを使用することを選択するのはなぜですか？
それはかなり良いもので、どの基準に基づいていますか？
回答:
それは素晴らしいです：
バグを早期に発見します。（Google Closureは、開発者をJavaScriptの世界に引き込みつつ、少しだけそれに応えます）。
GWTは（大規模なアプリケーションの場合）あなたよりも高速でコンパクトなJavaScriptを記述し、同等の完全なJSソリューションよりも間違いなくクライアントに送信されるものを簡単に決定できます。
まともなMVCまたはMVPアーキテクチャが既に簡単にプリベークされているため、大規模なアプリケーションの懸念を適切に分離できます。
GWTは興味深いライブラリを提供し、動的バンドルローディングでI18N対応のアプリケーションを簡単に（まあ、より簡単に）作成します。
Eclipse IDE内およびコマンドラインからJUnitを使用します。これは私の最初のポイントに関連しています。また、GWTプロジェクトでJavaのコード品質ツールの一部を使用することもできます（バイトコードチェックではなく、ソースチェック用です）。
GWTは万人向けではありません。これにより、一部の人々の生産性が向上し、JavaScriptに（過度に）触れることなく、動的なフロントエンドを備えたプロフェッショナルなWebアプリを構築するための優れたツールが、JS以外の開発者に提供されます。しかし、それがうまくいかない場合は、何か他のものを使用してください。
上記のほとんどが必要で、Javaは必要ない場合は、Google ClosureまたはDojo Toolkitをご覧ください。
JavaScriptの世界（およびWebフロントエンドテクノロジー全般）は最近非常に活発であるため、物事は見直されています。しかし、ほんの数年前、物事はそれほど明るくありませんでした。LESS / SASSはそれほど一般的ではなく、jQueryはまだ工場出荷時のJSライブラリではなく、JavaScriptライブラリは1週間おきに生成されておらず、ツールは一般的にそれほど優れていませんでした。
しかし、動的なフロントエンドを備えたプロフェッショナルで大規模なWebアプリケーションへの需要がすでに高まっているため、開発者の生産性を高めるために埋めるギャップがありました。JavaScriptには、注意する必要がある非常に多くの落とし穴と奇妙な点があり、それらを気にする必要さえない方が良いかもしれません。したがって、GWTのようなツールのニッチ。
それ以来、他のものが登場しました（CoffeeScriptが思い浮かび、Dartが進行中ですが、大規模なJavaScriptフレームワーク、Node.JSなどを使用したサーバーサイドJSの革命、そしてJavaScriptに対する強力なカムバックがすべて「十分」です-クライアント側だけでなく、ビジネススタックの他の部分でも使用される言語。
もちろん、Firebugを使用してGWTコードをデバッグできますが、理想的には、ライブコードデバッグサポートを提供するEclipse IDEのデバッガーから直接デバッグすることをお勧めします。
ただし、Firebugは引き続き使用できますが、GWTは最適化および圧縮されたJavaScriptを生成するため、そのままでは簡単にデバッグできない場合があることに留意する必要があります。
はい、もちろん、CSSコードを自分で記述する必要があります。ただし、GWTプロジェクトと他のツール（SASSなど）を、多少簡単に組み合わせることができます。
GWTをそうでないものと間違えないでください。Javaバイトコードとしてクライアント側で直接実行されるJavaコードを記述しないでください。Java言語でコードを記述し、それを効率化のためにJavaScriptに変換し、より高レベルの言語を使用できるようにします（または、少なくとも、それが本来の意味です）。
おそらく、JavaとJavaScriptは、抽象化レベルの点で同等と見なすことができます。ただし、Javaにはいくつかの利点（上記で詳細）が付属しているため、既存のツールの利点を再作成することなく享受できるという利点があります。Googleの開発者は、既存のJava指向のツールを再利用できるようにするだけでなく、実際にはJavaScriptアプリケーションを開発するという賢いアイデアを思いつきました。
さらに、JavaScriptとJavaコードが別々に処理される2言語Webアプリケーションの管理が面倒であることが多い、別の問題も解決します。GWTを使用すると、開発プロセスの両側で一定レベルの収束が可能になります。
GWTでWebアプリケーションを開発するのに何年も費やした後、私の意見では、GWTには非常に重大な不利な点があるので、強制されなければ再び使用することはありません。
DOMツリー
JavaScriptのパフォーマンスは向上しますが、レンダリングされたDOMツリーは不必要に複雑になることがよくあります。たとえば、ツリーの実装では、個々のアイテムごとに<table>を含む13以上のDOM要素を使用します。大きなツリー（約10000アイテム）を使用すると、ブラウザがフリーズするだけです。純粋なJavaScript / HTML / CSSツリーは、同量のアイテムを簡単に処理できました。
開発
純粋なJavaScript / HTML / CSSソースの変更と試行のサイクルに勝るものはありません。ソースファイルを保存し、ブラウザでページを更新するだけです。これは生産性の重要な要素であり、GWTはコードサーバーを使用しても競合することはできません。
JavaScriptのデバッグは、ChromeまたはFirebugのデバッガーを使用すると、非常に簡単で楽しいです。
ハンマーエキスパート
すべてにJavaを使用するという考え方は、「ハンマーの専門家」である開発者向けです。彼らはハンマーの達人なので、すべてが釘です。このアプローチは非常に間違っていると思います。GWTを使用するには、CSSとHTMLの知識も必要です。これがなければ、開発者は多くの場合、ほとんど解決できない問題にぶつかりますが、HTML / CSSの経験がある人は解決策を思いつきます。開発者がこの能力を必要とする場合、HTMLで開発することで簡単になります。
私の意見では、純粋なJavaScript / HTML / CSSでの開発と比較して、GWTによって提供される利点のほとんどは少なくとも疑問の余地がありますが、欠点ははるかに深刻です。
私が考えているGWTを使用する利点はほとんどありません（詳細は私のブログhttp://www.pandurangpatil.com/2012/09/benefits-of-using-gwt.htmlを読んでください）
GWTクライアントアプリケーションはJavaで記述されているため、同じ理由でコンパイル時に構文上の間違いを見つける機会があります（ただし、これらの機能はブラウザ自体ではサポートされていないため、すべてのJREクラスをサポートしていません）。私が言っていることを理解するために例を見てみましょう。純粋なJavaScriptライブラリを使用してJavaScript変数名のスペルを間違えた場合。このような間違いを見つけることができる唯一の方法は、アプリケーションを実行し、目的の結果をテストすることです。GenericsやAnnotationsなどのJava機能は完全に使用されており、アプリケーションで使用できます。
生成する必要のあるコードはJavaである必要があるため、既存の利用可能なライブラリを利用するか、要件に従って簡単にコードを生成するライブラリを作成できます。GWTコンパイラーはそれをコンパイルし、JavaScriptに変換します。
コードの管理がより簡単になります。
GWTクライアント側のコードで使用でき、Javaのようにサーバー側のコードでも使用できるように、一般的なビジネスロジックを簡単に書くことができます。たとえば、データの検証や一般的なユーティリティ関数です。
GWT eclipseプラグインを使用すると、ビジネスロジック用にJavaでクライアントコードを簡単にデバッグできます。
GWTコンパイラーがクライアントのJavaコードをコンパイルし、そこからJavaScriptを生成します。サーバーにデプロイする必要があり、要求があったときにユーザーのブラウザで提供され実行されます。このJavaScriptの生成中に、いくつかの最適化が行われます。
JavaScriptの生成中にデッドコードを考慮しません。デッドコードと言うときは、「メインフローから呼び出されないが存在するコード」と言うことを意味します。その結果、最終的なJavaScriptコードの有効サイズが小さくなります。
生成されたJavaScriptコードの難読化を処理します。
生成されたJavaScriptコードの縮小を行います。
さらに重要なことは、ブラウザ固有の最適化コードを個別に生成することです。別に言うと、ブラウザ固有の個別のJavaScriptが生成され、特定のブラウザからそれぞれのリクエストを受信したときに提供されます。これにより、特定のブラウザにダウンロードされるJavaScriptコードのサイズが小さくなります。これは、1つのコードにすべてのブラウザ固有の処理が含まれていないためです。
GWTの国際化機能を使用して、英語、ヒンディー語、マラーティー語などの異なる言語のアプリケーションを作成している場合。JavaScriptコードの生成中に、言語とブラウザーの組み合わせごとにコピーが作成されます。これにより、言語とブラウザの特定の組み合わせに対して生成されたJavaScriptコードが最適かつ小さいものになります。
Java GWTコードから呼び出すことができる直接JavaScriptを使用する必要がある場合は、JSNI（JavaScript Native Interface）を使用して実行できます。JavaSctiptからGWT Javaコードを呼び出すこともできます。
ブックマーク可能なページを作成する場合は、GWTの履歴機能を使用できます。
通信および操作のデータ形式としてJSONを使用する場合、JavaScriptオーバーレイタイプと呼ばれる非常に優れた機能があります。
GWTの遅延バインディング機能は、Javaのために提供できると思われる優れた機能です。
Java SwingスタイルのGWTの利用可能なウィジェットを使用して、ユーザーインターフェイスを構築できます。カスタムウィジェットを非常に簡単に作成することもできます。
ユーザーインターフェイス（Webページ）を純粋なhtmlスタイルで構築する場合は、GWTの宣言的UI機能を使用できます。GWTの大きな特徴の1つだと思います。これにより、開発者は純粋なHTMLスタイルでページを簡単に作成できます。私が思うに、これはSwingスタイルのコーディングよりも保守しやすいでしょう。そして最も重要なことは、ロジックをJavaで保持し、プレゼンテーション部分のみを純粋なHTMLで保持できることです。（注：使用するメソッド（宣言型UIまたはSwingスタイル）は、最終的にはHTMLのみになりますが、違いを生じるのは、コーディングと保守の方法です）。
GWTのクライアントバンドル機能を使用すると、CSS、画像、その他のテキストコンテンツなど、他のWebリソースを非常に簡単に管理できます。
セルウィジェット：ページ分割されたデータコレクションを表示するために、GWTにはセルウィジェットがあります。CellTable、CellList、CellTree、CellBrowserなどのウィジェットがあります。
GWTクライアントコードからサーバーとの通信。クライアントサーバー通信を実装する複数の方法をサポートします。
データ転送に使用されているプロトコルに関心がない場合は、GWT RPCメカニズムです。サーバーとのデータ転送のためにクライアント側のコードを非常に簡単に統合できます。サーバー側のコードでも使用できるクライアントコードでカスタムDTO（データ転送オブジェクト）を定義できます。サーバー側の実装は、パラメーターまたは戻り値として同じDTOを受け入れます。他のすべてはGWT RPCフレームワークによって処理されます。サーバー側コードから発生した例外をクライアント側コードで呼び出し側に伝播することもあります（クライアント側コードパッケージ内でそれらの例外クラスを定義する必要がある場合に提供されます。GWTRPCは、データ転送に独自のカスタムプロトコルでAJAX呼び出しを内部で使用します。
GWT RPCを使用したくない場合は、リクエストビルダーを使用してサーバーからデータを取得するサーバーAJAX呼び出しを行うことができます。実装もはるかに簡単です。また、興味深い機能であるRequest Factoryもあります。この機能を使用すると、クライアントコードから呼び出されるようにDAOまたはサービスレイヤーを公開できます。これを行うには、サービスおよびカスタムデータ型のインターフェイスのいくつかのセットを定義する必要があります。これらのインターフェイスを使用すると、クライアントコードからこれらのサービスにアクセスできます。これらのインターフェイスを生成するmavenプラグインを作成しました。必要な注釈を使用してDAOレイヤーに注釈を付ける場合は、https：//github.com/pandurangpatil/gwt-mvn-helperを参照してください）使用方法については、その中のmvn-helper-testモジュールを参照してください。Request Factoryは、サーバー上のJDOやJPAなどのORMレイヤーとの統合をよりターゲットにしています。クライアントコードから特定のエンティティでpersistを呼び出すサポートがあります。そして最も重要なのは、persistメソッドを呼び出して、変更（デルタ）のみを計算してサーバーに送信して保存することです。
クロスドメインJSONP呼び出しを行う場合、同じ参照を行うことができます。