我有一台能够运行 64 位 Windows 7 的不错的机器。那么为什么每次我在“开发模式”下停止一个小示例 GWT 应用程序、编辑它并重新启动它时，浏览器都需要 30 秒才能响应，无论是在最新版本还是在Firefox 和最新的 Chrome？
对于当今的 GWT 开发人员来说，这种基于糖蜜的编辑-编译周期是否是正常的、预期的事情？
对于更现实的应用程序来说，情况会变得更糟吗？或者这 30 秒的全部只是框架开销，而我自己的代码不会让它变得比任何时候都更加臃肿？
可以通过使用其他“模式”或任何其他调整解决方案来缓解这个问题吗？
谷歌员工是否拥有比我更快的机器，从而减轻了痛苦，或者他们是否像我们其他人一样遭受痛苦？
I have a decent machine capable of running 64 bit Windows 7. So how come any time I stop a small sample GWT app in "development mode", edit it and restart it it takes 30 sec to become responsive in the browser, both in latest Firefox and latest Chrome?
Is that sort of molasses-based edit-compile cycle just the normal, expected thing for GWT developers nowadays?
Will it get much worse for more realistic apps or is the whole of those 30 sec just the framework overhead, and my own code would not make it much more bloated than that any time soon?
Can this problem be alleviated by using some other "mode" or by whatever other tweak solution?
Do Google people have much faster machines than I do on which this is less of a pain or do they suffer like the rest of us?
发布评论
评论（3）
在开发过程中，GWT 应用程序可以在不同的模式下运行，并且对于何时需要
让我们退后一步，看看一方面开发模式/生产模式与“带调试器”/“不带调试器”之间的所有差异。当然，每个使用 GWT 的人都已经听说过它们...
模式
开发模式
使用附加到代码服务器的特殊浏览器插件运行客户端。您始终可以通过查看 URL 轻松识别此模式 - 它将包含类似
?gwt.codesvr=127.0.0.1:9997的内容 开发模式的主要优点是，它不需要您首先将代码编译为 JavaScript - 它在代码服务器中将客户端作为 Java 字节码运行。这基本上是一个 JavaScript 模拟 - 但它是如此接近，以至于大多数人不再注意到其中的差异（有些人甚至相信，GWT 在开发模式下将 Java 编译为 JavaScript，情况并非如此。）
由于代码作为 Java 字节码运行，因此此模式还允许您为客户端代码，我们将在下面看到（但您不必这样做！）
生产模式
将客户端作为已编译的 JavaScript 运行。在使用它之前，您必须先使用 GWT Java 到 JavaScript 编译器（通常称为
gwtc，或“带有图标”）
完成后（需要一段时间！），只需像开发模式一样启动 GWT 嵌入式服务器，但这次从您的 URL 中删除
?gwt.codesvr=127.0.0.1:9997。（或者，您可以将战争部署到单独的服务器（例如 Tomcat），并从那里运行它。）这里的优点是，a）您可以测试真实的编译结果，b）浏览器刷新比在开发模式下
启动
“不带调试器”
您可以简单地运行应用程序而无需附加调试器（在开发模式和生产模式下都可以），如果您
在开发模式下使用 Eclipse，则可以使用“运行方式 不需要代码服务器。
...”。您运行一个 Web 服务器（嵌入式 Jetty，通常在端口 8888 上）和一个代码服务器（通常在端口 9997 上），在生产模式下，如果您有客户端更改，当您刷新浏览器时，它们将被重新加载，这相对较快 - 您不必重新启动（代码）服务器，但它不像调试器那样立即。
如果您有服务器端更改，则必须重新加载服务器 Web 应用程序（在 Eclipse 中，您使用“开发”视图中的黄色小重新加载图标）这比完全重新启动服务器要快得多，但再一次，它并不像使用调试器那么直接！
“使用调试器”
在开发和生产模式下，您都可以使用附加的调试器运行应用程序。如果您使用 Eclipse，请使用“调试为...”。
对于开发模式，调试器会附加到代码的客户端和服务器端 - 而在生产模式下，它只能附加到服务器端！
如果您使用附加的调试器进行了客户端更改，则代码更改将立即生效，因此您所要做的就是单击网页中的某个位置来运行代码。
如果您使用附加的调试器进行服务器端更改，同样，代码更改将立即生效，因此您所要做的就是执行一些导致相应服务器调用的操作。
所有这些都非常快，但缺点是 Java 调试器只能应对某些类型的代码更改。如果您有更严重的更改，调试器将退出，并且您必须重新启动服务器（我仍在寻找一种在这种情况下重新加载和重新附加的方法 - 我认为这应该是可能的，但是有人已经有了可行的解决方案吗？）
另外，使用调试器时，您必须小心应用程序的状态。请记住，对代码的更改不会重新评估现有状态！
所以你基本上有四种组合
其他差异：
每种组合在开发速度和便利性方面都有其自身的优点和缺点。我喜欢根据情况使用所有这些。
这篇文章有点长，但我看到了很多围绕这个主题的问题，我想把它们全部写在一个地方。感谢您的阅读:-)
During development, a GWT application can be run in different modes, and there's often a bit of confusion about when it's necessary to
Let's take a step back and look at all the differences between Development mode/Production mode on the one hand, and "With Debugger"/"Without Debugger" on the other hand. Of course, everybody using GWT has already heard of them...
Mode
Development mode
Runs the client side with a special browser plugin that attaches to a code server. You can always identify this mode easily by looking at the URL - it will contain something like
?gwt.codesvr=127.0.0.1:9997The main advantage of Development mode is, that it doesn't require you to compile your code to JavaScript first - it runs the client side as Java bytecode in the code server. This is basically a JavaScript emulation - but it's so close, that most people don't notice the difference anymore (some even believe, that GWT compiles Java to JavaScript in Development mode, which is not the case.)
Since the code is run as Java bytecode, this mode also allows you to attach a debugger for the client side code, as we will see a little bit below (but you don't have to!)
Production mode
Runs the client side as compiled JavaScript. Before you can use it, you have to use the GWT Java to JavaScript compiler first (often known as
gwtc, or "the one with theicon")
After it's finished (takes a while!) just start the GWT embedded server like in development mode, but this time remove the
?gwt.codesvr=127.0.0.1:9997from your URL. (Alternatively, you can deploy the war to a separate server (e.g. Tomcat), and run it from there.)The advantage here is, that a) you can test the real compiled result, and b) that browser refresh is very much faster than in Development mode.
Launching
"Without Debugger"
You can simply run the application without attaching a debugger (that's possible both in Development and Production mode). Use "Run As...", if you use Eclipse.
In Development mode, this means that you run a web server (embedded Jetty, usually on port 8888) and a code server (usually port 9997). In Production mode, you don't need the code server.
If you have client side changes, they will be reloaded when you refresh the browser. This is relatively fast - you don't have to restart the (code) server. But it's not as immediate as with a Debugger.
If you have server side changes, you will have to do a server web application reload (in Eclipse, you use the small yellow reload icon in the Development view) This is much faster than a full server restart, but once again, it's not as immediate as with a Debugger!
"With Debugger"
Both in Development and Production mode, you can run the application with an attached debugger. Use "Debug As...", if you use Eclipse.
For Development mode, the debugger attaches both to the client and the server side of the code - whereas in Production mode, it can only attach to the server side!
If you have client side changes with an attached debugger, code changes will take effect immediately, so all you have to do is to click somewhere in your web page that causes the code to run.
If you have server side changes with an attached debugger, likewise, code changes will take effect immediately, so all you have to do is to perform some action that causes the corresponding server call.
All of this is extremely fast, but the drawback is, that Java debuggers can cope only with certain kinds of code changes. If you have more severe changes, the debugger will exit, and you'll have to restart the server (I'm still looking for a way to just reload and reattach in this case - I think it should be possible, but does anyone already have a working solution?)
Also, with debuggers, you'll have to be careful with the state of your application. Remember, that the changes to your code won't re-evaluate the existing state!
So you basically have four combinations
Additional differences:
Each combination has its own benefits and drawbacks for development speed and convenience. I like to use all of them, depending on the situation.
This post has become a bit long, but I have seen lots of questions around this topic, and I wanted to write it all down in one place. Thanks for reading :-)
我想我的回答是一个问题：“你确定你真的需要重新启动吗？”
假设您在浏览器中运行托管的它（听起来就像您是这样），那么大多数更改几乎在您完成后就变得“热门”。我昨天花了很多时间对模块中的主代码文件进行了各种更改，并且不需要为其中任何一个重新启动服务器。
我经常不得不在浏览器中重新加载页面才能看到更改，但这是一个不同的问题。
I guess my answer is in the form of a question, "Are you sure you're really needing to restart at all?"
Assuming you're running it hosted within the browser (which it sounds like you are) then most changes are "hot" almost as soon as you've finished them. I spent yesterday doing all kinds of changes to the main code file in a module and didn't have to restart the server for any of them.
I often had to reload the page within the browser to see the changes, but that's a different issue.
在 GWT 开发模式下，每次重新加载页面时，开发服务器都会重新编译 GWT 应用程序的源代码。这使您只需对 GWT 代码进行一些更改，然后在浏览器中重新加载页面即可查看更改 - 无需重新启动开发模式服务器。
当您在生产服务器上部署应用程序时，您部署了已编译的 JavaScript 文件。因此，您将看到的延迟将是加载这些页面的时间。
In GWT development mode every time you reload a page the dev server recompiles the GWT app's source. This enables you to just do some changes to your GWT code and just reload the page in browser to see the changes - no need to restart the dev mode server.
When you deploy your app on production server you deploy already compiled javascript files. So the delay you will see will be time to load those pages.