最大的 GWT 陷阱?

我正处于一个项目的开始/中期,我们选择使用 GWT 来实现这个项目。是否有人在使用 GWT (和 GWT-EXT)时遇到过无法克服的主要缺陷?从性能的角度来看怎么样?

我们已经看到或听到的一些事情包括:

  • 谷歌无法索引内容
  • CSS 和样式通常看起来有点古怪

希望您对这些项目有更多的反馈意见。谢谢!

30882 次浏览

没有我无法轻易克服的重大陷阱。请大量使用托管模式。 因为您正在使用 GWT-ext,所以几乎不需要自己动手修改 CSS,除非您想调整开箱即用的外观。

我的建议是使用 GWT“原生”小部件,而不是使用库小部件,因为库小部件的特性非常接近。

研究搜索引擎索引: 是的,网站将不会有可导航的网址正常(除非你只是添加小部件到一个常规网站的元素)。不过,您可以执行历史回退/转发功能。

首先我要说的是,我是 GWT 的铁杆粉丝,但是的确存在许多陷阱,但是大多数(如果不是全部的话)我们都能够克服:

问题: 编译时间长,随着项目的增长,编译所需的时间也越来越长。我听说过20分钟编译的报告,但我的报告平均约1分钟。

解决方案: 将您的代码分割成单独的模块,并告诉 ant 只在它发生变化时才构建它。另外,在开发过程中,您可以通过仅为一个浏览器构建来大大加快编译时间。你可以把这个放进你的。Xml 文件:

<set-property name="user.agent" value="gecko1_8" />

Gecko1 _ 8是 Firefox 2 + ,ie6是 IE 等等。


问题: 托管模式非常缓慢(至少在 OS X 上) ,并且不能匹配当你编辑 JSP 或 Rails 页面并在浏览器中点击刷新时获得的“实时”更改。

解决方案: 你可以给托管模式更多的内存(我通常得到512M) ,但它仍然很慢,我发现一旦你用 GWT 做得足够好,你就停止使用它了。您进行了大量的更改,然后只为一个浏览器进行编译(通常需要20秒的编译时间) ,然后在浏览器中单击刷新。

更新: 对于 GWT 2.0 + ,这不再是一个问题,因为您使用的是新的“开发模式”。它基本上意味着你可以直接在你选择的浏览器中运行代码,所以不会降低速度,而且你还可以调试/检查它,等等。

Http://code.google.com/p/google-web-toolkit/wiki/usingoophm


问题: GWT 代码是 Java,并且在布局 HTML 页面时有不同的思路,这使得采用 HTML 设计并将其转换为 GWT 变得更加困难

解决方案: 同样,您已经习惯了这一点,但不幸的是,将 HTML 设计转换为 GWT 设计总是比将 HTML 设计转换为 JSP 页面要慢。


问题: GWT 需要一些时间来理解,而且还不是主流。这意味着大多数加入您的团队或维护您的代码的开发人员将不得不从头开始学习它

解决方案: GWT 是否会腾飞还有待观察,但是如果你是一家控制你雇佣的人的公司,那么你总是可以选择那些知道 GWT 或者想学习它的人。


问题: 与 jquery 或普通的 javascript 相比,GWT 是一个大锤。要实现这一点,需要进行更多的设置,而不仅仅是包含一个 JS 文件。

解决方案: 使用类似 jquery 的库来完成适合这些任务的小型、简单的任务。当您想要在 AJAX 中构建真正复杂的东西,或者需要通过 RPC 机制来回传递数据时,可以使用 GWT。


问题: 有时为了填充 GWT 页面,需要在页面首次加载时进行服务器调用。当你获取你需要的数据时,用户坐在那里看一个加载符号会很烦人。

解决方案: 对于 JSP 页面,您的页面在变成 HTML 之前就已经由服务器呈现了,因此您可以实际进行所有的 GWT 调用,并将它们预先加载到页面上,以进行即时加载。详情请参阅此处:

通过预序列化 GWT 调用来加速页面加载


我从来没有任何问题 CSS 样式我的小部件,开箱即用,自定义或其他,所以我不知道你是什么意思,这是一个陷阱?

至于性能,我总是发现编译后的 GWT 代码速度很快,AJAX 调用几乎总是小于整个页面刷新,但这并不是 GWT 所独有的,尽管如果使用 JAVA 后端,您得到的本机 RPC 包非常紧凑。

一个主要的缺陷是,有时您需要显式地为最终成为 HTML 元素的元素分配一个 id,以便能够使用某些 CSS 样式。例如: 当 tabPanel 的 tabBar 被分配了一个 id 并且您在那个 elementId 上指定了一个: hover 时,GWT TabPanel 只会在 tabBarItems 上执行: hover。

我在别的地方写过一些其他的 GWT 的缺点,但是它们已经被生锈的书架覆盖了答案:)。

不久前,我在一个项目中同时使用了 GWT 和 GWT-ext。我发现随着网页开发的进行,我的体验相当顺利,但我的建议是:

不要将 GWT 本地小部件与 EXT 小部件混合使用。这是地狱般的混乱,因为通常名称是相同的(GWT.Button 或 GWText。按钮?)

在我身上发生的一件事,真的让代码比我想象的更复杂,那就是我想要一个 A)动态更新 B)可级联的

GWT 本地面板是动态的,Ext 面板是级联的。解决方案? 一个 GWT.VerticalPanel 包装一个 GWTExt 面板..

但是,嘿,这很管用。 ;)

我现在正在做一个项目,它使用 EXTGWT (GXT) ,不要与 GWTEXT 混淆。有一个区别,EXT GWT 实际上是由编写 ExtJS javascript 库的公司生产的。GWTEXT 是围绕 ExtJS 库的 GWT 包装器。GXT 是本机 GWT。

不管怎样,GXT 还是有点不成熟,缺乏一个我认为 GWT EXT 拥有的可靠的社区。然而,GXT 的未来是,因为它是原生的 GWT,实际上是由制造 ExtJS 的公司开发的。由于 ExtJS 库上的许可证发生了变化,GWT EXT 在某种程度上受到了损害,从而减缓了 GWT EXT 的开发。

总的来说,我认为 GWT/GXT 是开发 Web 应用程序的一个很好的解决方案。我其实很喜欢托管模式的开发,它使事情快速和简单。您还可以获得调试代码的好处。使用 JUnit 进行单元测试也非常可靠。我还没有看到一个很棒的 JavaScript 单元测试框架,我认为它足够成熟,可以测试企业应用程序。

关于 GWT EXT 的更多信息: Http://gwt-ext.com/

有关 EXT GWT (GXT)的更多信息: Http://extjs.com/products/gxt/

我们遇到的陷阱:

  • 虽然使用类似 GWT EXT 的工具可以获得很多经验,但任何时候只要在 JavaScript 库上使用这种薄薄的外壳,就会失去调试的能力。我不止一次地把头撞在桌子上,因为我无法检查(在我的 IntelliJ 调试器中) GWT EXT 表类中发生了什么... ... 你所能看到的只是它是一个 JavaScriptObject。这使得我们很难找出问题所在。

  • 你的团队里没有懂 CSS 的人。根据我的经验,这个人不是专家并不重要... 只要他有一些好的工作知识,并且知道在必要时谷歌正确的术语就够了。

  • 跨浏览器调试。关注进程外托管模式[ 1][ 2][ 3] ,希望是 GWT 1.6... 现在,你只需要在托管模式下把事情做好,然后使用“编译/浏览”按钮,在那里你可以玩其他浏览器。对于我来说,在 Windows 上工作,这意味着我可以在 FireFox 中查看我的工作,并使用 FireBug 来帮助调整和改进。

  • IE6.令人惊讶的是 IE6将呈现不同的东西。我已经采取了一种方法,根据浏览器将样式应用到最外面的“ viewport”,这样我就可以使用 CSS 规则,比如:

    .my-style { /* stuff that works most everywhere */ }
    
    
    .msie6 .my-style { /* "override" so that styles work on IE 6 */ }
    

Finally, make sure you use an editor that helps you. I use IntelliJ -- it's got lots of GWT smarts. E.g., If I try to use a class that isn't handled by the JRE emulation, it lets me know; if I specify a style for a widget, and I haven't defined that style yet, the code gets the little red squiggly... Or, when looking at the CSS, it will tell me when I've specified conflicting attributes in a single rule. (I haven't tried it yet, but I understand that version 8 has even better GWT support, like keeping the "local" and "async" RPC interfaces and implementations in sync.)

我们很难将我们的 GWT 代码库与我们从网页设计师那里得到的 HTML 网页模板(我们希望 GWT 管理的带有特定 div id 的静态 HTML 页面)结合起来。至少在我们使用它的时候,我们不能让 GWT 与我们网站中没有用 GWT 编码的部分集成。我们最终还是成功了,但这是个大黑客。

我附议来自 ykagano 的评论,最大的缺点是在 MVC 中失去 V。尽管您可以将真正的 ui 类与客户端代码的其余部分分离开来,但是您不能轻易地使用由图形/Web 设计器生成的 HTML 页面。这意味着您需要一个开发人员将 HTML 转换成 Java。

得到一个 wysiwyg ui 编辑器,它将节省你很多时间。我使用 GWTDesigner。

GWT 最大的优点是能够忘记跨浏览器问题。它不是100% ,但几乎带走所有的痛苦。结合托管模式调试的好处(与 Firebug 相比,Firebug 非常优秀,但与 Java 调试器不同) ,它让开发人员在生成复杂的 ajax 应用程序方面具有巨大的优势。

它在运行时非常快,特别是使用 gzip 过滤器的时候。

稍微偏离主题,但是 irc 上的 # gwt 通道非常有用,以防您遇到持续的问题。

我将在前面提到的基础上再加几点:

  • 数据绑定/验证。GWT 没有现成的数据绑定/验证支持,尽管在这个领域有一些项目开始出现。你会发现自己写了很多这样的东西:
TextField fname, faddress;
...
fname.setText(person.getName());
faddress.setText(person.getAddress());
...
  • 装载缓慢。由于 gwt 位于客户端,因此延迟加载实际上不是一个选项。您必须仔细设计您的 RPC 和域对象,以便
    • 发送所有需要的对象数据
    • 避免急于获取所有数据
    • 您还必须确保不会发送代理/非序列化对象。冬眠可以帮助你解决这些问题。
  • 用 java (面板、按钮等)显示 UI 比用 html 显示更困难。
  • 历史支持。GWT 不附带 History 子系统,也不附带任何用于漂亮 URL 或状态完整书签的子系统。您将不得不自己滚动(尽管它支持 History 标记,这只是一个开始)。这在所有 AJAX 工具包 AFAIK 中都会发生。

恕我直言,GWT 缺少一个支持这个“线程”上提到的所有问题的开箱即用的框架。

  • 必须为每个服务接口编写的 Async 接口看起来像是由 GWT 编译器自动生成的。
  • 对于大型项目来说,编译时间变得很长

但是对于一个大型的 Javascript 项目来说,这是最好的选择

我们已经与 GWT 合作近2年了。我们吸取了很多教训。我们是这样想的:

  1. 不要使用第三方小部件库,特别是 gwt-ext。它将扼杀您的调试、开发和运行时性能。如果你对此有疑问,请直接与我联系。

  2. 使用 gwt 只填充应用程序的动态部分。因此,如果你有一些复杂的用户交互与许多字段。但是,不要使用随之而来的面板。使用现有库存设计器提供的页面。划出包含应用程序控件的区域。将这些控件附加到 onModuleLoad ()中的页。通过这种方式,您可以使用来自设计器的标准页面,并且还可以在 gwt 之外进行所有的样式设计。

  3. 不要将整个应用程序构建为一个标准页面,然后动态构建所有部分。如果你按照我在第二项中的建议去做,这种情况不会发生。如果你动态地构建所有程序,你将会扼杀性能,并且为中型到大型的应用程序消耗大量的内存。而且,如果你按照我的建议去做,后退按钮会非常好用,搜索引擎索引等也会很好用。

其他评论者也提出了一些不错的建议。我使用的经验法则是创建网页,就像你正在做一个标准的网页。然后挖掘出需要动态的部分。用具有 id 的元素替换它们,然后使用 RootPanel.get( id ).add( widget )填充这些区域。

我最近在 GWT 上做了很多工作,我想说的是:

  1. CSS 样式只是有时候比较棘手,在 IE 中使用 IE 开发工具,在 Firefox 中使用 firebug 来弄清楚到底发生了什么,你就会清楚 CSS 需要改变什么
  2. 你可以使用技巧,让谷歌索引它。一个非常著名的网站是 http://examples.roughian.com/检查其在谷歌评级。一个远不那么有名的网站是 Www.salvin.in(忍不住提到这一点) ,我优化了它的话: salvin 主页(搜索这三个词谷歌)

我不太了解 GWT-EXT,但我也相信没有必要包含第三方库。

祝你做出最好的决定:)

GWT 2.0解决了所讨论的许多问题,预计将在未来几个月的某个时候发布。

  • 使用类似 html/xml 的语法创建布局
  • 动态脚本加载-只有基本的 JS 将首先下载。其余将根据需要下载
  • 在浏览器托管模式-这可能会照顾到托管模式的速度问题讨论,在其他好处
  • “编译器优化”-更快的编译,希望如此

GWT 2.0在 Google I/O 上预览视频

重用 RPC 服务对象。
它会导致出现类似应用程序挂起的症状。

GWT 非常简单直观。

尤其是随着 UIBinder 的发布,它允许 GWT 小部件以 XML 格式布局,然后在 Java 中进行编码。

因此,如果您使用过其他 Ajax 或 Flash 设计工具,或 Silverlight 等,那么 GWT 非常容易学习。

主要的障碍(如果不是陷阱的话)是 GWT RPC。您希望使用 GWT 的原因是因为 GWT 异步 RPC。否则,为什么不仅仅依靠 css 来格式化你的页面呢?

GWT RPC 就是这样一个元素,它允许服务器刷新服务器上的数据,而无需刷新页面。这是对诸如股票表现监控(或美国当前的国家和公共债务,或全球未出生婴儿数量的第二次流产)等页面的绝对要求。

GWT RPC 需要花费一些精力才能理解,但是只要花费几个小时,就会完全明白。

除此之外,在努力学习 GWT RPC 之后,您最终发现您不能使用 JSP 作为 RPC 的服务组件,除非... ... 我的博客上有一个关于如何使用 JSP 作为 GWT RPC 服务器的8部分(我认为)系列。不过,既然你们没有问我答案,只是问了一些问题,我就不再为我的博客做广告了。

那么。我非常相信,使用 GWT 的最大障碍/陷阱是找到如何正确地部署 GWT 异步 RPC 以及如何使其能够使用 JSP 服务器。

不是“无法克服”,而是对一些基本的东西有点痛苦。

日期处理:

GWT 使用不推荐的 java.util.Date,这可能导致在客户端处理日期时出现意外行为。GWT 不支持 java.util.Calendar更多信息请点击这里.

相关问题例子:

GWT 的浏览器嗅探代替了特征提取,而且你的应用程序在一些浏览器(特别是新的浏览器)上无法工作

下面是一些关于这个问题的参考资料:

下面是一些关于特征提取的参考资料:

取自 JavaScript 框架的比较-Wikipedia

GWT 2.4已经解决了上面提到的许多问题,一个很棒的小部件库刚刚从 Beta (Ext GWT 3.0.4 a.k.a. GXT)中诞生,它完全是用 GWT 编写的,而不是 JS 库的包装。

余痛:

  • 由于缺乏对 CSS3选择器的支持,在某些情况下可以使用“文字()”来绕过它。
  • 缺乏对 CSS3和现代浏览器事件(如 结束)的支持。
  • 缺乏 JavaCalendar 类支持(多年以后)。
  • JUnit4缺乏支持(5年及以后)。
  • Google GWT 团队缺乏清晰的路线图和发布时间表。

关于 GWT 2.4,使用 Firefox在调试 GWT 时,它比使用 chrome 快得多。 如果您只使用 firefox,可以考虑将这一行放到 Xml文件中

<set-property name="user.agent" value="gecko1_8" />

另外,如果您使用 eclipse,那么在参数下面添加以下参数-> VM 参数:

- Xmx512m-XX: MaxPermSize = 1024m-XX: PermSize = 1024m

您可以划分服务器和客户端,并使用下面的参数-> 程序参数: - codeServerPort 9997-startupUrl http://yourserver/project-noserver

另外,为了防止在每次更改时刷新服务器,请使用 JRebel Http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/ 这是现场演示 Http://www.youtube.com/watch?feature=player_embedded&v=4jggfczspay

我遇到的陷阱 1.在超级开发模式下的不同行为。例如,Someclass.class.getName ()在 Superdev 模式下工作得非常好,并返回类的完全限定名。在生产模式下,这是行不通的。

  1. AddWidget (widget)将调用 widget 的 Removefromrent ()

对于去年发布的 GWT 2.7,GWT 团队做了很多很大的改进。GWT 的一个主要缺点是,在 GWT 2.6及以下版本中编译花费了大量时间。现在 GWT 没有增量编译了,增量编译速度非常快,而且只编译变化。

GWT 2.7现有(来源) :

  • 现在只需要几秒钟就可以增量构建
  • 更紧凑、更精确的 SourceMaps
  • 安全总局的支持
  • JSInterop
  • 出色的 JavaScript 性能
  • 较小的代码大小

获得可靠事实的最好方法是从 重量调查。GWT 最大的问题之一就是编译时间太长。幸运的是,它的改进非常迅速,所以在不久的将来它不会成为一个重要的问题。另一个缺陷是 GWT 要复杂得多,因为 Java 是一种更加复杂的语言,每一步都能抵抗糟糕的程序员。此外,编译增加了一个层。例如,jsinterop 需要一个小样本。最根本的问题是 GWT 的设计并不简单。它是为极其复杂的 Web 应用程序而设计的,整个社区始终将优先级、性能、代码质量、体系结构等等置于易于编码之上。
请记住,您可以在任何时候在 GWT 中使用 js,所以如果您正在与 GWT 斗争,请考虑使用 js。最后,GWT 是 js,因此您可以在 GWT 中做任何在 js 中可以做的事情。实际上,大多数 GWT 项目使用 js。问题是 GWT 要复杂得多。然而,有时候额外的复杂性是值得的。

值得注意的是,GWT 3.0将带来巨大的改进。

GWT 是一个技术杰作。它将客户端和服务器编程结合起来,使其成为一个连贯的应用程序——就像“分层”之前编写软件的方式,以及它应该被编写的方式。它消除了不同的技能集,团队成员之间的沟通不畅,以及整个 Web 设计阶段: 艺术和编程。这也是你最接近手机的方式,比如 Android 开发。事实上,GWT 被设计用来生成不同的本地 UI,而不仅仅是 HTML。尽管它需要大量的纪律来确保这样的解耦——保持您的内部层的表示不可知。

您应该避免的第一个错误是使用第三方扩展(如 EXT-GWT,又名 GXT 和 SmartGWT) ,我花了四年时间才意识到这一点。开始使用它们漂亮的桌面小部件,而不是投资于自己的样式,这是非常诱人的,但我不知道有多少问题,我与 SmartGWT,直到我最终受够了。简而言之,它将核心 GWT 特性集冻结在某个(相当过时的)级别上,然后在此基础上构建。还要记住的是,现在的桌面外观和感觉看起来很傻,更不用说缓慢的性能、大量的 bug 和兼容性特性——尤其是在移动设备上。您希望尽可能靠近本机浏览器控件,例如,下拉列表呈现为本机 < select > 元素,而不是一些自定义绘制的控件。

由于移动设备的发展趋势,整个用户体验变得越来越简单和平滑,所以你不需要做太多的工作来设计一个外观漂亮的应用程序。虽然如果你想要“3D”的外观,也有渐变。CSS3简化了一切,而且 GWT 使用了一种优雅的面向对象方式来包装它,这与原始的 CSS 不同。因此,不要因为在 GWT Showcase 中看到相当丑陋的基本控件而泄气。GWT 团队故意不提供任何样式,因为这是开发人员的工作。

剩下的就是使用强类型 Java 和漂亮简洁的 API 进行的常规浏览器编程。但是当然不要忘记你的代码在浏览器中运行,所以所有的调用都是异步的,例如你不能在循环中调用 GWT-RPC 方法(填充一些列表) ,但是如果你遇到这种情况,需要递归地链接它们。

有一些自称的“反模式”,比如不使用 GWT-RPC。到目前为止对我来说还不错,已经10年了。简单是关键。我不会为了代码的优雅性和可维护性而牺牲一些边际性能。此外,这不是你的瓶颈会-在数据库中。当然要注意发送给客户端的数据量。

如果您无法找到或设计现有的小工具阅读丰富的 HTML5元素集,那么您总是可以包装第三方的元素集。我用流行的 jQuery FullCalendar 做到了这一点。一点都不复杂。谷歌地图和谷歌图表之类的东西都有半官方的 GWT 包装器。

GWT 是完美的。它没有得到足够的关注的唯一原因是因为早期的互联网使用者仍然影响着这个行业,他们并不是来自计算机科学和面向对象的语言来欣赏他们。他们要么有艺术(Photoshop/WordPress)背景,要么有网络(Perl/Python)背景。