关于gwt的帖子很少呀。

javaeye关于gwt的帖子很少呀。 搜索整个论坛才发现两篇文章。不知道这里有没有用gwt作开发的， 能不能说说使用的感受。最近又看了下gwt，感觉最好的地方是调式方面， 用java写界面， 这样的话对于传统的写javascript效率会不会有很大的提高呢？ 还有debug， 虽然FF下面有firebug venkmen， IE下面有VS MSE， 但是感觉都不是特别好， 而且你还需要分别在IE FF下面测试。 但是gwt保证了能够同时在FF IE下面都ok。 还有就是GWT的界面定制能力。

能否具体谈谈， 按照gwt上说的，应该会提高效率才对。我现在是使用dojo + json来开发系统， 感觉效率不是很搞。很想尝试下gwt，难道真的是像你说的那样效率底下，所以用的人少，还是gwt还在他的孩提时代。

本人感觉gwt在自定义页面上会比较麻烦。

假如一个项目客户对界面没有什么要求的话， 而且如果你的css，html不是很在行的话， 我觉得就使用gwt里面提供的widget的样式也是不错的。

感觉现在使用gwt的确实很少。 可能很多公司都没有在意这个东西

我觉得你说得有些偏激了。做一个ajaxify的应用并不是html tag这么简单，大多数工作还是在javascript这边。好比做一个tab pannel， 假如你要自己写的话，虽然是控制一些div的visable，但是你还是需要写上一大段的js。 我不清楚你说的用一大段话去表达是什么意思， 我觉得你用gwt之后你的js应该是能少写了。而且你可以用java去写那些客户端组建的交互，难道你用javascript写起来会比这个爽。如果有个swing基础， 上手gwt的组建应该会比较快。

开始我以为是gwt生成了4M js，仔细看了下，原来是你用gwt作了个代码声称器。这个是不是你自己的问题呢？难道web框架一定要有crud 要有脚手架？？ tapestry有么， jsf有么。 这些关于持久层的东西是hibernate之类的框架应该关心的， 而且gwt也能跟spring很好的结合， 而且gwt也提供了非常方便的Remote ProcedureCalls 。

gwt有什么地方不够灵活， 至少我知道他应该可以使用自定义的js。  css也是可以定制的。 我不知道你说的死板是什么意思， 他也就在Remote ProcedureCalls上要求你要使用inteface，要使用一些规则。 难道ror不也是有许多规则麻，应该比gwt约束的地方多很多吧。

我从毕业开始就一直使用tapestry， 现在已经使用2年了。 我现在做的是一个rss reader项目， 也是一个非常ajax的项目， 我们用的是Tapestry + dojo + jsonrpc.
我们用了许多dojo的组建，尽管这样我们还需要写大量的js，效率非常低的，其实也就才两个页面， tapestry在这里做的工作非常少，以至于根本没有必要用他， 我们仅仅是用tapestry render一个初始页面而已。

我感觉gwt还是有潜力的，现在已经有eclipse 插件支持了。

我一直都不信任和喜欢什么代码生成器， 重复的工作可以从代码级别入手， 更好的代码结构， 更高的通用性， 更好的抽象。

我们用了dojo 的TreeV3组建支持树节点的拖拉（dnd）。 做得确实非常酷， 我们Hack dojo treeV3的许多东西。 当然全是js。 这部分是我们系统的一个重要的部分， 当你的js写多了的华， 你会感觉他会比些java代码难维护得多。 至少java重构和IDE的支持强大得多。

你说gwt的remote功能有许多问题， 能否找几篇这样的文章给我看看。其实我想这个应该不会有什么问题的。 再怎样remote都是通过xmlhttprequest去做的。

说不定google那天真的会作出一个基于eclipse的IDE出来呢。。

要看你是在什么应用级别上的代码生成。 公司里现在有个小项目是用trails，他能帮你生成domain curd 和 tapestry的页面。 但是我感觉用处不是很大。 我自己写这些页面也是很快的。

gwt的  google groups还是蛮活跃的。这里有个用gwt实现的petstore，
http://code.google.com/p/gwtpetstore/

gwt我感觉还可以，我没有用gwt做过项目，我也没有说gwt一定非常好，我想现在国内的许多公司现在也是在实践尝试中。 gwt现在才刚起步， 我相信google的那帮人的实力。

   

我在公司用gwt实现了一个小项目，我觉得非常之好，正如楼上所说，我原来使用struts，感觉用gwt比struts快多了

我觉得gwt的最大优势在于(这两个词是我自造的，也许不合适)：
desktop-app-style coding：像桌面编写程序(如swing)一样编写webapp
java-style javascript：像编写java（其实就是)一样编写javascript

所以gwt所作的事情其实两点：1)用一、二种技术(gwt、css)取代webapp中各种技术(html，javascript，jsp，以及java的各种框架)，使开发者不再需要在各种技术之间debug;2)为webapp开发的vb化提供了API，接下来，就等待厂商实现这种API的WYSIWYG的IDE了，如我们所见，目前已经有了几种ide，虽然还不是完全成熟，但是我们应该可以想见成熟之后的情形：界面及remote接口的定义完全由编辑器上的拖拽实现，开发人员之需要关心各个listener中的事件，以及各个控件的赋值，以及远程接口的实现代码就ok了

其实还有一点：由于gwt是API级别的，所以开发者可以使用它来作比使用框架更多的事情，比如现在已经有人开始使用gwt开发图形程序了

如我们所看到的那样，即使用某些框架能够开发gmail、google calendar的话，但是用这些框架很难开发google docs和spreadsheet

所以我们甚至可以设想某一天google开发了一个大众半的photoshop放在了网上

当然我不是说将来gwt会一统ajax江湖，各种框架技术都有自己的优势，gwt也是如此，它只是所有技术之一

不过纯粹个人观点来说，纯技术角度gwt真有可能一统ajax江湖，就看ide做到什么程度了——我超级期待某一天google自己release一个让人意外的ide出来，就如同google发布gmail、calendar、spreadsheet、docs等等让人无比以外的服务一样

我觉得gwt能够带来一些方便。调试 重构。 而且gwt会使你养成你写Component的习惯。就像写Swing一样， 这样的话我觉得到项目后期维护会非常容易。效率也有提高。而且现在gwt方面也能非常方便的跟spring整合。http://g.georgovassilis.googlepages.com/usingthegwthandler

现在第三方的gwt的组件库也非常多。 一个刚刚出来不到一年的项目能有如此的关注也证明了他的魅力。