最大の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や検査などができることを意味します。

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

問題： GWTコードはJavaであり、HTMLページのレイアウトとは異なる考え方を持っているため、HTMLデザインを取得してGWTに変換することが難しくなっています。

解決策：再びこれに慣れますが、残念ながらHTMLデザインをGWTデザインに変換する方が、HTMLデザインをJSPページに変換するよりも常に遅くなります。

問題： GWTは少し頭を悩ませ、まだ主流ではありません。つまり、チームに参加したり、コードを保守したりするほとんどの開発者は、ゼロから学習する必要があります。

解決策： GWTが成功するかどうかはまだ分からないが、あなたが雇う人を管理している会社であれば、いつでもGWTを知っているか、GWTを学びたい人を選ぶことができる。

問題： GWTは、jqueryや単なるjavascriptのようなものと比較すると、大槌です。JSファイルをインクルードするだけでは、それを実現するために多くの設定が必要です。

解決策： jqueryのようなライブラリを使用して、それらに適したより小さく単純なタスクを実行します。AWTで本当に複雑なものを構築する場合、またはRPCメカニズムを介してデータをやり取りする必要がある場合は、GWTを使用します。

問題： GWTページにデータを取り込むために、ページが最初にロードされたときにサーバー呼び出しを行う必要がある場合があります。必要なデータをフェッチしている間、ユーザーがそこに座って読み込みシンボルを見るのは面倒です。

解決策： JSPページの場合、ページはHTMLになる前にサーバーによって既にレンダリングされているため、実際にすべてのGWT呼び出しを行い、それらをページに事前にロードして、瞬時にロードすることができます。詳細はこちらをご覧ください：

GWT呼び出しを事前にシリアル化することにより、ページの読み込みを高速化します。

私はウィジェットをそのまま、カスタム、またはその他の方法でCSSスタイルに設定するのに問題がなかったので、それが落とし穴であることの意味がわかりませんか？

パフォーマンスについては、コンパイルされたGWTコードが高速であり、AJAX呼び出しはページ全体の更新を行うよりもほとんど常に小さいことを常に発見しましたが、これはGWTに固有のものではありませんが、使用する場合に得られるネイティブRPCパケットはJAVAバックエンドはかなりコンパクトです。

私たちはほぼ2年間gwtを使用しています。私たちは多くの教訓を学びました。これが私たちの考えです：

1. サードパーティのウィジェットライブラリ、特にgwt-extは使用しないでください。デバッグ、開発、実行時のパフォーマンスが低下します。これがどのように発生するかについて質問がある場合は、直接私に連絡してください。

2. アプリの動的な部分のみを入力するには、gwtを使用します。したがって、多くのフィールドを使用する複雑なユーザー操作がある場合。ただし、付属のパネルは使用しないでください。既存のストックデザイナーが提供するページをご覧ください。アプリのコントロールが含まれる領域を切り分けます。これらのコントロールをonModuleLoad（）内のページにアタッチします。このようにして、デザイナーの標準ページを使用し、gwtの外部ですべてのスタイリングを行うことができます。

3. アプリ全体を1つの標準ページとして作成しないでください。1つのページで動的にすべての要素が作成されます。項目2で提案したことを実行しても、これはとにかく起こりません。すべてを動的に構築すると、パフォーマンスが低下し、中規模から大規模なアプリでは大量のメモリが消費されます。また、私が提案していることを実行すると、[戻る]ボタンが適切に機能し、検索エンジンのインデックス作成などが可能になります。

他のコメンターもいくつかの良い提案をしました。私が使用する経験則は、標準のWebページを行っているようにページを作成することです。次に、動的である必要がある部分を切り分けます。それらをidを持つ要素で置き換え、次にRootPanel.get( id ).add( widget )それらの領域を埋めるために使用します。

私たちが遭遇した落とし穴：

• GWT EXTなどを使用することで多くのメリットを得ることができますが、この種の薄いベニアをJavaScriptライブラリーの上に使用すると、デバッグする能力が失われます。GWT EXTテーブルクラスで何が起こっているのか（IntelliJデバッガー内で）検査できないので、何度か頭を打ちました。JavaScriptObjectであることがわかります。これは何がうまくいかないのかを理解することを非常に困難にします...

• チームにCSSを知っている人はいません。私の経験から、その人が専門家でなくても問題ありません...彼はいくつかの優れた実用的な知識を持っていて、必要に応じてグーグルに適切な用語を知っているだけで十分です。

• ブラウザー間でのデバッグ。アウトプロセスホストモードに注意してください[ 1 ] [ 2 ] [ 3 ]に注意してください。うまくいけばGWT 1.6が登場します...とりあえず、ホストモードで優れた機能を実現し、[コンパイル/参照]ボタンを使用するだけです。 、他のブラウザで遊ぶことができます。Windowsで作業している私にとって、これはFireFoxで自分の作業を表示し、FireBugを使用して微調整と改善を行うことができることを意味します。

• 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を見ると、競合する属性を指定したときに通知されます単一のルール。（まだ試していませんが、「ローカル」と「非同期」のRPCインターフェースと実装の同期を維持するなど、バージョン8のGWTサポートがさらに優れていることを理解しています。）

GWT 2.0は、今後数か月のうちにリリースされる予定であり、議論された多くの問題を解決します。

• 構文のようなhtml / xmlを使用してレイアウトを作成する
• 動的スクリプトの読み込み-重要なJSのみが最初にダウンロードされます。残りは必要に応じてダウンロードされます
• ブラウザー内ホストモード-これは、他の利点の中でも、議論されたホストモードの速度の問題を処理する可能性があります。
• 「コンパイラの最適化」-より高速なコンパイル、うまくいけば

Google I / OでのGWT 2.0プレビュービデオ

「克服できない」ではなく、基本的なことには少し苦労します。

日付の取り扱い：

GWTは非推奨のjava.util.Dateものを使用しているため、クライアント側で日付を処理するときに予期しない動作を引き起こす可能性があります。java.util.CalendarGWTではサポートされていません。詳細はこちら。

関連する問題の例：

• GWT java.util.Dateシリアル化のバグ
• GWTで日付の詳細（日、月、年）を取得する
• GWTでのクライアント側のタイムゾーンのサポート

私はすでに述べたものにいくつかのポイントを追加します：

• データバインディング/検証。GWTには、すぐに使用できるデータバインディング/検証のサポートはありませんが、この領域にはいくつかのプロジェクトが登場し始めています。あなたはこれをたくさん書いていることに気づくでしょう：

TextField fname、faddress;
...
fname.setText（person.getName（））;
faddress.setText（person.getAddress（））;
...

• 遅延読み込み。gwtはクライアント側にあるため、遅延読み込みは実際にはオプションではありません。RPCとドメインオブジェクトを慎重に設計して、
  • 必要なすべてのオブジェクトデータを送信する
  • すべてのデータを熱心にフェッチしないでください
  • また、プロキシ/非シリアル化オブジェクトを送信しないようにする必要もあります。hibernate4gwtはこれらのポイントを支援します。
• UIデザイン。htmlよりもjava（パネル、ボタンなど）でUIを視覚化することは困難です。
• 歴史のサポート。GWTにはHistoryサブシステムは付属していません。また、素敵なURLやステートフルブックマーク用のサブシステムも付属していません。自分でロールバックする必要があります（ただし、これは履歴トークンをサポートしているためです）。これは、すべてのAJAXツールキットAFAIKで発生します。

私見、GWTには、この「スレッド」で言及されているすべての問題をすぐにサポートできるフレームワークがありません。

現在、GWT EXTと混同しないようにEXT GWT（GXT）を使用するプロジェクトに取り組んでいます。違いがあります。EXTGWTは、ExtJSにJavaScriptライブラリを作成した会社が実際に作成したものです。GWT EXTは、ExtJSライブラリのGWTラッパーです。GXTはネイティブGWTです。

とにかく、GXTはまだいくぶん未熟で、GWT EXTが持っていると私が思う強固なコミュニティーに欠けています。ただし、GXTはネイティブGWTであり、実際にはExtJSを作った会社によって開発されているため、将来はGXTにあります。ExtJSライブラリのライセンスが変更されたため、GWT EXTは多少不自由になり、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の「ネイティブ」ウィジェットを、機能が近いライブラリのウィジェットよりも使用することです。

検索エンジンのインデックス作成について：はい、サイトには通常、移動可能なURLはありません（通常のWebサイトの要素にウィジェットを追加するだけの場合を除きます）。ただし、履歴のバック/フォワード機能を実行できます。

先ほどのプロジェクトでGWTとGWT-extを一緒に使用しました。Web開発が進むにつれ、エクスペリエンスは非常にスムーズになりましたが、私のアドバイスは次のとおりです。

GWTネイティブウィジェットとEXTウィジェットを混在させないでください。通常は名前が同じであるため、地獄として混乱しています（GWT.ButtonまたはGWText.Button？）

コードを本当に複雑にした私に起こった1つのことは、a）動的に更新可能なb）カスケード可能なPanelが欲しかったことです

GWTネイティブパネルは動的で、Extパネルはカスケード可能です。解決？GWTExtパネルをラップするGWT.VerticalPanel ...カオス。:)

しかし、それは機能します。;）

ykaganoからのコメントの2番目に、最大の欠点はMVCでVを失うことです。真のUIクラスを残りのクライアント側コードから分離することはできますが、グラフィック/ Webデザイナーによって生成されたHTMLページを簡単に使用することはできません。つまり、HTMLをJavaに変換する開発者が必要です。

wysiwyg uiエディターを入手してください。時間を大幅に節約できます。私はGWTDesignerを使用しています。

GWTの最大の利点は、クロスブラウザーの問題を忘れることができることです。100％ではありませんが、ほとんどすべての痛みを取り除きます。ホストモードデバッグの利点（FirebugはJavaデバッガーとは異なりますが、同じではありません）と組み合わせると、複雑なajaxアプリを生成する上で大きな利点があります。

特にgzipフィルターを使用する場合は、実行時に高速です。

少しトピックから外れていますが、ircの#gwtチャネルは非常に役立ちます。

GWTは非常に単純で直感的です。

特に、UIBinderのリリースにより、GWTウィジェットをXMLでレイアウトし、Javaでコード化できるようになりました。

したがって、他のAjaxやFlashの設計ツール、またはSilverlightなどを使用したことがあれば、GWTは非常に簡単に習得できます。

落とし穴ではないとしても、主要なハードルはGWT RPCです。GWTを使用する理由は、GWT非同期RPCが原因です。そうでなければ、なぜあなたのページをフォーマットするために単にCSSに依存しないのですか？

GWT RPCは、サーバーがページを更新せずにサーバー上のデータを更新できるようにする要素です。これは、株のパフォーマンスの監視（または現在の米国の国債と米国の公的債務、または2番目までに世界中で中絶された胎児の数）などのページの絶対的な要件です。

GWT RPCは理解するのにいくらかの努力を要しますが、数時間与えられれば、それはすべて明らかになるはずです。

その上で、GWT RPCを学ぶために少し努力した後、JSPの使用方法に関するブログに8部（私は思う）シリーズがない限り、RPCのサービスコンポーネントとしてJSPを使用できないことが最終的にわかります。 GWT RPCサービサーとして。しかし、あなたが答えを求めたのではなく問題だけを求めたので、私は私のブログを宣伝しないようにします。

そう。GWTを使用する際の最悪の障害/落とし穴は、GWT非同期RPCを適切にデプロイする方法と、JSPサービサーを使用できるようにする方法を見つけることだと私は非常に信じています。

私たちは、GWTコードベースと、Webデザイナーから取得したHTML Webテンプレート（GWTで管理したい特定のdiv IDを持つ静的HTMLページ）を組み合わせるのに非常に苦労しました。少なくともそれを使用したときは、GWTでコーディングされていないWebサイトの一部とGWTを統合することができませんでした。最終的にはうまくいきましたが、それは大きなハックでした。

• 各サービスインターフェイスに対して作成する必要がある非同期インターフェイスは、GWTコンパイラーによって自動的に生成されたもののように見えます。
• 大規模なプロジェクトではコンパイル時間が長くなる

ただし、大規模なJavaScriptプロジェクトの場合は、これが最良の選択です。

GWT 2.4は前述の問題の多くを修正しており、JSライブラリのラッパーではなく、完全にGWTで記述されたベータ（Ext GWT 3.0.4別名GXT）から優れたウィジェットライブラリが出てきています。

残りの痛み：

• CSS3セレクターのサポートがないため、場合によっては "literal（）"を使用して回避できます。
• CSS3およびtransitionEndのような最新のブラウザーイベントのサポートの欠如。
• Java Calendarクラスのサポートの欠如（数年後）。
• JUnit4サポートの欠如（5年以上）。
• Google GWTチームからの明確なロードマップとリリーススケジュールの欠如。

GWT 2.4については、GWTをデバッグするときにFirefoxを使用してください。Chromeを使用するよりもはるかに高速です。そして、firefoxのみを使用する場合は、この行をproject.gwt.xmlファイルに入れることを検討してください。

<set-property name="user.agent" value="gecko1_8" />

また、Eclipseを使用している場合は、引数-> VM引数の下に以下を追加します。

-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

1つの大きな落とし穴は、特定のCSSスタイルを使用できるようにするために、最終的にHTML要素になるものに明示的にIDを割り当てる必要がある場合があることです。たとえば、GWT TabPanelは、tabPanelのtabBarにIDが割り当てられていて、そのelementIdに：hoverを指定した場合にのみ、tabBarItemsに対して：hoverを実行します。

私は他の場所でGWTの他のいくつかの欠点について書きましたが、それらはすでにrustyshelfsの回答でカバーされています:)。

私は最近GWTについて多くの作業を行いましたが、これは私が言わなければならないことです：

1. CSSスタイリングは時々トリッキーですが、IEでIE開発ツールを使用し、FirefoxでFirebugを使用して正確に何が起こっているのかを理解すると、変更する必要があるCSSが明確になります。
2. トリックを使用して、Googleにインデックスを作成させることができます。非常に有名なサイトはhttp://examples.roughian.com/です。Googleでその評価を確認してください。はるかに有名ではないサイトはwww.salvin.in（それに言及することはできません）で、単語に最適化しました：salvinホームページ（これらの3つの単語についてgoogleを検索）

GWT-EXTについてはあまり知りませんが、サードパーティのライブラリを含める必要はないと私も信じています。

あなたの決定に幸運を祈ります:)

GWTは機能検出の代わりにブラウザースニッフィングを行い、アプリケーションは一部のブラウザー（特に新しいブラウザー）では動作しません

ここに問題のいくつかの参照があります：

• google-web-toolkit問題2938：RFE：user.agentプロパティプロバイダーを改善して、userAgent文字列の「マスキング」に対応
• Iceweaselはサポートされなくなりましたか？-Googleドキュメントヘルプ
• すべてのブラウザーのGWT実装

以下は、特徴検出に関する参考資料です。

• ブラウザ検出（および代わりに何をすべきか）
• 機能検出：最先端のブラウザースクリプト
• ブラウザ機能の検出

JavaScriptフレームワークの比較から抽出-ウィキペディア

GWTチームは、昨年リリースされたGWT 2.7に多くの大きな改善を加えました。GWTの主な弱点の1つは、GWT 2.6以下ではコンパイルに時間がかかることです。これはなくなったGWTには、超高速で変更のみをコンパイルするインクリメンタルコンパイルがありません。

GWT 2.7に（Source）が追加されました：

• インクリメンタルビルドはわずか数秒
• よりコンパクトで正確なSourceMaps
• GSSサポート
• JSInterop
• 優れたJavaScriptパフォーマンス
• 小さいコードサイズ

信頼できる事実を入手するための最良の方法は、gwt調査。GWTの最大の問題の1つは、コンパイル時間が長いことです。幸いにも、それは非常に急速に改善しているので、近い将来に大きな問題になることはありません。もう1つの落とし穴は、Javaはより複雑な言語であるため、GWTは劇的に複雑になることです。また、コンパイルするとレイヤーが追加されます。たとえば、jsの相互運用には少しのボイラープレートが必要です。基本的な問題は、GWTが単純になるように設計されていないことです。非常に複雑なWebアプリ用にゼロから設計されており、コミュニティ全体が簡単なコーディングよりも一貫してパフォーマンス、コード品質、アーキテクチャなどを優先しています。からです。GWT
でいつでもjsを使用できるため、GWTに苦労している場合はjsの使用を検討してください。結局、GWTはjsなので、jsでできることは何でもGWTで実行できます。実際、ほとんどのGWTプロジェクトはjsを使用しています。問題は、GWTが大幅に複雑になることです。それにもかかわらず、それは時々余分な複雑さの価値があります。

GWT 3.0が大幅な改善をもたらすことは注目に値します。

RPCサービスオブジェクトの再利用。
アプリがハングしているように見える症状で競合状態が発生します。

私が遭遇した落とし穴1. superdevモードでの異なる動作。たとえば、Someclass.class.getName（）はSuperdevモードで完全に正常に動作し、クラスの完全修飾名を返します。本稼働モードでは、これは機能しません。

2. addWidget（widget）はウィジェットのremovefromparent（）を呼び出します

GWTは技術の傑作です。これは、クライアントとサーバーのプログラミングを統合して1つの一貫したアプリケーションにします。つまり、「階層化」の前にソフトウェアを作成する方法と、その方法を記述します。さまざまなスキルセット、チームメンバー間のコミュニケーションの誤り、一般的にWebデザインフェーズ全体（芸術的およびプログラミングの両方）を排除します。また、Android開発など、モバイルに最も近いものです。実際、GWTはHTMLだけでなく、さまざまなネイティブUIを生成するように設計されています。ただし、このような分離を確実にするためには膨大な規律が必要です-内層のプレゼンテーションにとらわれないようにするためです。

回避すべき最初の間違いは、4年かけて実現しましたが、EXT-GWT（GXTやSmartGWT）のようなサードパーティの拡張機能を使用することです。独自のスタイリングに投資するのではなく、かなりデスクトップっぽいウィジェットを使い始めるのは非常に魅力的ですが、私が最終的にうんざりするまで、SmartGWTで発生した問題の数はわかりません。つまり、コアGWT機能セットを特定の（かなり古い）レベルで凍結し、その上に構築します。また、最近のデスクトップのルックアンドフィールは、特にモバイルデバイスでは、パフォーマンスの低下、大量のバグ、互換性機能は言うまでもなく、ばかげています。一部のカスタム描画されたコントロールではなく、ネイティブの<select>要素としてレンダリングされたドロップダウンを、可能な限りネイティブのブラウザーコントロールに近づけたい。

モバイルトレンドのおかげで、UX全体がよりシンプルでフラットになり、シャープな外観のアプリケーションをスタイルするために多くのことを行う必要がなくなりました。「3D」の外観が必要な場合でも、グラデーションがあります。CSS3はすべてを簡単にし、GWTは生のCSSとは異なり、エレガントなオブジェクト指向の方法でラップします。したがって、GWTショーケースでかなり醜いベアボーンのコントロールを見て落胆しないでください。GWTチームは開発者の仕事であるため、意図的にスタイルを提供しませんでした。

残りは、美しく簡潔なAPIを備えた厳密に型指定されたJavaでのほとんどの従来のブラウザープログラミングです。ただし、もちろん、コードがブラウザ内で実行されることを忘れないでください。したがって、すべての呼び出しは非同期です。たとえば、GWT-RPCメソッドをループで呼び出すことはできません（リストにデータを入力するため）が、これに到達した場合は再帰的にチェーンする必要があります。状況。

GWT-RPCを使用しないなど、自称「アンチパターン」がいくつかあります。これまでのところ、10年間は​​良いことでした。シンプルさが鍵です。コードの優雅さと保守性のために限界のパフォーマンスを犠牲にすることは、1秒もないと思います。さらに、これはあなたのボトルネックがどこにあるかではありません-データベースで。もちろん、クライアントに送信するデータの量に注意してください。

また、既存のガジェットを見つけたりスタイルを設定したりできない場合は、リッチなHTML5要素セットを読み取れば、いつでもサードパーティの要素をラップできます。私は人気のあるjQuery FullCalendarでそれを行いました。ロケット科学ではありません。GoogleマップやGoogleチャートのような他のすべてのものは、準公式のGWTラッパーを持っています。

GWTは完璧です。それが十分な愛情を得られない唯一の理由は、まだ業界に影響を与えている初期のインターネット採用者がそれらを評価するためにコンピュータサイエンスとオブジェクト指向言語から来なかったからです。彼らは芸術的（Photoshop / WordPress）またはネットワーク（Perl / Python）の背景を持っています。