it-swarm.cn

什么时候不使用Google Web Toolkit?

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

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

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

55
Jas

我回答这个问题既好又不好-好的,因为我之前实际上已经使用过它,而不好的是,在使用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的方法太多,导致名称空间混乱。最重要的是,您还提供了Sprite支持,听起来还不错,但实际上使您的CSS发生了变化,我们在编写属性时遇到了问题,后来我们不得不显式覆盖这些属性,或者在某些情况下,阻碍了我们匹配手形的尝试。对CSS进行编码,并且只需要以GWT不会搞砸的方式对其进行重新设计。

问题的结合,利益的交集

任何语言都会有自己的问题和好处。是否使用它是基于这些的加权公式。当您拥有抽象时,所得到的就是所有问题的结合,以及收益的交叉。 JavaScript有它的问题,通常在服务器端工程师中被嘲笑,但是它也具有许多有助于快速Web开发的功能。考虑闭包,语法简写,即席对象,所有由Jquery完成的工作(例如CSS选择器进行的DOM查询)。现在忘了在GWT中使用它!

关注点分离

我们都知道,随着项目规模的扩大,良好的关注点分离至关重要。最重要的之一是显示和处理之间的分离。 GWT使这变得非常困难。可能并非不可能,但是我所在的团队从来没有想出一个好的解决方案,即使我们认为我们有,也总是会有一个泄漏到另一个泄漏。

桌面!= Web

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

结论...

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

84
Nicole

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

我们的要求是:

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

我们选择了GWT,我永远不会后悔。新团队几乎没有DHMTL经验,因此Java GWT的开发过程)很有帮助。

  • 浏览器兼容性
  • 基于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

24
ChrLipp