答案 0 :(得分：6)
我有几个GXT应用程序，其中一个是~35K行。没有发现其他人提到的任何问题。
我正在做直接的ExtJs / JavaScript，然后随着GWT-EXT的出现转移到GWT，后来转移到Ext-GWT（GXT）。如果不是那两个工具包，我今天仍然会使用ExtJs / JavaScript。
性能问题：现代浏览器上没有问题。在IE6 / 7上，你想要使用常识，从性能和可用性的角度来看，在网格中显示1000行并不是最好的选择。
答案 1 :(得分：5)
GXT仍然很糟糕。我们一直在使用它，虽然它提供了一些不错的小部件，但是编写任何业务代码都需要永远。我们大部分时间都花在试图让GXT做我们想要的事情上。例如，使用RPC是痛苦的，因为你必须继续从JPA实体bean转换为ModelData对象（或者可以通过RPC序列化的其他一些对象），还有一些不一致的地方，例如你是否想要使用FormBinding对象（它自动生成）表单元素和ModelData之间的映射，然后你不能使用真正有用的FieldSets。 FormBinding仅适用于FormPanels而不适用于FieldSets。
此外，如果您想使用FileUploadField对象，则由于帖子URL，您无法在开发模式下对其进行测试。
基本上，如果你想增加40％的开发时间。但是否则使用普通的JavaScript框架。
答案 2 :(得分：4)
我们在过去一年中一直在使用GXT 2.x，而我们使用GXT构建了3个项目。
除了缺少一个WYSIWYG UI设计器，它使得UI设计与其他框架相比相对较慢，它仍然是IMO在GWT之上构建的最好的小部件库。
到目前为止，我们还没有遇到任何与GXT有关的重大问题。
答案 3 :(得分：3)
可在此处找到良好的效果比较：http://gxtvsgwt.appspot.com/
答案 4 :(得分：3)
在我们目前的项目中，我们使用Ext-GWT 2大约一年没有任何重大投诉。它有时候有点儿麻烦，但通常都有效。
答案 5 :(得分：2)
我们使用GXT 2.1.x一年没有任何重大问题。最近，我们更新到GXT 2.2.4并且只需要对我们的代码进行微小的更改，但它们不是因为GXT，而是因为升级到GWT 2.3.0
就个人而言，我喜欢用GXT编码。我不明白为什么有人会说GXT开发很糟糕，除了已经提到的性能问题和缺乏UI设计器。
我不知道任何其他基于GWT的框架有如此多的功能。