最大のGWT落とし穴？
私はGWTを使用して実装することを選択したプロジェクトの最初/中間にいます。 GWT（およびGWT-EXT）を使用する際に克服できない大きな落とし穴に遭遇した人はいますか？パフォーマンスの観点からはどうですか？
私たちが見た/聞いたことがいくつかあります：
- Googleがコンテンツのインデックスを作成できない
- CSSとスタイリングは一般的に少し不安定です
これらのアイテムに関する追加のフィードバックも探しています。ありがとう！
私はGWTの大ファンだと言って始めますが、はい、多くの落とし穴がありますが、ほとんどの場合は克服できました：
問題：プロジェクトが大きくなるとコンパイルに時間がかかり、コンパイル時間が長くなります。 20分のコンパイルのレポートを聞いたことがありますが、私の場合は平均で約1分です。
解決策：コードを個別のモジュールに分割し、変更された場合のみビルドするようにantに指示します。また、開発中に、1つのブラウザ用にビルドするだけでコンパイル時間を大幅に短縮できます。これを行うには、これを.gwt.xmlファイルに追加します。
<set-property name="user.agent" value="gecko1_8" />
Gecko1_8はFirefox 2 +、ie6はIEなどです。
問題：ホストモードは非常に遅く（少なくともOS Xで）、編集時に取得する「ライブ」変更に一致しませんJSPやRailsページのように、ブラウザで更新をクリックします。
解決策：ホストモードにもっと多くのメモリを与えることができます（一般的に512M用です）が、それでもまだ遅いです。 GWTの使用を停止します。大きな変更を加え、1つのブラウザー（通常は20倍のコンパイル）でコンパイルしてから、ブラウザーで更新をクリックします。
更新：GWT 2.0以降では、新しい「開発モード」を使用するため、これはもはや問題ではありません。基本的には、選択したブラウザでコードを直接実行できるため、速度を落とすことなく、firebug/inspectなどを実行できます。
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
問題：GWTコードはJavaであり、HTMLページのレイアウトとは異なる考え方を持っているため、HTMLデザインを取得してGWTに変換することが難しくなります。
解決策：繰り返しますが、残念ながらHTMLデザインをGWTデザインに変換することは、HTMLを変換するようなことを行うよりも常に遅くなりますJSPページへの設計。
問題：GWTは少し頭を悩ませていますが、まだ主流ではありません。つまり、チームに参加したりコードを保守したりするほとんどの開発者は、ゼロから学習する必要があります
解決策：GWTが離陸するかどうかはまだ不明ですが、雇用者を管理している会社の場合は、いつでも選択できますGWTを知っているか、それを学びたい人。
問題：GWTは、jqueryや単なるjavascriptのようなものと比較して、大ハンマーです。 JSファイルを含めるだけでなく、それを実現するには多くのセットアップが必要です。
解決策：jqueryのようなライブラリを使用して、それらに適したより小さく単純なタスクを実行します。 AJAXで本当に複雑なものを構築する場合、またはRPCメカニズムを介してデータをやり取りする必要がある場合は、GWTを使用します。
問題：GWTページを読み込むために、ページが最初にロードされたときにサーバー呼び出しを行う必要がある場合があります。ユーザーがそこに座って、必要なデータをフェッチしている間、読み込み中のシンボルを見るのは面倒です。
解決策：JSPページの場合、ページはHTMLになる前にサーバーによって既にレンダリングされているため、実際にすべてのGWT呼び出しを行うことができます、ページにプリロードして、すぐにロードできるようにします。詳細はこちらをご覧ください：
GWT呼び出しを事前にシリアル化してページの読み込みを高速化
カスタム、またはその他の方法で、ウィジェットのCSSスタイル設定に問題が発生したことは一度もないので、落とし穴であることの意味がわかりませんか？
パフォーマンスに関しては、コンパイルされたGWTコードは高速であり、AJAX呼び出しはページ全体の更新を行うよりもほとんど常に小さくなりますが、それはGWTに固有のものではありませんが、 Javaバックエンドを使用すると得られるネイティブRPCパケットは非常にコンパクトです。
私たちはほぼ2年間gwtを使用しています。私たちは多くの教訓を学びました。これが私たちの考えです：
サードパーティのウィジェットライブラリ、特にgwt-extを使用しないでください。デバッグ、開発、実行時のパフォーマンスが低下します。これがどのように発生するかについて質問がある場合は、直接私に連絡してください。
Gwtを使用して、アプリの動的な部分のみを入力します。そのため、多くのフィールドとの複雑なユーザーインタラクションがある場合。ただし、付属のパネルは使用しないでください。既存のストックデザイナーが提供するページを使用します。アプリのコントロールを含む領域を切り分けます。これらのコントロールをonModuleLoad（）内のページに添付します。このようにして、デザイナーの標準ページを使用し、gwt以外のすべてのスタイル設定を行うことができます。
アプリ全体を1つの標準ページとしてビルドしないでください。その後、すべての要素が動的にビルドされます。項目2で提案したことを行うと、これはとにかく起こりません。すべてを動的に構築すると、パフォーマンスが低下し、中規模から大規模のアプリで大量のメモリが消費されます。また、あなたが私が提案していることをすれば、戻るボタンはうまく機能するので、検索エンジンのインデックス作成などもできます。
他のコメント者にもいくつかの良い提案がありました。私が使用する経験則は、標準のWebページを作成しているようなページを作成することです。次に、動的にする必要がある部分を切り分けます。それらをidを持つ要素で置き換え、RootPanel.get( id ).add( widget )を使用してそれらの領域を埋めます。
私たちが遭遇した落とし穴：
GWT EXTのようなものを使用することで多くのマイレージを得ることができますが、JavaScriptライブラリの上でこの種の薄いベニアを使用すると、デバッグする能力が失われます。 GWT EXTテーブルクラスで何が起こっているかを（IntelliJデバッガー内で）検査できないため、何度も頭を机の上で打ちました。これにより、何が間違っているのかを把握することが非常に難しくなります...
チームにCSSを知っている人がいないこと。私の経験から、その人が専門家でなくても問題ありませんでした...彼はある程度の実用的な知識を持ち、必要なときにグーグルに適切な用語を知っていれば十分です。
ブラウザー間でのデバッグ。 Out of Process Hosted Modeに注意してください[ 1 ] [ 2 ] []、できればGWT 1.6で... 、ホストモードで問題を解決し、他のブラウザで再生できる[コンパイル/参照]ボタンを使用するだけです。私にとって、Windowsで作業しているということは、FireFoxで自分の作業を表示し、FireBugを使用してTweakを助けて物事を改善できることを意味します。
IE6。 IE 6がどのようにレンダリングするかは驚くべきことです。ブラウザに応じてスタイルを最も外側の「ビューポート」に適用して、CSSルールを次のようにすることができます。
.my-style { /* stuff that works most everywhere */ } .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
最後に、役立つエディターを使用してください。私はIntelliJを使用しています-GWTスマートがたくさんあります。たとえば、JREエミュレーションで処理されないクラスを使用しようとすると、通知されます。ウィジェットのスタイルを指定し、まだそのスタイルを定義していない場合、コードは少し赤い波線を取得します...または、CSSを見ると、競合する属性を指定したときに通知されます単一のルール。 （私はまだ試していませんが、バージョン8には、「ローカル」および「非同期」RPCインターフェイスと実装の同期を維持するなど、GWTのサポートがさらに優れていることがわかります。
GWT 2.0は、今後数か月のうちにリリースされる予定であり、議論されている多くの問題を解決します。
- Html/xmlのような構文を使用してレイアウトを作成する
- 動的なスクリプトの読み込み-必須のJSのみが最初にダウンロードされます。残りは必要に応じてダウンロードされます
- In-Browser Hosted Mode-これは、他の利点の中でも特に、説明されているホストモードの速度の問題を処理する可能性があります。
- 「コンパイラの最適化」-コンパイルの高速化、できれば
「克服することはできません」ではなく、基本的なものに対する少しの痛み。
日付処理：
GWTは非推奨のJava.util.Dateを使用するため、クライアント側で日付を処理するときに予期しない動作が発生する可能性があります。 Java.util.CalendarはGWTでサポートされていません。 詳細はこちら 。
関連する問題の例：
既に述べたものにいくつかのポイントを追加します。
- データバインディング/検証。 GWTには、すぐに使用できるデータバインディング/検証のサポートはありませんが、この領域にはいくつかのプロジェクトが出現し始めています。これをたくさん書いていることに気づくでしょう：
TextField fname、faddress; ... fname.setText（person.getName（））; faddress.setText（person.getAddress（））; ...
- 遅延読み込み。 gwtはクライアント側にあるため、遅延読み込みは実際にはオプションではありません。 を行うには、RPCとドメインオブジェクトを慎重に設計する必要があります。
- 必要なすべてのオブジェクトデータを送信する
- すべてのデータを積極的に取得しないでください
- また、プロキシ/非シリアル化オブジェクトを送信しないことを確認する必要があります。 hibernate4gwt は、これらの点で役立ちます。
- UIデザイン。 Java（パネル、ボタンなど）でUIを視覚化するのは、htmlよりも難しいです。
- 履歴サポート。 GWTにはHistoryサブシステムは付属していません。また、Nice URLやステートフルブックマーク用のサブシステムも付属していません。独自にロールする必要があります（ただし、開始点であるヒストリトークンをサポートしています）。これはすべてのAJAX toolkits AFAIKで発生します。
私見、GWTには、この「スレッド」で言及されているすべての問題をすぐにサポートできるフレームワークがありません。
私は現在、GWT EXTと混同しないようにEXT GWT（GXT）を使用するプロジェクトに取り組んでいます。違いがあります。EXTGWTは、ExtJSにjavascriptライブラリを作成した会社によって実際に作成されたものです。 GWT EXTは、ExtJSライブラリのGWTラッパーです。 GXTはネイティブGWTです。
とにかく、GXTはいまだに未熟であり、GWT EXTが持っていると感じる堅実なコミュニティを欠いています。ただし、GXTはネイティブGWTであり、実際にExtJSを作成した会社によって開発されているため、GXTの将来はそうです。 GWT EXTは、ExtJSライブラリのライセンスが変更され、GWT EXTの開発が遅くなるため、多少不自由になります。
全体として、GWT/GXTはWebアプリケーションを開発するための優れたソリューションだと思います。私は実際、開発用のホストモードが非常に好きです。また、コードをデバッグできるという利点もあります。 JUnitを使用した単体テストも非常に安定しています。エンタープライズアプリケーションをテストするのに十分成熟していると感じた優れたJavaScriptユニットテストフレームワークはまだ見ていません。
GWT EXTの詳細： http://gwt-ext.com/
EXT GWT（GXT）の詳細： http://extjs.com/products/gxt/
簡単に克服できなかった大きな落とし穴はありません。ホストモードを多用します。 GWT-extを使用しているため、すぐに使用できる外観を微調整する場合を除き、CSSに触れる必要はほとんどありません。
私の推奨事項は、機能が近いライブラリのGWT「ネイティブ」ウィジェットを使用することです。
再検索エンジンのインデックス作成：はい、通常のWebサイトの要素にウィジェットを追加するだけでない限り、サイトには通常、ナビゲート可能なURLがありません。ただし、履歴の戻る/進む機能を実行できます。
GWTは非常に簡単で直感的です。
特に、UIBinderのリリースにより、GWTウィジェットをXMLでレイアウトし、Javaでコードビハインドできるようになりました。
そのため、他のAjaxまたはFlashデザインツール、またはSilverlightなどを使用したことがある場合、GWTの学習は非常に簡単です。
落とし穴ではないにしても、大きなハードルはGWT RPCです。 GWTを使用するまさにその理由は、GWT非同期RPCのためです。それ以外の場合は、CSSだけでページをフォーマットしないでください。
GWT RPCは、ページを更新することなくサーバーがサーバー上のデータを更新できるようにする要素です。これは、株価パフォーマンスモニタリング（または現在の米国の国家および公的債務、または2番目までに世界中で流産した胎児の数）などのページの絶対要件です。
GWT RPCを理解するには多少の努力が必要ですが、数時間を考えると、すべてが明らかになるはずです。
その上、GWT RPCを学習するための努力を行った後、次の場合を除き、RPCのサービスコンポーネントとしてJSPを使用できないことが最終的にわかります。 GWT RPCサービサーとして。しかし、あなたは答えを求めたのではなく、単に問題を求めていたので、私のブログを宣伝することはやめましょう。
そう。 GWTを使用する上での最悪の障害/落とし穴は、GWT非同期RPCを適切にデプロイする方法と、JSPサービサーを使用できるようにする方法を見つけることだと非常に信じています。
トピックは少し異なりますが、ircの#gwtチャンネルは、永続的な問題がある場合に非常に役立ちます。
Ykaganoからのコメントの2番目、最大の欠点はMVCでVを失うことです。真のuiクラスを他のクライアント側コードから分離できますが、グラフィック/ Webデザイナーによって生成されたHTMLページを簡単に使用することはできません。つまり、HTMLをJavaに翻訳する開発者が必要です。
Wysiwyg uiエディターを入手すると、時間を大幅に節約できます。 GWTDesignerを使用します。
GWTの最大の利点は、クロスブラウザーの問題を忘れることができることです。 100％ではありませんが、ほとんどすべての痛みを取り除きます。ホストモードデバッグの利点（優れているがJavaデバッガーと同じではない）Firebugとは対照的に）は、開発者に複雑なAjaxアプリを生成する際の大きな利点を提供します。
特にgzipフィルターを使用する場合は、実行時に高速になります。
少し前にプロジェクトでGWTとGWT-extを一緒に使用しました。 Web開発が進むにつれて、この経験は非常にスムーズになりましたが、私のアドバイスは次のとおりです。
GWTネイティブウィジェットとEXTウィジェットを混在させないでください。通常、名前は同じなので（GWT.ButtonまたはGWText.Button？）
私が思いついたよりもコードを実際に複雑にした私に起こった1つのことは、a）動的に更新可能なb）カスケード可能なPanelが欲しかったということです
GWTネイティブパネルは動的で、Extパネルはカスケード可能です。溶液？ GWTExtパネルをラップするGWT.VerticalPanel ...カオス。 :)
しかし、ちょっと、それは動作します。 ;）
GWT 2.4は前述の問題の多くを修正し、優れたウィジェットライブラリがベータ版（Ext GWT 3.0.4 a.k.a. GXT）から登場しました。これは、JSライブラリのラッパーではなくGWTで完全に記述されています。
残りの痛み：
- CSS3セレクターのサポートがないため、場合によっては「literal（）」を使用して回避できます。
- CSS3およびtransitionEndなどの最新のブラウザーイベントのサポートの欠如。
- Java Calendarクラスのサポートの欠如（多くの年後）。
- JUnit4サポートの欠如（5年以上）。
- Google GWTチームからの明確なロードマップとリリーススケジュールの欠如。
- 各サービスインターフェイス用に記述する必要がある非同期インターフェイスは、GWTコンパイラによって自動的に生成されたもののように見えます。
- 大規模プロジェクトではコンパイル時間が長くなります
しかし、大規模なJavascriptプロジェクトの場合、これが最良の選択です
GWTコードベースと、Webデザイナーから取得したHTML Webテンプレート（GWTで管理したい特定のdiv IDを持つ静的HTMLページ）を組み合わせるのは非常に困難でした。少なくともそれを使用したときは、GWTをWebサイトのGWTでコーディングされていない部分と統合することはできませんでした。最終的には機能しましたが、大きなハックでした。
GWT 2.4については、GWTのデバッグ時にFirefoxを使用してください。クロムを使用するよりも高速です。また、Firefoxのみを使用する場合は、この行をproject.gwt.xmlファイルに入れることを検討してください
<set-property name="user.agent" value="gecko1_8" />
また、Eclipseを使用している場合は、引数の下に以下を追加します-> VM arguments：
-Xmx512m -XX：MaxPermSize = 1024m -XX：PermSize = 1024m
サーバーとクライアントを分割し、引数->プログラム引数で以下を使用できます：-codeServerPort 9997 -startupUrl http：// yourserver/project -noserver
また、変更ごとにサーバーが更新されないようにするには、JRebelを使用します http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ そして、これがライブデモです http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
GWTは機能検出の代わりにブラウザスニッフィングを実行し、アプリケーションは一部のブラウザ（特に新しいブラウザ）で動作しません
問題の参照先を次に示します。
- google-web-toolkit問題2938：RFE：user.agentプロパティプロバイダーを改善して、userAgent文字列「マスキング」に対処する
- Iceweaselはサポートされなくなりましたか？-Googleドキュメントヘルプ
- すべてのブラウザのGWT実装
機能検出への参照は次のとおりです。
私は最近GWTで多くの仕事をしましたが、これは私が言わなければならないことです：
- CSSのスタイリングは時々注意が必要です。IEの開発者ツールを使用して、IEとFirefoxのfirebugで正確に何が起こっているのかを把握すると、変更する必要があるcss
- トリックを使用して、Googleにインデックスを作成させることができます。非常に有名なサイトは http://examples.roughian.com/ googleで評価をチェックしてください。あまり有名ではないサイトは www.salvin.in （それについて言及するのを拒むことはできません）、私はそれを言葉に最適化しました：salvinホームページ（これらの3つの言葉をgoogleで検索してください）
私はGWT-EXTについてあまり知りませんが、私もサードパーティのライブラリを含める必要はないと信じています。
あなたの決定の幸運:)
信頼できる事実を取得する最良の方法は、 gwt survey からです。 GWTの最大の問題の1つは、常に長いコンパイル時間でした。幸いなことに、それは非常に迅速に改善されているため、近い将来に大きな問題になることはありません。別の落とし穴は、GWTが劇的に複雑になることです。Javaは、すべての段階で悪いコーダーに抵抗するより複雑な言語です。さらに、コンパイルはレイヤーを追加します。たとえば、js interopは基本的な問題は、GWTが単純に設計されていないことです。非常に複雑なWebアプリ向けにゼロから設計されており、コミュニティ全体がコーディングしやすいよりも一貫して優先順位付け、パフォーマンス、コード品質、アーキテクチャなどを優先しています。
いつでもGWTでjsを使用できるため、GWTで苦労している場合はjsの使用を検討してください。結局のところ、GWTはjsなので、jsでできることはGWTで何でもできます。実際、ほとんどのGWTプロジェクトはjsを使用しています。問題は、GWTが大幅に複雑になることです。それにもかかわらず、それは時々余分な複雑さの価値があります。
GWT 3.0が大幅な改善をもたらすことは注目に値します。
GWTチームは、昨年のGWT 2.7のリリースで多くの大きな改善を行いました。 GWTの大きな弱点の1つは、GWT 2.6以前ではコンパイルに時間がかかることでした。これはなくなりました。GWTにはインクリメンタルコンパイルがありません。インクリメンタルコンパイルは非常に高速で、変更のみをコンパイルします。
GWT 2.7は（ Source ）になりました：
- インクリメンタルビルドがわずか数秒になりました
- よりコンパクトで正確なSourceMap
- GSSサポート
- JSInterop
- 優れたJavaScriptパフォーマンス
- より小さなコードサイズ
1つの大きな落とし穴は、特定のCSSスタイルを使用できるようにするために、最終的にHTML要素になるものにidを明示的に割り当てる必要がある場合があることです。たとえば、GWT TabPanelは、tabPanelのtabBarにidが割り当てられ、そのelementIdで：hoverを指定した場合にのみtabBarItemsで：hoverを実行します。
私は他のいくつかについて書きました GWTの欠点 他の場所で、しかしそれらは既にrustyshelfsの回答でカバーされています:)。
RPCサービスオブジェクトを再利用します。
アプリがハングしているように見える症状を伴う競合状態を引き起こします。
落とし穴1に遭遇しました。superdevモードでの動作が異なります。例えば。 Someclass.class.getName（）は、Superdevモードで完全に機能し、クラスの完全修飾名を返します。本稼働モードでは、これは機能しません。
- addWidget（widget）は、ウィジェットのremovefromparent（）を呼び出します
GWTはテクノロジーの傑作です。クライアントとサーバーのプログラミングを結合して、1つの一貫したアプリケーションにします。「階層化」前のソフトウェアの記述方法と、その記述方法です。さまざまなスキルセット、チームメンバー間のコミュニケーションの誤り、および一般的にWebデザインフェーズ全体（芸術とプログラミングの両方）を排除します。そして、モバイルに最も近い場所です。 Android開発。実際、GWTはHTMLだけでなく、さまざまなネイティブUIを生成するように設計されました。このような分離を保証するには膨大な訓練が必要ですが、内部レイヤーをプレゼンテーションに依存しません。
避けるべき最初の間違いは、私が気付くまでに4年かかりましたが、EXT-GWT別名GXTやSmartGWTなどのサードパーティの拡張機能を使用することです。自分のスタイリングに投資する代わりに、かなりデスクトップ風のウィジェットを使い始めるのはとても魅力的ですが、ついにうんざりするまでSmartGWTでどれだけ多くの問題を抱えていたかはわかりません。要するに、特定の（かなり時代遅れの）レベルで設定されたコアGWT機能をフリーズし、その上にビルドします。また、特にモバイルデバイスでは、パフォーマンスの低下、多くのバグ、互換性機能は言うまでもなく、最近のデスクトップルックアンドフィールは愚かに見えることにも留意してください。可能な限りネイティブブラウザーコントロール、つまりカスタムペイントされたコントロールではなく、ネイティブ<select>要素としてレンダリングされたドロップダウンにできるだけ近づけたいと思います。
モバイルトレンドのおかげで、UX全体がよりシンプルでフラットになっているため、シャープな外観のアプリケーションをスタイルするために多くのことをする必要はありません。 「3D」の外観が必要な場合でも、グラデーションがあります。 CSS3はすべてを簡単にし、GWTは生のCSSとは異なりエレガントなオブジェクト指向の方法でラップします。そのため、GWTショーケースのややugいベアボーンコントロールを見て気を落とさないでください。 GWTチームは、開発者の仕事であるため、意図的にスタイリングを提供しませんでした。
残りは強く型付けされたJavaの美しい簡潔なAPIによる従来のブラウザプログラミングです。しかし、もちろん、ブラウザ内でコードが実行されることを決して忘れないため、GWTを呼び出すことはできません。 -ループ内のRPCメソッド（リストを作成するため）。ただし、この状況に陥った場合、再帰的にチェーンする必要があります。
GWT-RPCを使用しないなど、自称「アンチパターン」がいくつかあります。私にとってこれまで良かったのは、10年間です。シンプルさが鍵です。コードの優雅さと保守性のために、わずかなパフォーマンスを犠牲にすることさえ、一瞬でもないと思います。それに加えて、これはあなたのボトルネックがある場所ではありません-データベース内。もちろん、クライアントに送信するデータの量に注意してください。
また、既存のガジェットの検索やスタイル設定ができない場合-リッチHTML5要素セットを読み取る場合は、サードパーティのガジェットをいつでもラップできます。人気のあるjQuery FullCalendarを使用して行いました。ロケット科学ではありません。 Google MapsやGoogle Chartsのような他のすべてには、半公式のGWTラッパーがあります。
GWTは完璧です。十分な愛情を得られない唯一の理由は、まだ業界に影響を与えている初期のインターネット採用者が、それらを評価するためのコンピューターサイエンスやオブジェクト指向言語から来ていないからです。芸術的背景（Photoshop/WordPress）またはネットワーク（Perl/Python）の背景があります。