GWT 优点和缺点「建议收藏」

大家好，又见面了，我是你们的朋友全栈君。

原文地址：http://blog.csdn.net/superhc/article/details/7223716点击打开链接

优点：

如果你以前使用JAVA开发Swing or AWT应用, 那么选择GWT是最自然的. 对这样的开发人员来说，学习曲线是最平缓的。（评论中被质疑。认为不懂得JAVASCRIPT就无法真正DEBUG使用GWT中遇到的问题）
即使你不是JAVA GUI开发的老手，多年JAVA服务器端编程的经验也会帮助你较快上手。
你创造的快速响应的web应用可以基于很少的的客户端开发和更直接的服务器开发。
虽然网络上有很多实用的JAVASCRIPT类库，很多传统程序员并不真正理解它们的价值。铭记，像JAVASCRIPT这样强大的语言总是一把双刃剑。如果你不知道如何正确使用它，你会弄的更糟。（被质疑，对质疑者而言，高质量的开源的类库很难找）
你可以迭代的把传统WEB应用移植到GWT。这不是一个要么全转要么全不能转的选择。你可以使用JSNI作为去调用那些已经被移植的JAVASCRIPT函数。但是总是越早越好。
GWT的IDE支持是最好的. Java IDEs 在过去的十年中不断成长成为世界上最好的之一，而GWT正好利用了这点。
集成的跟踪查错是开发人员梦寐以求的功能. 集成在JAVA IDE中的优秀的跟踪查错功能可以让任何人钟情于GWT。
集成在IDE中的重构JAVA代码功能可以保持代码总是保持简单，而这点JAVASCRIPT很难做到。
集成在IDE中的语法高亮，错误检查，代码完成快捷等等是无法抗拒的。
GWT一直被GOOGLE积极的维护着。我们知道这个项目不会很快停滞。到现在，他们仍旧对这个项目的提出了很多承诺。（评论中，有人质疑DART项目和GWT的冲突，怀疑GOOGLE会不会逐步转移到DART）
活跃的社区支持是一个对GWT巨大的加分因素。在很多论坛，WIKI和BLOG都有讨论。一个简单查询可以帮助你找到正确的方向。（被质疑，因为和其他框架JQUERY相比，GWT的第三方组件相对少）
GWT是一个设计精良的API; 不是一个为了快速发布的半成品。这帮助开发人员较容易理解GWT的抽象和更简单去应用。
你可以使用GWT自己的协议在客户端和服务器端交换数据，这样就不用关心数据打包和传输的细节。如果你需要更多的控制，你可以使用XML, JSON或者其他任意的格式。在这种情况下使用JSON，你仍旧可以抛弃难用的JAVA的JSON类库。你可以直接使用JSNI去执行直接的JAVASCRIPT。
你可以利用标准的JAVA静态代码分析工具，比如FindBugs, CheckStyle, Detangler, PMD等等，去监控和管理代码及设计质量。这点在一个比较大的有各自分工的团队中尤其重要。
你可以使用JUnit或者Test NG进行单元测试，可以使用JMock或者其他类似类库去替代依赖。TDD的执行是很直接明了的，如果你已经开始实践了。尽管有很多JAVASCRIPT的单元测试框架，比如JSUNIT和QUNIT，请告诉我有多少人真正了解它们，或者忍不住要求使用它们。
GWT编译器产生跨浏览器的JAVASCRIPT代码。如今，这已经成为WEB应用的必需品。
GWT编译器优化产生的代码，删除无用代码，甚至可以混淆JAVASCRIPT代码。
尽管编译过程很长，你不需要在开发阶段经历它。GWT有一种特殊的模式可以使用浏览器插件去产生输出。
丰富的第三方组件，比如Smart GWT, Ext GWT等等。它们有着很好的设计，并且支持主题定制。因此，如果GWT标准组件无法满足你的需求时候，这些第三方组件很有可能帮到你。就算还是没有，你还可以开发自己的定制组件。
GWT 强调有状态的客户端和无状态的服务器端。这可以在多用户并发的情况下很大的减轻服务器的压力。
I18N和L10N在GWT里面很容易使用. 事实上，GWT采用的是基于区域的编译器，而其他客户端的框架很难轻易做到I18N和L10N。
GWT使用AJAX并集成浏览器BACK.的支持。如果你是一个AJAX程序员，你可以减少很多的工作量。

缺点:

GWT发展很快，导致了同时存在了很多版本。很多函数，接口和事件在不断推出的新版本中失效，这样会让基于GWT开发的项目不得不花费时间和精力跟上GWT的步伐。（被质疑，其他框架有同样的问题）
开始的时候有很多GWT书籍，而现在则很少了。举个例子，我没有看到很多关于GWT 2.0的书。这让我们不得不使用GOOGLE提供的文档。这些文档是高质量的和全面的，但仍旧比不上一本好书可以带来的帮助。
GWT不是很容易被使用的，毕竟JAVA是一门较难的语言，而GWT基于JAVA。再加上你需要使用JAVA去构造整个布局和页面组件，你可以让一个程序员很容易头疼。在GWT 2.0中推出的UI binder似乎解决了这个问题，但你仍旧学习一种新的语法。
Java to JavaScript 编译太慢了，这是个你决定使用GWT前需要仔细考虑的问题。
我个人习惯于使用HTML和CSS来设计网页。但在GWT中, 我不得不使用GWT专有的方式. 再加上GWT对于样式和布局的不兼容性更加让网页设计变得复杂。但是在UI Binder和HTMLLayout在2.0+版本中推出后，我觉得舒坦多了。
使用GWT需要很认真的态度，因为一个客户端技术的更新可能会需要重写你整个应用。
目前还没有使用GWT的最佳实践。通常情况下，人们会把所有GWT代码放在一个模块里面直到被认定为太大而不得不拆分成多个模块。如果拆分过晚，重构也变得很困难。
在GWT 1.X中，表现层代码和逻辑代码是搅合在一起的。引入UI Binder之后，这个问题应该解决了。但是学习一门新的XML语言也是让人不爽的。
处理简单事情时，GWT通常会产生3到5倍于其他框架（比如JQUERY)的代码。（被支持，针对简单的事情，应该使用JQUERY）
你应该记住GWT对HTML的抽象是不完整的。你仍旧需要了解最终产生的DOM结构，才能够正确应用样式。然而，从GWT的代码无法很直观的看到最终产生的DOM结构。
GWT对JAVA开发人员来说是优势，对.NET和PHP来说则不是。
如果你已经体会了JAVASCRIPT的能力并且知道如何使用它，你会发现使用非表述性的语言比如JAVA是一件很麻烦的事情。