我的公司正计划开发一个全新的Web前端应用程序.
一些背景:
有人建议使用GWT而不是Silverlight或传统技术(Javascript,jquery,CSS等).
我不确定这是否是正确的方法？很多GWT新闻来自2007/2008.这让我觉得这项技术已经老了,也许正在消亡.
如果您有选择,您会选择GWT吗？
ian*_*ayo 18
遗憾的是,在这种情况下,你的两个陈述是相互排斥的:
我是一名Java程序员,在过去一年左右的时间里已经获得了GWT.能够使用编译语言和成熟的开发工具直接写入浏览器是非常有效的.我可以比以前更快地通过Web开发(使用ASP,JSP,ExtJS ......).
但是,正如其他评论者所说:如果你没有Java经验,你会发现在短时间内接受这两种技术(Java和GWT)是一个真正的挑战.如果你确实设法在合理的时间内将它推向市场,我只能想象代码库会处于非常糟糕的状态(因为你会像往常一样学习) - 这对你的组织来说是一个非常糟糕的基础合资企业.
同样,你在其他相关技能中也没有很多技能.
我怀疑有一个更有效的解决方案.正如一位聪明的老山羊项目经理所说:
我有三个变量来交付您的项目:时间,成本和质量.挑选任何两个
在您的情况下,如果组织希望在短时间内获得高质量的产品,则必须补偿成本因素 - 您的组织应该购买一些临时GWT专业知识,为您提供完善的软件架构,并在未来几个月内指导您的团队.在此之后,你将准备好接受统治,通过"站在巨人的肩膀上"继承一个高质量的代码库.
Tho*_*yer 12
正如其他人所说,GWT绝对不是一个垂死的项目.实际上恰恰相反,因为现在有超过20个来自Google内部的常规贡献者(而2008年则是半数以上).Wave(尽管已停止作为Google服务,它仍然是一个Apache基金会项目),Orkut,AdWords,Google版主和新的(仍测试版)Google网上论坛都是用GWT制作的; Google Buzz的部分内容以及谷歌的其他一些项目也是用它构建的.
现在您的选择:
因此,根据您的需求/需求和技能,我会选择GWT或"一些JS工具包".在任何情况下,你都可以完全控制外观(除非你选择一个膨胀的玩家:ExtJS/ExtGWT,SmartGWT或类似的;你可能会缩短这些产品的上市时间,但是你在性能,与其他工具包的集成以及外观方面,我会稍后付款.
根据你对你技能的评价,我肯定会推荐GWT(尽管你缺乏Java经验); 因为缺乏JavaScript经验比缺乏Java经验更糟糕(你说的是"大型应用程序",所以开始正确构建和/或拥有帮助重构的工具非常重要,你将拥有用Java).
@ianmayo在我写这篇文章时回答说,我只能说出他说的话!
小智 6
为了不使用上述看似一致的答案误导读者,请在尊重的stackoverflow中保持客观视图,以下评论表达了我使用GWT时的确切经验.GWT是否正在消亡取决于有多少新应用程序将采用它,谷歌趋势可以告诉(gwt趋势).
摘录自https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkit
>回答这个问题我既好又坏 - 好,因为我以前实际使用过它,而且很糟糕,因为在使用GWT之前我对HTML/CSS/JavaScript很有经验.这让我感到很疯狂,因为使用GWT的方式可能不是真正了解DHTML的其他Java开发人员.
GWT做了它所说的 - 它将JavaScript和某种程度上的HTML抽象为Java.对许多开发者来说,这听起来很棒.然而,我们知道,正如杰夫阿特伍德所说,所有的抽象都是失败的抽象(如果考虑GWT,值得一读).使用GWT,这特别引入了以下问题:
在GWT中使用HTML很糟糕.
正如我所说,在某种程度上,甚至抽象HTML.这对Java开发人员来说听起来不错.但事实并非如此.HTML是一种文档标记格式.如果要创建Java对象以定义文档,则不会使用文档标记元素.这令人抓狂.它也不够控制.在HTML中基本上有一种写入
<p>Hello how are <b>you</b>?</p>
GWT的方法,你有3个子节点(文本,B,文本)连接到P节点.您可以先创建P,也可以先创建子节点.其中一个子节点可能是函数的返回结果.在与许多开发人员进行了几个月的开发之后,尝试通过跟踪GWT代码来破译HTML文档的样子是一个令人头痛的过程.
最后,团队决定将HTMLPanel用于所有HTML是正确的方法.现在,您已经失去了GWT的许多优点,即Java代码可以轻松地为数据绑定元素.
在GWT中使用CSS很糟糕.
通过附加到HTML抽象,这意味着您必须使用CSS的方式也不同.自从我上次使用GWT(大约9个月前)以来它可能已经有所改进,但当时CSS支持是一团糟.由于GWT使您创建HTML的方式,您通常会注入您不知道的节点级别(任何CSS开发人员都知道这会如何显着影响渲染).嵌入或链接CSS的方法太多,导致名称空间混乱.最重要的是你有精灵支持,这听起来不错,但实际上你的CSS发生了变化,我们遇到了编写属性的问题,然后我们必须明确地覆盖它们,或者在某些情况下,阻止我们尝试匹配我们的手 - 编码CSS并且必须以GWT没有搞砸的方式重新设计它.
问题的结合,利益的交叉
任何语言都会有自己的一系列问题和好处.您是否使用它是基于这些的加权公式.当你有一个抽象时,你得到的是所有问题的结合,以及各种好处的交集.JavaScript存在问题,并且通常受到服务器端工程师的嘲笑,但它也有很多有助于快速Web开发的功能.想想闭包,语法简写,ad-hoc对象,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并不是消亡的技术，它的使用量在增加，最新版本是2.2。从 1.6 版本开始，我使用 GWT 已有 2 年了。自它们以来它的改进是相当惊人的。
由于 GWT 是客户端技术，因此它只会对应用程序可扩展性功能产生积极影响。因为jsf、struts、wicket等服务器端Web技术都是服务器资源消耗者，但gwt不需要任何服务器资源来渲染用户界面。
但你的团队有问题。因为你们的团队没有java经验，自己去适应java和gwt这两项新技术是相当困难的。如果你们有时间学习，我强烈建议GWT。