有没有人使用过GWT，可以说它真的实现了它的承诺？[已关闭]

我在GWT中编写了相当大的应用程序，我不得不说，GWT给我留下了比项目开始时更深刻的印象。我对这个平台的总体“感觉”是，事情真的经过了深思熟虑，除非他们能做得很好，否则他们不会做事，并且可以在所有浏览器上都做得很好（IE用户仍然是你的用户！

现在，请记住，GWT真正擅长的是创建大型，高度动态的单页样式Web应用程序。如果你的目标是用一些javascript效果来增强一个静态页面，那么GWT是巨大的过度杀戮（gquery可能会改变这一点，但我没有gquery的经验）

我喜欢的一些功能包括：

• 在服务器端和客户端之间共享代码的能力。（当然，如果你的服务器端是用java编写的）。起初我没想到会经常使用这个，但在实践中，它确实可以节省大量的代码重复。但是，我发现一般来说，这仅适用于使用GWT编写的代码 - 使用未使用GWT编写的代码通常不能很好地工作。这是因为GWT在JDK中只有一个类的子集，而在javascript中，你必须比在服务器端更关心性能。
• 它的目标是实现最快的javascript，比你手写的要快（因为如果你用手写它，代码将无法维护）。不幸的现实是，很多人使用的浏览器都有非常慢的javascript引擎，所以你的javascript代码的性能非常重要。Gwt的编译器是一个真正的优化编译器 - 它将内联方法，插入所有字符串。尽可能取消虚拟化方法调用等。由于您正在为每个浏览器和区域设置进行编译，因此编译器还可以内联特定于浏览器和特定于区域设置的代码。这个Google I / O演示文稿有一些基准测试，有几张幻灯片。
• 它还会自动将图像精灵化在一起，以最大限度地减少所需的http请求数量，再次提高您网站的速度。GWT 2.0将允许您将任意文件组合在一起。
• gwt创建的大多数文件都有一个强哈希作为文件名，这使您可以将文件设置为永久缓存，但不必担心如果文件更改，人们有旧版本
• GWT 2.0中的代码拆分非常令人印象深刻，并且很难手动完成。随着应用程序大小的增长，处理javascript的大小越来越重要，您需要能够将其拆分为块。
• 您正在使用静态类型语言进行编码。我知道有些人更喜欢动态打字，但我喜欢将这场辩论与emacs vs vi辩论进行比较 - 两个阵营中都有很多聪明的人，在互联网上争论不会改变任何人的偏好。
• 你可以使用Java生态系统中存在的许多伟大的工具，这些工具通常比等效的javascript工具成熟得多。- junit，java IDE，java调试器，重构等

如果你同时熟悉 JavaScript 和 Java，你真的非常适合充分利用 GWT。许多人没有意识到的是，GWT的层次非常好，你可以真正决定你想在哪个级别工作。

例如，我有时直接针对项目的DOM库进行编写。这很像编写JavaScript代码，除了你能够正确使用IDE并获得编译器的强大功能。从编译器中，我得到了静态类型检查，许多好的编译器优化，以及（实际上是我最喜欢的维护代码）调试模式断言。从来没有人真正做过很多断言的能力，但是能够编译一个调试模式真是太好了，该模式可以进行昂贵的检查以梳理出错误，然后关闭调试模式并让代码蒸发。（不仅断言语句消失了，而且所有可从断言访问的代码也会被编译出来）。

其他时候，我针对GWT的UI库编写代码。该代码看起来有点像swing或SWT代码，因此对于纯java开发人员来说，它是最舒适的。在这个级别上工作，你不必担心DOM，并且通常可以在不编写任何JavaScript的情况下构建应用程序。您偶尔会遇到一个错误，即某些内容在特定浏览器上无法始终如一地工作。GWT的人考虑这些错误。

你可以选择你想在哪个抽象级别工作。每个级别都有权衡，但GWT应该支持它们。

另外，完全披露：我是Chi上面链接的视频中的家伙，所以你可能会说我非常依恋GWT。