小编典典

最大的GWT陷阱?

ajax

我处于我们选择使用GWT实施的项目的开始/中期。是否有人在使用GWT(和GWT-EXT)时遇到无法克服的重大陷阱?从性能角度来看如何?

我们已经看到/听到的几件事已经包括:

  • Google无法将内容编入索引
  • CSS和样式总体上似乎有些不稳定

寻找关于这些项目的任何其他反馈。谢谢!


阅读 252

收藏
2020-07-26

共1个答案

小编典典

我首先要说我是GWT的忠实拥护者,但是是的,有很多陷阱,但是大多数(即使不是全部)我们都能够克服:

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

解决方案:
将您的代码分成单独的模块,并告诉ant仅在更改时才构建它。同样,在开发过程中,仅通过构建一个浏览器就可以大大加快编译速度。您可以通过将其放入.gwt.xml文件中来实现此目的:

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

其中gecko1_8是Firefox 2+,即ie6是IE等。


问题: 托管模式非常慢(至少在OS X上是这样),并且与在编辑JSP或Rails页面之类的东西并在浏览器中刷新时获得的“实时”更改相差甚远。

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

更新:对于GWT2.0+,这不再是问题,因为您使用了新的“开发模式”。基本上,这意味着您可以直接在您选择的浏览器中运行代码,因此不会损失速度,而且您可以对它进行调试/检查等。

http://code.google.com/p/google-web-
toolkit/wiki/UsingOOPHM


问题: GWT代码是Java,与布局HTML页面的思路不同,这使得采用HTML设计并将其变成GWT变得更加困难

解决方案: 您再次习惯了这一点,但是不幸的是,将HTML设计转换为GWT设计总是比将HTML设计转换为JSP页面的速度慢。


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

解决方案: GWT是否会起飞还有待观察,但是如果您是一家由您控制聘用人员的公司,那么您始终可以选择了解GWT或想要学习GWT的人员。


问题: 与jQuery或纯JavaScript相比,GWT是一把大锤。要使其发生,需要花更多的时间进行设置,而不仅仅是添加一个JS文件。

解决方案:
将jquery之类的库用于适合它们的较小,简单的任务。当您想在AJAX中构建真正复杂的东西,或者需要通过RPC机制来回传递数据时,请使用GWT。


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

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

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


我从来没有遇到过CSS样式化小部件(无论是开箱即用,自定义还是其他方式)的问题,所以我不知道这是陷阱是什么意思?

至于性能,我总是发现,一旦编译的GWT代码很快,并且AJAX调用几乎总是比刷新整个页面小,但这并不是GWT真正独特的,尽管如果使用JAVA后端非常紧凑。

2020-07-26