我的公司正计划开发一个全新的 Web 前端应用程序。
一些背景：
有人建议使用 GWT 而不是 Silverlight 或传统技术（Javascript、jquery、CSS 等）。
我不确定这是否是正确的方法？很多 GWT 新闻来自 2007/2008 年。这让我觉得这项技术已经过时并且可能正在消亡。
如果让你选择，你会选择 GWT 吗？
不幸的是，您的两个陈述在这种情况下是相互排斥的：
我是一名 Java 程序员，在过去一年左右的时间里学习了 GWT。能够使用编译语言和成熟的开发工具直接写入浏览器是非常有效的。我可以比以往更快地完成网络开发（使用 ASP、JSP、ExtJS ...）。
但是，正如其他评论者所说：如果您没有 Java 经验，您会发现在短时间内掌握这两种技术（Java 和 GWT）是一个真正的挑战。如果您确实设法在合理的时间内将其推向市场，我只能想象代码库的状况会很差（因为您会边学习边学习）-这对于您的组织的闪亮新事物来说将是一个非常糟糕的基础冒险。
同样，在您列出的其他相关技能中，您也没有“很多”技能。
我怀疑有一个更有效的解决方案。正如一些聪明的老山羊项目经理所说：
我有三个变量来交付您的项目：时间、成本和质量。随便选两个
在您的情况下，如果组织想要在短时间内获得高质量的产品，则必须补偿成本因素 - 您的组织应该购买一些临时 GWT 专业知识，以便为您提供完善的软件架构并在接下来的几个月内指导您的团队. 之后，您将准备好掌权，通过“站在巨人的肩膀上”继承高质量的代码库。
正如其他人所说，GWT 绝对不是一个垂死的项目。实际上恰恰相反，因为现在 Google 内部有 20 多个定期贡献者（而 2008 年只有半打）。Wave（尽管作为一项 Google 服务已停产，但作为 Apache Foundation 项目仍然存在）、Orkut、AdWords、Google 版主和新的（仍为测试版）Google Groups 是使用 GWT 制作的；Google Buzz 的部分内容和 Google 的其他一些项目也是使用它构建的。
现在至于你的选择：
因此，根据您的需求/愿望和技能，我会选择 GWT 或“一些 JS 工具包”。在任何情况下，您都可以完全控制外观和感觉（除非您选择其中一个臃肿的播放器：ExtJS/ExtGWT、SmartGWT 或类似的；这些播放器的上市时间可能会更短，但您' 稍后会在性能、与其他工具包的集成以及外观方面支付它）。
鉴于你所说的关于你的技能，我肯定会推荐 GWT（尽管你缺乏 Java 经验）；因为缺乏 JavaScript 经验远比缺乏 Java 经验更糟糕（你说的是“大型应用程序”，所以开始正确构建东西和/或拥有帮助重构的工具非常重要，你将拥有与Java）。
@ianmayo 在我写上面的时候回复了，我只能支持他说的！
为了不以上述看似一致的答案误导读者，请在尊重的 stackoverflow 中保持客观的观点，以下评论表达了我使用 GWT 的确切经验。GWT 是否会消亡取决于有多少新应用会采用它，Google 趋势可以看出（gwt 趋势）。
摘自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 个子节点（文本、B、文本）附加到 P 节点。您可以先创建 P，也可以先创建子节点。其中一个子节点可能是函数的返回结果。在与许多开发人员进行了几个月的开发之后，试图通过跟踪 GWT 代码来破译 HTML 文档的外观是一个令人头疼的过程。
最后，团队决定也许对所有 HTML 使用 HTMLPanel 是正确的方法。现在，您已经失去了 GWT 的许多优势，即让 Java 代码可以轻松使用元素以轻松绑定数据。
在 GWT 中使用 CSS 很糟糕。
通过附加到 HTML 抽象，这意味着您必须使用 CSS 的方式也不同。自从我上次使用 GWT（大约 9 个月前）以来，它可能有所改进，但当时，CSS 支持一团糟。由于 GWT 使您创建 HTML 的方式，您经常有一些您不知道被注入的节点级别（任何 CSS 开发人员都知道这会如何显着影响渲染）。嵌入或链接 CSS 的方法太多，导致命名空间混乱。最重要的是，你有精灵支持，这听起来不错，但实际上改变了你的 CSS，我们在编写属性时遇到了问题，我们必须在以后显式覆盖这些属性，或者在某些情况下，阻碍了我们匹配我们的手的尝试-编码 CSS 并且必须以 GWT 没有搞砸的方式重新设计它。
问题的结合，利益的交集
任何语言都会有它自己的一系列问题和利益。是否使用它是基于这些的加权公式。当你有一个抽象时，你得到的是所有问题的结合，以及好处的交集。JavaScript 有它的问题，通常在服务器端工程师中被嘲笑，但它也有很多有助于快速 Web 开发的特性。想想闭包、语法速记、即席对象，所有由 Jquery 完成的东西（如 CSS 选择器的 DOM 查询）。现在忘记在 GWT 中使用它！
关注点分离
我们都知道，随着项目规模的增长，良好的关注点分离至关重要。其中最重要的一项是显示和处理之间的分离。GWT 让这变得非常困难。可能不是不可能，但我所在的团队从来没有想出一个好的解决方案，即使我们认为我们有，我们总是有一个泄漏到另一个。
桌面！=网络
正如@Berin Loritsch 在评论中发布的那样，GWT 的模型或思维模式是为实时应用程序构建的，其中程序具有与处理引擎紧密耦合的实时显示。这听起来不错，因为这就是很多人认为网络所缺乏的。但是有两个问题： A) Web 是建立在 HTTP 之上的，这本质上是不同的。正如我上面提到的，基于 HTTP 的技术——HTML、CSS，甚至资源加载和缓存（图像等），都是为该平台构建的。B) 一直在 Web 上工作的 Java 开发人员不会轻易切换到这种桌面应用程序思维方式。这个世界上的建筑是一门完全不同的学科。Flex 开发人员可能比 Java Web 开发人员更适合 GWT。
综上所述... GWT 能够仅使用 Java 就很容易地生成快速而简单的 AJAX 应用程序。如果快速和肮脏听起来不像你想要的，不要使用它。我工作的公司是一家非常关心最终产品的公司，它对用户来说是视觉和交互的抛光感。对于我们前端开发人员来说，这意味着我们需要以使用 GWT 的方式来控制 HTML、CSS 和 JavaScript，就像戴着拳击手套弹钢琴一样
GWT 绝对不老也不死！Google 自己的很多应用程序都是使用 GWT 开发的。您可以下载GBST 案例研究，了解这家全球金融公司如何使用 GWT 来提高生产力并创造丰富的用户体验。您必须知道，当您使用 GWT 时，您会自动使用 javascript、html 等。您在 java 中创建了一个 gwt 应用程序，但是当您编译它时，gwt 会创建一个包含 html 文件、javascript 代码、css 等的文件夹......
我绝对推荐它！
首先，GWT 不是垂死的技术，它的使用量越来越大，它的最新版本是 2.2。从 1.6 版开始，我使用 GWT 已有 2 年了。它的改进，因为他们是相当惊人的。
由于 GWT 是客户端技术，它确实只会对您的应用程序可伸缩性功能产生积极影响。因为 jsf、struts、wicket 等服务器端 web 技术是服务器资源消费者，但 gwt 不需要任何服务器资源来呈现用户界面。
但是你的团队有问题。因为你的团队没有java经验，所以要适应java和gwt这两种新技术是相当困难的。如果你有时间学习，我强烈推荐GWT。
精通 GWT 大约需要 1 年时间。如果您开发像 MicrosoftOffice 或 PhotoShop 这样复杂的应用程序，则使用 GWT 会有所回报。恕我直言，将 GWT 用于小型且相对简单的应用程序是没有意义的。GWT 确实是一个消磨时间的框架，你必须有非常充分的理由才能使用它。我认为 99% 的网络应用程序不需要 GWT。
GWT 不是消亡的框架，而是消磨时间的框架。它有安全问题。您可以轻松地向 GWT 应用程序发出 CSRF（跨站点请求伪造）请求。此外，Java 和 Javascript 是完全不同的语言，您不能轻易翻译。为了您的生产力，请避免使用 GWT。