純粋なJavaScriptフレームワークに対するGWTなどのツールの実証済みの利点は何ですか？

Question

GWTは、JavaコードとJavaランタイムのクラスライブラリのサブセットをJavaScriptコードに変換したものです。

JavaScriptツールキットと比較すると、GWTは本質的に、また使用法によって疎外に見え、単純なことでも非常に複雑になり、JavaScriptを直接使用することで得られる細かい制御の多くを奪ってしまいます。

純粋なJavaScriptとJavaScriptフレームワークおよびツールキットを使用する代わりに、Web開発者がGWTのようなツールを使用することを選択したのはなぜですか？

それは測定可能なほど良く、どのような基準に基づいていますか？

haylem · Answer

含まれている電池

Javaのツール

それはただ素晴らしいです：

IDEs：一部のIDEがJavaScriptをサポートしていても、サポートのレベルは比較されません。大きなコードベース（たとえば、40K以上のLOC）でJavaScriptコードをリファクタリングして、泣いてみてください。
Unit-Testing：これは過去数年で採用されていますが、Javaの世界では、さらに成熟しています。
継続的インテグレーションおよび継続的インスペクション
Documentation Generation：もちろん、JSDocと他のいくつかのドキュメントがあります。

静的型付け

バグを早期にキャッチします。（Google Closureは、必要に応じて、開発者をJavaScriptの世界に留めながら少し対処しています）。

最適化されたJavaScript

GWTはより高速でコンパクトなJavaScriptを記述し（大規模なアプリケーションの場合）、同等の完全なJSソリューションを使用するよりも間違いなくクライアントに送信されるものを決定できます。

建築

大規模なアプリケーションの問題を適切に分離し、まともなMVCまたはMVPアーキテクチャがすでに指先でプリベークされています。

まともな図書館

GWTは興味深いライブラリーを提供し、動的なバンドル・ロードを使用してI18N対応のアプリケーションを簡単に（しかも簡単に）作成できるようにします。

ユニットテスト

Eclipse内からJUnitを使用するIDEおよびコマンドラインから。これは私の最初のポイントに関連します。GWTプロジェクトでJavaのコード品質ツールのいくつかを使用することもできます（ソースチェック用に、バイトコードチェックがないため、チェックされません）。

それはあなたのすべてです!!

GWTは万人向けではありません。これにより、一部の人々の生産性が向上し、JS以外の開発者がJavaScriptに（あまり）触れずに動的なフロントエンドを備えたプロフェッショナルなWebアプリを構築するための優れたツールが提供されます。それでもうまくいかない場合は、他のものを使用してください。

上記のほとんどが必要で、Javaが不要な場合は、 Google Closure または Dojo Toolkit を参照してください。

当時は良いアイデアでした：歴史が重要です!!

JavaScriptの世界（およびWebフロントエンドテクノロジー全般）は最近非常に活発になっているため、状況は改善されています。しかし、ほんの数年前、物事はそれほど明るくありませんでした。 LESS/SASSはそれほど人気がなく、jQueryはまだデファクトリーJSライブラリではありませんでした。JavaScriptライブラリは隔週で生成されておらず、ツールは一般的にそれほど優れていませんでした。

しかし、動的なフロントエンドを備えたプロフェッショナルで大規模なWebアプリケーションに対する需要がすでに高まっているため、開発者の生産性を高めるために埋めるギャップがありました。 JavaScriptには、知っておく必要のある多くの落とし穴と奇妙な点があり、おそらくそれらについて気にする必要さえない方が良いでしょう。したがって、GWTのようなツールのニッチです。

それ以来、他のものが登場しました（CoffeeScriptが頭に浮かびます、Dartが進んでいますが、大規模なJavaScriptフレームワーク、Node.JSを使ったサーバーサイドJSの革命など、そしてすべてが「十分」なJavaScriptの強力な復活-クライアント側だけでなく、ビジネススタックの他の部分でも使用される周辺言語。

その他の注意事項

Firebugの使用に関する元の（編集済み）質問について

もちろんFirebugを使用してGWTコードをデバッグできますが、理想的には、Eclipse IDEのデバッガーから直接デバッグし、ライブコードデバッグサポートを提供します。

ただし、Firebugは引き続き使用できますが、GWTは最適化および圧縮されたJavaScriptを生成するため、そのままでは簡単にデバッグできない場合があることに注意してください。

CSSについての元の（編集済みの）質問について

はい、もちろんCSSコードを自分で書く必要があります。ただし、GWTプロジェクトを他のツール（SASSなど）と簡単に組み合わせることができます。

それは単なるツールです！

Javaクライアント側で直接実行するコードをJavaバイトコードとして記述します。コードを記述しないでください。GWTを間違えないでください。 in Java言語、これは効率のためにJavaScriptに翻訳され、より高水準の言語を使用できるようにします（または、少なくともそれが意図されている方法です）見られる）。

間違いなく、JavaおよびJavaScriptは、抽象化レベルの点で同等と見なすことができます。ただし、Javaにはいくつかの利点があります（詳細上記）、したがって、既存のツールの利点を、それらを書き直す必要なしに享受できるという利点があります。Googleの開発者は、既存のJava指向のツールを再利用できるようにするだけでなく、実際にはJavaScriptアプリケーションを開発できるという賢いアイデアを思いついただけです。

さらに、JavaScriptとJavaコードが別々に処理された、しばしば煩雑な管理された2言語Webアプリケーションでした。別の問題も解決します。GWTの使用により、ある程度の収束が可能になります。開発プロセスの両面で。

参考文献：

GWTについてどう思いますか？
JavaScriptスタックについては、 JavaScript/CSS/HTMLフレームワークの組み合わせを参照してください。

Zsolt Sky · Answer

GWTでのWebアプリケーションの開発に何年も費やした後、私の意見では、GWTには深刻な欠点があるため、強制されなければそれを再び使用することはないでしょう。

DOMツリー

JavaScriptのパフォーマンスは向上するかもしれませんが、レンダリングされたDOMツリーは、多くの場合、不必要に複雑です。たとえば、ツリーの実装では、個々のアイテムごとに<table>を含む13以上のDOM要素を使用します。大きなツリー（約10000アイテム）を使用すると、ブラウザがフリーズするだけです。純粋なJavaScript/HTML/CSSツリーは、同じ量のアイテムを簡単に処理できました。

開発

純粋なJavaScript/HTML/CSSソースの変更-試行サイクルを打ち負かすことはできません。ソースファイルを保存して、ブラウザでページを更新するだけです。これは生産性の重要な要素であり、GWTはコードサーバーを使用しても競争できません。

JavaScriptのデバッグは、ChromeまたはFirebugのデバッガーを使用すると、絶対に簡単で楽しいです。

ハンマーエキスパート

Javaをすべてに使用するという考えは、「ハンマーのエキスパート」である開発者向けです。彼らはハンマーの達人なので、すべてが釘です。このアプローチは非常に間違っていると思います。GWTを使用する場合にも、 CSSとHTMLの知識。このGWTがなければ、開発者はほとんど解決できない問題にぶつかりますが、HTML/CSSの経験がある人はソリューションを考え出すことができます。開発者がこの能力を必要とする場合、開発を容易にすることができます。 HTML。

純粋なJavaScript/HTML/CSSで開発する場合に比べて、デメリットははるかに深刻ですが、GWTによって提供されるメリットのほとんどは疑わしいと私は考えています。

Pandurang Patil · Answer

私が考える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の使用可能なウィジェットを使用してユーザーインターフェイスを構築できます。カスタムウィジェットを非常に簡単に作成することもできます。
純粋なHTMLスタイルでユーザーインターフェイス（Webページ）を構築する場合は、GWTの宣言型UI機能を利用できます。 GWTの大きな特徴の1つだと思います。これにより、開発者は純粋なHTMLスタイルでページを簡単に作成できます。 Swingスタイルのコーディングよりも保守しやすいと思います。そして最も重要なのは、ロジックをJavaにそのままにして、純粋なHTMLのプレゼンテーション部分のみにすることです。（注：どちらのメソッド（宣言型UIまたはSwingスタイル）を使用しても、最終的にはHTMLのみになりますが、違いは、コーディング方法と維持方法です）。
GWTのクライアントバンドル機能を使用すると、CSS、画像、その他のテキストコンテンツなど、他のWebリソースを非常に簡単に管理できます。
- CSSリソースを使用すると、CSS内に条件付きロジックを含めることができます。 GWTクライアント側のJavaコードから動的な値にアクセスすることもできます。
- また、CSSクラスの難読化も処理します。そして最も重要なのは、GWTがcssクラスから使用するためのcssファイルからのインターフェースの自動生成を備えていることです。
- 画像リソースを使用すると、開発者はアプリケーションで画像を非常に簡単に保守可能な方法で簡単に使用できます。簡単に言うと、ハードコードされたURLを使用するのではなく、GWT Javaコードで画像を使用したい場合は、画像リソースを使用できます。画像リソースを使用すると、場所を変更したり、別の名前の別の画像を使用したりする場合に、1つの場所で変更するだけで済みます。画像リソースのより重要な機能は、CSSリソースをSpriteとして使用する場合です。その画像をインラインデータuriとして作成するか、Spriteで使用します。他のフレームワークでそれを行うことができないとは言いませんが、より重要なことは、どれほど速く簡単にそれを行うことができるかです。 GWTを使用すると、はるかに簡単になります。
- データリソースは、.pdfなどのデータファイルの最適化を追加して、コンテンツに基づいてファイルの名前を変更し、ブラウザで強力にキャッシュできるようにします。小さなデータファイルは、インラインデータURIに変換される場合があります。
- 他のWebリソースにクライアントバンドルを利用し、アプリケーションを適切に構造化して別のモジュールにする。すべてのリソースで、全体として完全に再利用可能なモジュールになる可能性があります。再利用可能なモジュールの重要な点は何ですか？一部のモジュールで直接URLを使用して画像を使用している場合も同様です。また、そのモジュールを他のモジュールに含め、そのモジュールで作成されたコンポーネントを使用しようとする場合でも、それらの画像を最終的なアプリケーションのパブリックURLにコピーする必要があります。これらの画像を画像リソースとして使用する場合、これを行う必要はありません。
- CSSとイメージのクライアントバンドルを使用して小さなモジュールを作成することで達成できるその他の最適化。最終モジュール内に必要なモジュールのみを含めることを選択できる場所。モジュールの小さな部分を使用したい場合でも、最終的なモジュールJavaScriptと他のリソースには必要なコンテンツのみが含まれ、コンテンツ全体は含まれません。
セルウィジェット：ページ分割されたデータコレクションを表示するために、GWTにはセルウィジェットがあります。 CellTable、CellList、CellTree、CellBrowserなどのウィジェットがあります。
- CellTableは、ページ分割された表形式でデータを表示するためのものであり、所定のセルの内容を適切に変更できる機能があります。クライアント側とサーバー側の両方でページ分割をサポートし、列でのソートをサポートし、1つまたは複数のレコードの選択と同じレコードのイベントの生成もサポートします。
- CellListを使用してデータをリスト形式で表示し、アイテムをカスタム形式で表示できます。また、クライアント側とサーバー側のページ付けと1つまたは複数のレコードの選択をサポートし、選択用のイベントを生成します。 CellTreeとCellBrowserを使用して、データをツリー形式で表示できます。
GWTクライアントコードからサーバーとの通信。クライアントサーバー通信を実装する複数の方法をサポートしています。
- データ転送に使用されているプロトコルに関心がない場合は、GWT RPCメカニズムです。データ転送用のクライアント側コードをサーバーと統合するのは非常に簡単です。サーバー側のコードでも使用できるクライアントコードでカスタムDTO（データ転送オブジェクト）を定義できます。サーバー側の実装は、同じDTOをパラメーターまたは戻り値として受け入れます。それ以外はすべて、GWT RPCフレームワークによって処理されます。サーバー側コードから発生した例外をクライアント側コードの呼び出し元に伝播します（クライアント側コードパッケージ内でこれらの例外クラスを定義する必要がある場合、GWT RPCは独自のカスタムプロトコルで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呼び出しを行う場合は、同じ参照を行うことができます。

ZJR · Answer

それは測定可能なほど良くはありません。
日常の使用については、 jQuery 、 AmpleSDK 、または some html5 polyfill を検討してください。

GWTには多くのオーバーヘッドがあります。実際のおよび概念的なものです。

Javaアプリまたは一部のサーバー側JavaコードをportWebフロントエンドへ。