原文网址：http://www.gmarwaha.com/blog/2011/05/09/gwt-pros-and-cons/
译文网址：http://blog.dontcareabout.us/2013/04/gwt.html
注：原文写于 2011.05.09
BBS 版以 markdown 语法撰写
______________________________________________________________________
我爱 JavaScript。[jQuery] 跟 [MooTools] 出来之后，
让我对 JavaScript 的爱又增加了好多倍。
如果要我对所有我开发的 web application 做出选择，
我会从上面两个 framework 当中选一个。
但是在这一行，我不得不一次又一次地屈服于客户的压力、
用他们选择的技术来作业，无论他们的选择对或错
（付钱就是老大啊...... Orz）。
有一个客户让我接触到 [GWT] 的世界。
[jQuery]: http://jquery.com/
[MooTools]: http://mootools.net/
[GWT]: http://code.google.com/webtoolkit/
几年前当 GWT 刚发布的时候，我曾经试了一下。
我不怎么喜欢，所以我甩了 GWT 就再也没回头看过它一眼。
但是在过去六个月用 GWT 作业之后，我对这个 framework 有稍微不同的印象。
我仍然不会说 GWT 是什么拯救世界的神兵利器，
但至少它没有我想像的那么糟糕。
我把对这个 project 的观察结果纪录下来，好的坏的都有，
对之后要导入 GWT 的开发人员来说可能有点用处。
优点
====
1. 如果你对 Swing 或 AWT 是有经验的老手，
那不用考虑、用 GWT 就对了。
在这个背景条件下学习曲线会是最小的。
1. 即使你在 Java GUI 方面没啥开发经验，
有多年对付 server side 的 Java 经验，
也能在开发 GWT application 时派上用场。
1. 你可以把工作都交给 client、减少骚扰 server，
以建立反应迅速的 web application。
1. 虽然有众多的 JavaScript library、大多数都是称职好用的，
但许多传统的开发人员无法理解它们的真正威力。
请记得，像 JavaScript 这种强大的语言是一把双面刃。
如果你不知道怎么使用它，你甚至不知道怎么清理你制造出来的混乱场面。
1. 你可以把一个传统的 web application 渐进地转移程 GWT application，
这两个不是互斥关系。
你可以用 JSNI 这种聪明的技巧去加载你已有的 JavaScript function。
不过趁早把它们转移到 GWT 是比较好的作法。
1. GWT 的 IDE 支援度好到不能再好了。
Java IDE 已经在过去十年中成熟了，
成为世界上最好的 IDE 之一，GWT 可以直接获得这些优势。
1. 看看这精美的 debug 整合工具，你绝对会想拥有一套的。
成熟的 Java IDE 提供的 debug 支援度可以让任何人转而选择 GWT。
1. IDE 内建的 Java code 重构功能可以直接派上用场，
让你在任何时候都能维持简单的设计。
要在 JavaScript 作这件事会让你心脏衰弱。
1. IDE 的语法 highlight、错误检查、程式码自动完成快速见......
完全就是乐胜啊。
1. Google 正在积极发展 GWT（译注：......）。
我们知道这个 project 不会随便死掉（译注：......）。
直到现在，他们对这个 project 做了很多跟这个领域的未来有关的承诺。
（译注：............）
1. GWT 的社群也是一大利多。
每天在 StackOverflow、讨论区、wiki
以及个人 blog 都有相关讨论。
用对关键字，一个简单的搜寻就可以导引你到正确的方向。
1. GWT 是一个深思熟虑的 API，没有东西是仓促拼凑出来的。
这有助于开发人员快速理解抽象化的部份，使用起来也很直觉。
1. server 与 client 之间的资料传输，
你可以使用 GWT 内建的通讯协定，
完全不需要知道资料是怎么包装怎么发送。
如果你想要有更多掌控权，你一定可以改用 XML、JSON 或是其他可行的格式。
即使是用 JSON，你不需要用不直觉的 Java-JSON library。
透过 JSNI 直接用 JavaScript 来“eval”JSON，这招够帅了吧... \囧/
1. 能使用标准的 Java static code 分析器，
像 FindBugs、CheckStyle、PMD 等等
来监控程式码与设计的品质也是一项优势。
在成员经验值参差不齐的团队中，这是很重要的。
1. 你可以使用 JUnit 或 Test NG 来作 unit test，
用 JMock 或其他 mock library 来 mock 相依性。
如果你已经上手了，那么依循 TDD 就很简单易懂。
虽然 JavaScript 有 unit test framework，
像是 jsunit 跟 qunit... 得了吧...
有多少人已经再用或是想要用它们？
1. GWT compiler 产生跨 browser 的 JavaScript 程式码。
现在讲这个东西的行销人员可能会被打。
它已经变成一个基本需求，而不是奢侈品。
1. GWT compiler 会对产生的程式码作最佳化、
移除没用的程式、甚至混淆 JavaScript 程式码......
这一切只需要一个动作就完成。
1. 虽然 compile 的时间真天杀的久，不过在开发过程中不会遇到。
有一个特别的 hosted mode 透过 browser plugin
直接用 Java bytecode 产生输出结果。
这也是你可以用 Java debugger 来抓 client side bug 的主要原因。
1. 借由一些 project（像是 Smart GWT、Ext GWT 等等）
可以取得一些第三方的丰富元件
（译注：原文是 rich third-party control）。
它们设计的不错、容易使用、而且有布景主题。
所以，如果既有元件无法符合你的需求，
你应该在这些 project 当中找找看。
有极为渺茫的机会可以在这些元件中找到解决的方法。
即使它们没办法解决，你还是可以自己作一个。
1. GWT 强调“能保持状态（stateful）的 client
与不保持状态（stateless）的 server”这个概念。
这导致有很多使用者同时存在的 server 负载量尽可能地减少，
而只有一个使用者在运作的 client 端负荷加重。
1. i18n 跟 l10n 用 GWT 来作是相当简单的。
In fact locale based compilation is taken care by the GWT compiler itself.
（译注：翻译不能... Orz）
这很难说是一个只能在 client 端使用的 framework。
1. GWT 内建支援 browser 的“上一页”功能，即使在 AJAX 之下也可以。
如果你是 AJAX 开发人员，我几乎可以听到你松了一口气的声音。
这不用付出什么代价。
缺点
====
1. GWT 是一个快速发展的 project，所以有好多版本散落各处。
许多函数、interface 跟 event 已经舍弃不用了，
当你还有其他工作要作时，还要跟上脚步就不会太愉快。
1. 一开始有很多 GWT 的书，最近就没那么多了。
举例来说，我找不太到 GWT 2.0 的书，结果只能看 Google 文件。
我同意 Google 文件良好又完整，但是比不上一本好书。
1. 写 GWT 不有趣。
毕竟 GWT 里头都是 Java，而写 Java 不是很有趣。
如果全部的 layout 跟自订的控制方式都要用 Java 写，
你可以很轻松地让一个程式老手哭哭。
随着 GWT 2.0 导入 UiBinder，这个问题解决了，但是你得学新语法。
1. Java 转成 JavaScript 的速度相当地慢，
这是选择 GWT 的一个明显缺点。
1. 我个人偏好用 HTML 撰写结构，然后用 CSS 上样式。
用 HTML 的作法是干净且直接的，我多年来的经验就是这样做的。
但在 GWT，我被迫用一种特有的方法来作相同的事情。
对我而言 GWT 没有解决样式与校正不一致的状况，
这些加在一起就是个大问题。
因此，我超痛恨在 GWT 里头写 layout。
不过从 2.0 开始，有 UiBinder 跟 HTMLLayout
（译注：没有 HTMLLayout 这个 widget，不确定原作者要说啥？），
我觉得回到了自己熟悉的领域。
1. 要进入 GWT 需要一些 serious commitment level，
因为 client 技术的一个改变就可能需要完全重写你的 application，
这跟其他 client side 的 framework 是完全不同的。
1. 没有一个用 GWT 开发 application 的明确方法。
到底是一个 application 只用一个 module？
还是一个 page 就用一个 module？还是介于这两者之间？
这些设计模式发展迟缓，所以通常人们倾向在同一个 module 里头开发，
直到 module 大到不能阶受才重构成几个 module，
但为时已晚，重构不会像之前那么简单。
1. 把呈现的方式跟程式码混在一起，这不科学，
虽然传统桌机的 GUI application 是这样作。
但是近来，即使桌机的 application framework
（像是 Flex、Silverlight）也采用 XML 为基础的描述方法，
让呈现方式从逻辑中分离出来。
我觉得 GWT 1.x 版有这个缺点，
在 2.0 版导入 UiBinder 之后，我想这个缺点可以划掉了，
尽管有另一个痛苦的 XML 语言得学。
1. 你常常要写 3～5 倍多的程式码，
而其他像 jQuery 的 client side library 很简单就可以做完。
1. 你应该要记得，GWT 对 HTML 的抽象化还不够完整。
你仍然得了解 application 产生的 DOM 结构，如此一来才能挂上样式。
而且 GWT 会让结构看起来更可怕。
1. GWT 的优势仅对 Java 开发人员有效。
对于用 .net、PHP 的人啥都没有。
1. 如果你已经感受过 JavaScript 的威力、
并且知道正确使用下所带来的优势，
那么像 Java 这种笨拙的语言会让你好像断手断脚一样。