私は64ビットのWindows7を実行できるまともなマシンを持っています。小さなサンプルのGWTアプリを「開発モード」で停止し、編集して再起動すると、ブラウザーで応答するまでに30秒かかります。 Firefoxと最新のChrome？
この種の糖蜜ベースの編集-コンパイルサイクルは、今日のGWT開発者にとって通常の予想されることですか？
より現実的なアプリの場合はさらに悪化するのでしょうか、それとも30秒全体がフレームワークのオーバーヘッドにすぎないのでしょうか。また、私自身のコードでは、すぐにそれよりもはるかに肥大化することはないでしょうか。
この問題は、他の「モード」を使用するか、他の微調整ソリューションを使用することで軽減できますか？
グーグルの人々は私よりもはるかに速いマシンを持っていますか？これはそれほど苦痛ではありませんか、それとも彼らは私たちの他の人のように苦しんでいますか？
開発中、GWTアプリケーションはさまざまなモードで実行でき、いつ必要になるかについて少し混乱することがよくあります。
一歩下がって、開発モード/本番モードと「デバッガあり」/「デバッガなし」のすべての違いを見てみましょう。もちろん、GWTを使用している人は誰でもすでに聞いたことがあるでしょう...
コードサーバーに接続する特別なブラウザプラグインを使用してクライアント側を実行します。このモードは、URLを見ればいつでも簡単に識別できます。これには、次のようなものが含まれます。?gwt.codesvr=127.0.0.1:9997
開発モードの主な利点は、最初にコードをJavaScriptにコンパイルする必要がないことです。つまり、コードサーバーでクライアント側をJavaバイトコードとして実行します。これは基本的にJavaScriptエミュレーションですが、非常に近いため、ほとんどの人は違いに気づきません（GWTが開発モードでJavaをJavaScriptにコンパイルすると信じている人もいますが、そうではありません）。
コードはJavaバイトコードとして実行されるため、このモードでは、クライアント側のコード用のデバッガーをアタッチすることもできます。これについては、以下で少し説明します（ただし、そうする必要はありません）。
コンパイルされたJavaScriptとしてクライアント側を実行します。これを使用する前に、まずGWT Java to JavaScriptコンパイラー（多くの場合gwtc、または「
アイコン付きのもの」として知られています）を使用する必要があります。
終了したら（しばらく時間がかかります！）、開発モードのようにGWT組み込みサーバーを起動するだけですが、今回は?gwt.codesvr=127.0.0.1:9997URLからを削除します。（または、戦争を別のサーバー（Tomcatなど）にデプロイして、そこから実行することもできます。）
ここでの利点は、a）実際にコンパイルされた結果をテストできること、およびb）ブラウザーの更新が開発モードよりもはるかに高速であることです。
デバッガーを接続せずにアプリケーションを実行するだけです（開発モードと本番モードの両方で可能です）。Eclipseを使用する場合は、「実行...」を使用します。
開発モードでは、これはWebサーバー（通常はポート8888に埋め込まれたJetty）とコードサーバー（通常はポート9997）を実行することを意味します。本番モードでは、コードサーバーは必要ありません。
クライアント側の変更がある場合は、ブラウザを更新したときにそれらが再ロードされます。これは比較的高速です。（コード）サーバーを再起動する必要はありません。ただし、デバッガーの場合ほど即時ではありません。
サーバー側の変更がある場合は、サーバーWebアプリケーションのリロードを実行する必要があります（Eclipseでは、開発ビューで小さな黄色のリロードアイコンを使用します）。これは、サーバー全体を再起動するよりもはるかに高速ですが、これもそうではありません。デバッガーと同じようにすぐに！
開発モードと本番モードの両方で、接続されたデバッガーを使用してアプリケーションを実行できます。Eclipseを使用する場合は、「名前を付けてデバッグ...」を使用します。
開発モードの場合、デバッガーはコードのクライアント側とサーバー側の両方に接続しますが、本番モードの場合、デバッガーはサーバー側にのみ接続できます。
デバッガーが接続されたクライアント側の変更がある場合、コードの変更はすぐに有効になるため、Webページのどこかをクリックするだけで、コードが実行されます。
同様に、デバッガーが接続されたサーバー側の変更がある場合、コードの変更はすぐに有効になるため、必要なのは、対応するサーバー呼び出しを引き起こすアクションを実行することだけです。
これらはすべて非常に高速ですが、欠点は、Javaデバッガーが特定の種類のコード変更にしか対応できないことです。より深刻な変更がある場合は、デバッガーが終了し、サーバーを再起動する必要があります（この場合、リロードして再接続する方法をまだ探しています-可能であると思いますが、すでに誰かが行っています実用的な解決策がありますか？）
また、デバッガーでは、アプリケーションの状態に注意する必要があります。コードを変更しても、既存の状態は再評価されないことに注意してください。
つまり、基本的に4つの組み合わせがあります
その他の違い：
それぞれの組み合わせには、開発のスピードと利便性に関して独自の長所と短所があります。状況に応じて全部使いたいです。
この投稿は少し長くなりましたが、このトピックに関する質問をたくさん見てきたので、すべてを1か所に書き留めておきたいと思いました。読んでくれてありがとう ：-）
私の答えは、「本当に再起動する必要があるのですか？」という質問の形だと思います。
ブラウザ内でホストされて実行していると仮定すると（あなたのように聞こえます）、ほとんどの変更は、終了するとすぐに「ホット」になります。私は昨日、モジュール内のメインコードファイルにあらゆる種類の変更を加えて過ごしましたが、それらのいずれについてもサーバーを再起動する必要はありませんでした。
変更を確認するためにブラウザ内でページをリロードしなければならないことがよくありましたが、それは別の問題です。
GWT開発モードでは、ページをリロードするたびに、開発サーバーがGWTアプリのソースを再コンパイルします。これにより、GWTコードにいくつかの変更を加え、ブラウザでページをリロードするだけで変更を確認できます。開発モードサーバーを再起動する必要はありません。
アプリを本番サーバーにデプロイするときは、コンパイル済みのjavascriptファイルをデプロイします。したがって、表示される遅延は、それらのページをロードする時間になります。