我的公司正计划开发一个全新的web前端应用程序。
一些背景：
- 它必须"嘶嘶作响"，即具有良好的市场外观和感觉
- 我们的开发团队没有Java经验，在Silverlight、Javascript、JQuery或CSS方面的经验有限
- 上市时间是一个因素
- 我们需要从Oracle数据库流式传输大量数据
- 它必须支持500-1000个并发用户
- 它将在防火墙后面的内部托管
- 我们需要地图(地理空间)功能
有人建议使用GWT而不是Silverlight或传统技术(Javascript、jquery、CSS等)。
我不确定这样做是否正确？GWT的许多新闻都来自2007/2008年。这让我觉得这项技术已经过时了，可能正在消亡。
如果你有选择，你会选择GWT吗？
不幸的是，您的两个语句在这种情况下是互斥的：
- 我们的开发团队没有Java经验
- 上市时间是一个因素
我是一名Java程序员，在过去一年左右的时间里学习了GWT；成熟的开发工具。我可以比以往更快地完成web开发(使用ASP、JSP、ExtJS…)
但是，正如其他评论者所说：如果你没有Java经验，你会发现在短时间内学习这两种技术(Java&GWT)是一个真正的挑战。如果你能在合理的时间内成功上市，我只能想象代码库的状况会非常糟糕(因为你会边学习边学习)——这对你的组织闪亮的新企业来说将是一个非常糟糕的基础。
再说一遍，在你列出的其他相关技能中，你也没有"很多"技能。
我怀疑还有更有效的解决方案。正如一些聪明的老山羊项目经理所说：
我有三个变量来交付您的项目：时间、成本和质量。选择任意两个
在您的情况下，如果组织想要在短时间内获得高质量的产品，则必须补偿成本因素-您的组织应该购买一些临时的GWT专业知识，为您提供一个健全的软件体系结构，并在接下来的几个月指导您的团队。在那之后，你将准备好占据统治地位，通过"站在巨人的肩膀上"继承高质量的代码库。
正如其他人所说，GWT绝对不是一个垂死的项目。事实恰恰相反，因为现在谷歌内部有20多个定期贡献者(而2008年只有半打)。Wave(尽管作为谷歌服务已经停产，但它仍然是Apache基金会的一个项目)、Orkut、AdWords、Google Moderator和新的(仍然是测试版)Google Group都是用GWT制作的；谷歌Buzz和谷歌其他一些项目的部分内容也是用它构建的。
现在你的选择：
- Silverlight是一项正在消亡的技术。微软明确表示，它现在投资于"HTML5"：http://www.zdnet.com/blog/microsoft/microsoft-our-strategy-with-silverlight-has-shifted/7834
- GWT主要是一个客户端工具包，但它附带了用于客户端-服务器通信的"高生产率"工具(GWT-RPC和RequestFactory用于端到端协议，AutoBeans用于轻松的JSON序列化)。使用UiBinder，您可以轻松使用您的网页设计师技能
- 如果您对JS感到满意，那么就选择它，但您必须选择"正确的工具包"(jQuery？Google Closure？)。否则(似乎是这样)，这真的取决于你需要/想要成为多少"ajaxy"。我坚信"一页应用程序"，但YMMV，或者你可以有特定的限制来排除它。在任何情况下，您都必须选择服务器端技术
因此，根据您的需求/愿望和技能，我会选择GWT或"一些JS工具包"。在任何情况下，您都可以完全控制外观(除非您选择一个臃肿的播放器：ExtJS/ExtGWT、SmartGWT或类似的播放器；您可能会在更短的时间内推出这些产品，但您稍后会在性能、与其他工具包的集成以及外观方面付出代价)。
根据您所说的技能，我肯定会推荐GWT(尽管您缺乏Java经验)；因为缺乏JavaScript的经验远比缺乏Java的经验更糟糕(你说的是一个"大型应用程序"，所以正确地开始构建东西和/或拥有帮助重构的工具非常重要，Java就是这样)。
@ianmayo在我写上面的时候回答了，我只能相信他说的！
GWT绝对不会老，也不会死！谷歌自己的许多应用程序都是使用GWT开发的。您可以下载GBST案例研究，了解这家全球金融公司如何使用GWT来提高生产力并创造丰富的用户体验。你必须知道，当你使用GWT时，你会自动使用javascript、html等。你用java创建了一个GWT应用程序，但当你编译它时，GWT会创建一个包含html文件、javascript代码、css等的文件夹
我绝对推荐它！
为了不用以上看似一致的答案误导读者，请保持客观的观点，下面的评论表达了我使用GWT的确切经验。GWT是否正在消亡取决于有多少新应用程序将采用它，谷歌趋势可以判断(GWT-trend)。
摘录自https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>我回答这个问题有好有坏——好的是，我以前确实使用过它，坏的是，在使用GWT之前，我对HTML/CSS/JavaScript非常有经验。这让我很恼火，因为其他不了解DHTML的Java开发人员可能不会使用GWT
GWT说到做到——它将JavaScript和某种程度上的HTML抽象为Java。对于许多开发人员来说，这听起来非常棒。然而，正如Jeff Atwood所说，我们知道，所有的抽象都是失败的抽象(如果考虑GWT，值得一读)。对于GWT，这特别引入了以下问题：
在GWT中使用HTML很糟糕
正如我所说，在某种程度上，甚至抽象掉了HTML。对于Java开发人员来说，这听起来不错。但事实并非如此。HTML是一种文档标记格式。如果您想创建Java对象来定义文档，则不需要使用文档标记元素。它冗长得令人抓狂。它也没有得到足够的控制。在HTML中，基本上有一种编写<p>Hello how are <b>you</b>?</p>的方法
在GWT中，有3个子节点(text、B、text)连接到一个P节点。可以先创建P，也可以先创建子节点。其中一个子节点可能是函数的返回结果。在与许多开发人员进行了几个月的开发之后，试图通过跟踪GWT代码来破译HTML文档的外观是一个令人头疼的过程。
最终，团队决定，也许对所有HTML使用HTMLPanel是正确的做法。现在，您已经失去了GWT的许多优点，即Java代码可以很容易地使用元素来绑定数据。
在GWT中使用CSS很糟糕
通过附加HTML抽象，这意味着您使用CSS的方式也有所不同。自从我上次使用GWT(大约9个月前)以来，它可能有所改进，但当时CSS支持非常糟糕。由于GWT让您创建HTML的方式，您经常会有一些级别的节点被注入(任何CSS开发人员都知道这会极大地影响渲染)。嵌入或链接CSS的方法太多，导致名称空间混乱不堪。最重要的是，你有sprite支持，这听起来很好，但实际上改变了你的CSS，我们在编写属性时遇到了问题，后来我们不得不显式地覆盖这些属性，或者在某些情况下，阻碍了我们匹配手工编码的CSS的尝试，不得不以GWT不会搞砸的方式重新设计它。
问题的联合，利益的交叉
任何语言都会有自己的一系列问题和利益。你是否使用它是一个基于这些的加权公式。当你有一个抽象概念时，你得到的是所有问题的结合，以及利益的交集。JavaScript有它的问题，通常被服务器端工程师嘲笑，但它也有很多有助于快速web开发的功能。想想闭包、语法简写、特别对象，Jquery所做的所有事情(比如CSS选择器的DOM查询)。现在忘记在GWT中使用它吧！
关注点的分离
我们都知道，随着项目规模的增长，良好的关注点分离至关重要。其中最重要的是显示和处理之间的分离。GWT让这件事变得非常困难。也许不是不可能，但我所在的团队从来没有想出一个好的解决方案，即使我们认为我们有，我们也总是有一个泄漏到另一个。
桌面！=Web
正如@Berin-Loritsch在评论中发布的那样，GWT的模型或心态是为即时应用程序构建的，在即时应用程序中，程序具有与处理引擎紧密耦合的即时显示。这听起来不错，因为这正是许多人认为网络所缺乏的。但有两个问题：A)网络是建立在HTTP上的，这本身就不同。正如我上面提到的，基于HTTP-HTML、CSS，甚至资源加载和缓存(图像等)的技术都是为该平台构建的。B) 一直在web上工作的Java开发人员不容易转换到这种桌面应用程序的心态。这个世界上的建筑是一门完全不同的学科。Flex开发人员可能比Java web开发人员更适合GWT。
最后GWT只需使用Java就可以很容易地生成快速而肮脏的AJAX应用程序。如果快速和肮脏听起来不像你想要的，就不要使用它。我工作的公司是一家非常关心最终产品的公司，它对用户来说是一种视觉和互动的抛光感。对于我们这些前端开发人员来说，这意味着我们需要以使用GWT的方式来控制HTML、CSS和JavaScript，就像在上戴着拳击手套弹钢琴一样
首先，GWT并没有消亡，它的使用量在增加，它的最新版本是2.2。从1.6版本开始，我已经使用GWT两年了。自那以后，它的改进相当惊人。
由于GWT是客户端技术，所以它只会对应用程序的可伸缩性特性产生积极影响。因为jsf、struts、wicket等服务器端web技术是服务器资源的消费者，但gwt不需要任何服务器资源来呈现用户界面。。
但你们的团队也有问题。因为您的团队没有java经验，所以很难适应java和gwt这两种新技术。。如果您有时间学习，我强烈建议您使用GWT。
精通GWT大约需要一年时间。如果您开发了像MicrosoftOffice或PhotoShop这样复杂的应用程序，那么使用GWT是有回报的。将GWT用于小型且相对简单的应用程序IMHO是没有意义的。GWT确实是一个消磨时间的框架，你必须有充分的理由使用它。我认为99%的web应用程序都不需要GWT。
GWT不是垂死的框架，而是消磨时间的框架。它有安全问题。您可以轻松地对GWT应用程序进行CSRF(跨站点请求伪造)请求。此外，Java和Javascript是完全不同的语言，你无法轻松翻译。为了提高生产力，请避免使用GWT。