原文：http://soft.yesky.com/info/41/2547541.shtml
Google Web Toolkit 已经吸引了全世界无数web程序员的眼球，因为它承诺能够使AJAX Web开发变得简单。但是，它到底有多大的优势?而且，更为重要的是，我们有多需要它呢?
这是一个否认的声音——首先，作为一个开发人员和框架架构师，我发现Google Web Toolkit (GWT)非常得迷人。它是那些非常有才能的人才能做出来的相当棒的软件。但是，问题是:在企业软件开发的领域中，这种吸引力的作用好像并不大。我的意思 是，量身定制的软件中包含着成百上千个用例，而这些用例之间存在着极其复杂的交互业务和GUI逻辑。这种软件对于大多数程序员来说非常重要，因为工作中会 牵涉到。而且这种软件也是我下面要探讨的Web应用程序开发的类型。
首先，我们来总结一下GWT为(Java)Web 开发团体所带来的创新，有以下几点:
一个使用Java.lang API实现的从Java到Javascript的编译器——虽然这个想法很棒，但是，这确实不能算是创新。因为，至少有一个以上的方案(J2S)已经提供了与此类似的特性，实际上，还提供了更先进的JavaScript生成特性。
一个窗口组件库，能够在不使用HTML的情况下构建用户界面(UI)。这有些类似于Dojo中具备的功能，并且与J2S/RIA几乎相同。除此之外，还有一些服务器端的框架也能够提供相同的功能(如Echo2、wingS)
一个在HTTP协议上的远程过程调用(RPC)的实现，它能够通过DWR在其他协议上实现。
一个允许在Java中调试应用程序的容器。实际上，J2S确实不需要这个功能，因为它能够解释SWT/RCP代码，并且作为桌面应用程序自动运行。
在项目开始时，脚本是受到了Ruby on Rails的启发(至少是类似的)。
因此，Google主要是陷入了这个严重的问题:重新实现所有这些可利用的项目。当然，你可以争辩说，他们实现得更好、用起来更加方便、使代码 更加文档化(这通常是一个项目成功与失败的关键)。但是，他们既然够像重新实现无数的其他项目，那为什么不重新实现Eclipse项目呢?而且，他们为什 么不利用丰富客户端平台(RCP)或者丰富互联网应用程序(RIA)堆栈呢?
关于这个问题，我的回答非常简单——Google希望解决他们自己的问题。为了理解GWT，我们首先需要理解Google创建它的动机。 Google是不做商业软件的——他们做桌面软件，然后把它们放到web上(如GMail、Base、Spreadsheet、Calendar等)。这 些软件所包含的用例相对较少，而用例通常都是很复杂的并且需要响应的。
Google需要一种开发新的web应用程序的方式，这种方式应该是:
1. 高度响应的
2. 迅速开发的
3. 迷人的
其中，第二个目标的障碍是:如果要在web上达到高度响应，那么，你必须采用很多快速解决方案，而且更糟糕的是，你需要针对不同的浏览器采用不同的快速解决方案。正是这个问题使AJAX应用程序的开发成本远远高于普通应用程序的。
针对这个问题，一个显著的解决方案是:把这些快速解决方案封装起来，放到简洁的界面背后。还有一个不很显著的解决方案是:使用大量的集成开发环 境(IDE)和调试器，把快速解决方案封装到静态类型语言中，然后，尽量避免在应用程序中同时使用JavaScript。因此，GWT是解决快速开发 AJAX类桌面应用程序的最佳方案，并且，GWT能够运行在主流的浏览器上而仅需要相当少的测试。
但是，剩下的开发人员应该怎么办呢(尤其是那些编写大型商业应用程序的开发人员)?我的观点是:如果GWT不是100%纯粹基于 JavaScript的话，那么它将是一种非常棒的视图技术。关于HTML和JavaScript的问题是:目前，至少有4种大型的不兼容的平台实现机 制。我们正在讨论的就是:一种能够配套四种虚拟机的语言，同时它能够与事后制定的标准松散耦合——James Gosling的恶梦实现了。
Web在商业应用程序中能够得到如此广泛的使用，其中一个主要原因就是:它是建立在Java承诺一次编程处处运行的基础上的(因为web平台比 Java简单得多，而且对客户端环境的依赖较少)。而且web也能够给我们提供这些可能的特性:易于混搭、整合、重新设计等等。但是， JavaScript却使这个承诺变得毫无意义，因为在浏览器中存在着:
对于脚本规模的限制
对于脚本存储消耗的限制
对于脚本运行时间的限制
交叉域的访问限制
非常多其他类型的限制，程序缺陷和不兼容性，这些都在折磨着web程序员
所有的这些意味着你只能封装这么多——迟早一些“有毅力”的bug会死灰复燃，或者，使用标准工具包的话，你可能完成更多工作，而现在，你还需 要采用JavaScript快速解决方案。实际上，我几乎能够确保:在所有规模足够大并且复杂的应用程序中，这种现象很快就会出现(我的意思是像内存溢出 这样的bug，它们几乎不可能在平台中被调试出来)。确实，对于应用程序而言，HTML和HTTP从来都是没有意义的，它们的作用是用于在科学家之间分享 信息的。不久，动态DOM、CSS、XML以及其他缩略语所代表的技术将运用到这些应用程序中来，虽然它们能够适合，但是，并不匹配——你可以用，但是无 法走得很远。
现在，结束对AJAX的讨论，我们切换到应用程序本身上来。一个典型的大型企业应用程序有着各种不同的用户界面需求，而不仅仅是一个典型的桌面 界面。在商业应用程序的图形用户界面(GUI)中，有许多大而复杂的工作流，但是，只是一小部分这样的工作流是需要达到高度响应的(典型地，某些查询或者 搜索)。而且，通过使用HTML并且添加一些独立于浏览器的JavaScript，这些需求是很容易满足的。实际上，如果我们对商业用户的需求进行调查的 话，就能够了解到他们所需要的软件是:
满足他们需要
能够快速开发、价格合理
不要与单独的开发商或者合作者绑定
易于与其他软件整合
通过以上分析，能够找到给商业世界带来这些的软件，并不是那些没有使用AJAX的软件。在web框架中，首先需要满足的是高度响应和整合——可 能这就是为什么Struts如此流行的一个原因(运用Struts的主要过程是解决大量的遗留代码)。而且AJAX，如果有什么区别的话，那就是:加大整 合难度、降低生产力。
但是，这就意味着我将永远宣传简单的web应用程序么?当然，不是!我只是认为:基于IE来模拟桌面，这是商业客户端所无法承受的。如果已经做 好了一个通用的丰富的GUI平台，那么，我将成为第一个进行试验的人。使Eclipse 丰富客户端平台(RCP)更加完美或者在Adobe Flash上编译Java应用程序(至少是稳定的平台)，甚至可能将Avalon运行在Linux上。仅仅给我一些任务——让我以此来编写Java代码、 并且带来的困扰比web应用程序少，我就能够无障碍地工作了。
因此，在未来的几年内，Google Web Toolkit至关重要么?我肯定希望是不，因为这将意味着，我们必须在本质上具有破坏性的平台上来构建下一代的应用程序。而且，不论我是否有偏见，在21世纪的前十年内，我非常希望能够看到更好的平台发布。