将Google Web Toolkit（GWT）用作完整的Java Web框架是否有意义？
我感兴趣的是GWT可以作为我整个表示层的基础。
我很想知道是否有人成功地尝试过这种方法 – 或者说没有成功 – 并且可以说服或不会让我试图这样做。
一年前我和GWT合作过。 当时它似乎是一个好主意，有一些警告：
- 我对API的某些部分有“问题”，这可能与你编写的事实有关，就好像你在java中，而实际上你正在编写一个像java一样的单独编译环境，所以你做了一些不正确的假设（在这种情况下，将嵌套值传递给前端）。 我认为还有一个是重写我的ant脚本以使用32位jvm进行gwt编译。
- 我花了一些时间试图调整外观 – 我们从未部署完成的项目所以我不确定这将花多少工作才能达到专业水平，但它似乎（逻辑上）就像它是相当于调整摇摆界面。 也许比html更加笨拙，在视觉上。
- 因为ajax在最终产品中对你很隐蔽，所以如果表现不佳，我会对我可能做的事情表示担忧。
话虽如此，它似乎值得玩，我的经历很久很久以前在互联网时代，特别是鉴于它现在可能更加成熟。 值得指出的是，它是从大多数MVC框架开发GUI代码的一种非常不同（且令人耳目一新）的方式，值得一看，除此之外别无其他原因。
我的感觉是，如果你正在构建一个具有非常苛刻的图形要求的高负载专业站点，GWT可能不是一个好的选择，否则没问题。
您提到GWT将处理表示层。 你也会用Java做业务层吗？ 如果是这种情况，我想向您指出IT Mill Toolkit ，它正是如此：它是一个使用GWT来呈现其GUI组件的工具包，允许您完全使用Java来完成应用程序。 我认为它试图硬币的术语是“服务器驱动的RIA”。
我来自PHP背景，但很快就开始喜欢这个工具包了。 但是，我不会再说什么，让你做自己的决定可能会更好。
Disclamer：我在IT Mill工作，虽然这与我的意见无关。
GWT相对较新。 随着代码库的增长，编译过程往往变得有点慢。 当我们使用它时，我们发现许多问题与更复杂的小部件的布局和渲染，并且模拟器与真实服务器完全不同。 另外，我们在从右到左语言的i18n方面遇到了麻烦……
总而言之，GWT有（通常？）年轻技术的问题。 但是，它确实使某些事情变得非常容易，就像你命名的Ajaxifying一样。
我们已经为一个非常大的项目做了这个，只要你知道它的局限性，优点和缺点，它就会很好。 有趣的演示文稿是我们最少的麻烦，因为我们只是像使用CSS一样剥离它，就像任何其他HTML页面一样。 该项目上线，运行完美，所以我没有抱怨。
我在这里找到的陷阱你可以在这里找到：
最大的GWT陷阱？
我们开发了一个大型HR门户应用程序，整个表示层在GWT中完成。 后端是Spring。 这一切都运行良好，UI已经受到用户的好评。 非常重要的是，我们很容易添加新function并维护应用程序。 我认为使用Javascript库做一些可比较和可维护的东西要困难得多。
你确实需要某种客户端框架，或者你最终会编写一个（就像我们做的那样！）：我们的应用程序是基于GWT Portlets （免费和开源）构建的。
我们使用HTML片段为不同部署的应用程序设置外观，并将每个“页面”的布局存储在XML文件中。
关于这个可视video的一些很好的信息： http ：//raibledesigns.com/rd/entry/my_drunk_on_software_interview
GWT in it’s self是一个UI增强库，而不是框架。 如果您将它与Google App Engine一起使用，那么您就拥有了一个基本框架。 （这是一个不同的故事，当我看着它时，我决定不将它包含在我们的架构中）。
这是一个很棒的图书馆，我们用它做了一些很棒的事情。 然而，由于它是一个库，它只能与您的架构一样好。
至于ANT对64位编译器没有任何问题。
就生成的代码而言，如果您想要查看它，它就在您的战争中。 （它也是开源的，所以你可以在那里查看它。）
GWT在编译过程中做了什么：它为不同的浏览器集创建了几个JS库副本（编译可能需要几分钟的一个原因），您可以根据需要添加/删除它们。 这减少了需要下载的JS包，并提高了速度，因为如果（FF）那就不需要那些讨厌的（EI）。 但是，当您进行本地调试（至少在eclipse中）时，您不必等待，允许将其留给构建服务器（或者当您需要手动构建和部署（neanderthals）时）。
GWT的缺点。 因为它是一个javascript客户端（几乎是纯粹的），你不能将它用于不支持它的东西，或支持其中一个版本。 因此，对于像iPad和iPhone这样的东西，如果你不使用旨在弥补这些差距的额外库（如mgwt），你可能会遇到一些问题。