GWT的最大陷阱是什么？

一个主要的陷阱是有时你需要显式地为最终成为HTML元素的内容分配一个id，以便能够使用某些CSS样式。例如：只有在TabPanel的tabBar被分配了一个id并且您在该elementId上指定了:hover时，GWT TabPanel才会在tabBarItems上执行:hover。
我曾经在其他地方写过一些GWT的缺点，但它们已经被rustyshelfs回答涵盖了 :)。

GWT是一项技术杰作。它将客户端和服务器编程结合在一起，使其成为一个连贯的应用程序 - 这是软件在“分层”之前编写的方式，也是应该编写的方式。它消除了不同的技能集、团队成员之间的沟通问题，以及整个Web设计阶段：包括艺术和编程。而且它是最接近移动开发（例如Android）的技术。事实上，GWT旨在生成不同的本地UI，而不仅仅是HTML。尽管需要极大的纪律性来确保这种解耦 - 保持内部层呈现无关。

你应该避免的第一个错误是使用第三方扩展，比如EXT-GWT aka GXT和SmartGWT。开始使用它们漂亮的桌面小部件代替投资于自己的样式非常诱人，但我不能告诉你我在SmartGWT上遇到了多少问题，直到我终于受够了。简而言之，它将核心GWT功能集冻结在某个（相当过时的）水平上，然后在其上构建。此外，请记住，那种雕刻式的桌面外观看起来现在很傻，更不用说笨重的性能、大量的错误和兼容性特性 - 尤其是在移动设备上。你想尽可能接近本地浏览器控件，即下拉菜单呈现为本地<select>元素，而不是一些自定义绘制的控件。

由于移动趋势的影响，整个用户体验变得更加简单和扁平化，因此您不需要做太多工作来设计一个漂亮的应用程序。虽然如果您想要“3D”效果，也可以使用渐变。CSS3使一切变得容易，而GWT以优雅的面向对象方式包装它，不像原始的CSS。因此，不要因为在GWT Showcase中看到相当丑陋的基本控件而感到沮丧。GWT团队故意没有提供任何样式，因为这是开发人员的工作。
其余部分基本上是强类型Java中的传统浏览器编程，具有美丽简洁的API。但当然不要忘记您的代码运行在浏览器内部，因此所有调用都是异步的，例如您不能在循环中调用GWT-RPC方法（以填充某些列表），但需要递归链接它们，如果您遇到这种情况。
还有一些自称为“反模式”的东西，比如不要使用GWT-RPC。到目前为止，它对我来说一直很好：已经10年了。简单性是关键。我不会考虑牺牲一些边缘性能来换取代码的优雅和可维护性。此外，这也不是您的瓶颈所在——数据库才是。当然，要注意向客户端发送多少数据。

如果您找不到或无法样式化现有小工具 - 阅读丰富的HTML5元素集，您始终可以包装第三方小工具。我使用了流行的jQuery FullCalendar。这并不是什么难事。其他所有内容，如Google Maps和Google Charts都有半官方的GWT包装器。

GWT非常完美。它没有得到足够的关注的唯一原因是早期互联网采用者并不来自计算机科学和面向对象语言，无法欣赏它们。他们要么有艺术背景（Photoshop/WordPress），要么有网络背景（Perl/Python）。

我遇到的陷阱： 1. 在超级开发模式下，行为不同。例如，Someclass.class.getName()在超级开发模式下完全正常，并返回类的完全限定名称。但在生产模式下，这种方法无法正常工作。
2. addWidget(widget)将调用widget的removefromparent()方法。

重复使用RPC服务对象。
这会导致竞态条件，症状看起来像应用程序挂起。