什么时候不使用Google Web Toolkit？[关闭]

我正在考虑在一个主要的内部Web应用程序开发项目中使用GWT，即在我眼中，它的主要优势是与Javascript的交叉编译，这将（至少从理论上讲）帮助我的团队将技术堆栈的大小减少一倍。。

但是，像以前一样（像大多数开发人员一样）被烧掉了，我想听听那些确实在GWT的任何问题上实际使用过它的程序员，这些问题可能会阻碍或限制它在某个问题领域内的使用。

反对使用GWT的理由是什么？为什么？

— 贾斯
source

我以为GWT死了。

— 亚伦·麦克弗

@Aaron，真的吗？

— Jas

我个人不推荐GWT。这种想法迫使您投入桌面应用程序的工作，但是在HTML函数中尝试这种方式会给您带来麻烦。我喜欢将编码范例与当前的问题相匹配，而抽象妨碍了我的工作。这就是为什么每次我开始评估它时，我都决定不使用它。

— Berin Loritsch 2011年

@Jas Experience是几年前的事；在婴儿期，当时感觉很生。它改变了吗？也许....但是我正在慢慢地尝试学习框架的基础，而不是依赖框架本身。归根结底，这是一台用于搅打JS的绞肉机；不是说这是一件坏事，而是我想付出努力的地方。选择这些框架中的许多框架是由于缺乏技术X知识或某些知识……但是您最终将需要在某个时间点变得对技术X有所了解。。。

— 亚伦·麦克弗

我对JS非常了解，在那写了一些非常严肃的文章，但是我现在正在运行一个非常关键的项目，由于上下文从Java切换到JS导致的错误，我无法承担初级人员的浪费时间。因此，如果您有GWT为什么不为您工作的真实示例，请进行描述，否则，请不要在假设性和主观色彩的讨论中浪费彼此的时间。

— Jas

Answers:

我回答这个问题既好又不好-好的，因为我之前实际上已经使用过它，而不好的是，在使用GWT之前，我对HTML / CSS / JavaScript很有经验。这让我为使用GWT感到困惑，而其他真正不了解DHTML的Java开发人员可能没有。

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使这变得非常困难。可能并非不可能，但是我所在的团队从来没有想过一个好的解决方案，即使我们认为我们有，也总是会有一个渗入另一个。

桌面！= Web

正如@Berin Loritsch在评论中发布的那样，GWT的模型或思维模式是为实时应用程序而构建的，其中程序的实时显示与处理引擎紧密结合。这听起来不错，因为这就是许多人缺乏网络的感觉。但是有两个问题：A） Web建立在HTTP之上，这本质上是不同的。如上所述，基于HTTP构建的技术-HTML，CSS，甚至资源加载和缓存（图像等）均已针对该平台构建。B）从事网络工作的Java开发人员不会轻易切换到这种桌面应用程序思维方式。在这个世界上，建筑学是一门完全不同的学科。Flex开发人员可能比Java Web开发人员更适合GWT。

结论...

GWT能够仅使用Java即可轻松生成快速且肮脏的AJAX应用程序。如果快捷方式听起来不像您想要的那样，请不要使用它。我所工作的公司是一家非常关心最终产品的公司，它给用户带来视觉和交互式的抛光感。对于我们的前端开发人员来说，这意味着我们需要使用GWT进行控制HTML，CSS和JavaScript的方式，例如尝试戴着拳击手套弹钢琴。

— 妮可
source

我认识到我们选择Wicket而不是GWT的一些原因，这很不适合演示。

— biziclop 2011年

对于FUD -1，我在小型和大型应用程序中使用GWT的经验比肯定的要积极得多。而且我还没有遇到过这些“问题”中的一个，因此FUD发表了意见。我们只需花费很少的精力就将GWT生成的小部件成功地嵌入到非常复杂的HTML页面中。如果您知道自己在做什么，那就太好了，如果您不想考虑可能会有一种新的更好的做事方法，请遵循此“答案”，而忽略此评论。

@Jarrod这些不是遇到的“问题”，而是对GWT本质的简单描述。在相关的情况下，我进一步将其限定为负面因素，特别是在我们项目目标的范围内。如果您有其他经验，请随时写下。在此之前，唯一未经证实的信息是您声称GWT是“新的和更好的”。顺便说一句-自从我写了这个答案以来，该公司（我已经不再为之工作）花了一年多的工程师工作，并在没有GWT的情况下重写了该项目。用更少的时间。

— 妮可（Nicole）

@JarrodRoberson我同意NickC，非常高兴阅读同样详尽的经验文章。

— funkybro 2012年

@NickC“用更少的时间”来重写项目对GWT IMO并不构成沉重打击；任何您基本上重复执行以前在不同框架或语言下所做的工作的项目，都应花费“较少的时间”。

— funkybro 2012年

我们将GWT用于大型电子政务Web应用程序（后端SOA），该应用程序使用率很高。旧的UI使用DHTML，但是我们在浏览器兼容性，性能优化和开发过程方面存在问题，因此我们寻找替代方案。

我们的要求是：

客户端UI层以最大程度地减少服务器负载
浏览器兼容性
基于网络的RIA
简单的性能优化
无需安装客户端插件，应与纯Windows安装一起使用

我们选择了GWT，我永远不会后悔。新团队几乎没有DHMTL经验，因此GWT的Java开发过程非常有帮助。您所获得的是：

浏览器兼容性
基于Java的开发过程和代码重用
轻松最小化请求（图像包，...）
简便的主动缓存（新的应用程序完全在客户端缓存）
轻松压缩所有资源（即使使用旧的越野车IE上的JS）
还有很多，这里要多说

我们的应用程序在启动时仅向服务器发出一个请求。不利的一面是，GWT（以及Android）开箱即用的设计很差，但是无论如何，如果您应用自己的外观和感觉，就必须适应CSS。另外，您可以为GWT使用各种组件库，从而可以轻松应用适当的样式和主题。

对我而言，毫无疑问，HTML DOM可能不如手工制作的好，这从来都不是问题。当我用C ++开发时，我不会查看生成的汇编代码。当我在GWT中进行开发时，我从来没有理由要查看JS代码，而没有理由要查看DOM并进行一些重构。

对我来说，GWT是RIA开发的唯一选择，我希望GWT拥有光明的未来。请参阅以下任务说明：

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

但是，不要忘了Google在其许多内部项目中并未使用GWT，并且目前关于GWT的未来有一些传言，请参见

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

— 克莱普
source