GWT旨在更具可扩展性和可管理性，当然这也伴随着成本。如果您习惯于在小型网站/应用程序上与小团队（即1-5人）直接使用HTML / CSS / JS工作，则GWT可能会增加比其价值更高的复杂性。
如果您处于较大规模的环境中，并且预计有许多迭代和不同的人员进入/退出项目，则使用框架可能是值得的 - GWT非常好。顺便看看GWT EXT JS :)
与直接使用HTML相比，自定义GWT很难（但如果未来出现重大变化，则会带来回报）。为了理解所有组件如何配合，需要学习有关GWT API和架构的许多知识。
1) 如果你的模块变得越来越大，那么刷新前端（或在部署之前编译）可能会非常耗时。然而，您仍然可以像往常一样使用Firebug或类似工具，更有趣的是，调试容易且强大。但是也存在一些小问题，例如Java和JavaScript基础正则表达式之间的不兼容性。
2) 将由Photoshop等软件提供的“预期屏幕样本”（不确定如何称呼）转换为基于html/js GWT的前端更加困难。这是一个真正的缺点。
3) 你需要知道自己在做什么，但确实有很多现成的资源可用。使用GXT/SmartGWT或类似的库会有所帮助。将所有这些插件与JQuery内容包含在前端中也很困难。
4) 这就是GWT真正强大的地方。后端的东西和与前端的通信的易用性。我的看法是，如果你需要很多业务（主要是后端）逻辑，一旦学会如何有效地使用它进行开发，你不会后悔使用GWT。与BE部分的通信也使得在客户端编写业务逻辑变得更加容易。如果你渴望在前端使用美丽、非标准、易于定制的东西，而不需要太多逻辑、复杂的数据传输等等，那么你最好选择“标准”的非GWT方法。对于许多使用GWT的人来说，一个主要的优势是他们不需要在JS中编写代码，而GWT生成的JS代码快速、有效且跨浏览器。如果你不介意在html/js中编写前端（并且不需要适当的调试控制），并且想使用Java编写BE，那么DWR或其他轻量级Ajax库可能会对你有所帮助。
在GWT中实现定制化功能肯定更加困难。你必须要考虑到，你是在用Java编写代码，而这些代码会被翻译成js。
当然，你可以集成不同的js库，但相对于纯粹的html/css/js还是更加复杂。
还要考虑到，如果你要进行SEO优化，GWT可能会有些棘手。
