最大的 GWT 陷阱? [英] Biggest GWT Pitfalls?
问题描述
我正处于我们选择使用 GWT 实施的项目的开始/中期.有没有人在使用 GWT(和 GWT-EXT)时遇到过无法克服的主要陷阱?从性能角度来看如何?
我们已经看到/听到的一些事情包括:
- Google 无法将内容编入索引
- CSS 和样式总体上似乎有点不稳定
也在寻找有关这些项目的任何其他反馈.谢谢！
我首先要说我是 GWT 的忠实粉丝，但是确实有很多陷阱，但我们能够克服大部分(如果不是全部):
问题: 编译时间长，随着项目的增长，编译它所需的时间也会增加.我听说过 20 分钟编译的报告，但我的平均大约是 1 分钟.
解决方案: 将您的代码拆分为单独的模块，并告诉 ant 仅在更改时构建它.此外，在开发过程中，您可以通过仅针对一个浏览器进行构建来大幅加快编译时间.您可以通过将其放入 .gwt.xml 文件来实现:
其中 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 或想要了解 GWT 的人学习一下.
<小时>问题:与 jquery 或纯 javascript 之类的东西相比，GWT 是一个大锤.它需要更多的设置才能实现，而不仅仅是包含一个 JS 文件.
解决方案:将 jquery 之类的库用于适合这些任务的更小、更简单的任务.当您想在 AJAX 中构建真正复杂的东西时，或者您需要通过 RPC 机制来回传递数据时，请使用 GWT.
<小时>问题:有时为了填充您的 GWT 页面，您需要在页面首次加载时进行服务器调用.当您获取所需数据时，用户坐在那里观看加载符号可能会很烦人.
解决方案:在 JSP 页面的情况下，您的页面在变成 HTML 之前已经由服务器呈现，因此您可以实际进行所有 GWT 调用，并将它们预加载到页面，即时加载.详情请看这里:
<小时>我从来没有遇到过任何 CSS 样式我的小部件的问题，开箱即用，自定义或其他方式，所以我不知道你所说的陷阱是什么意思?
至于性能，我一直发现一旦编译的 GWT 代码很快，而且 AJAX 调用几乎总是比刷新整个页面要小，但这并不是 GWT 独有的，尽管您得到的本地 RPC 数据包如果您使用 JAVA 后端，则非常紧凑.
I'm at the beginning/middle of a project that we chose to implement using GWT. Has anyone encountered any major pitfalls in using GWT (and GWT-EXT) that were unable to be overcome? How about from a performance perspective?
A couple things that we've seen/heard already include:
- Google not being able to index content
- CSS and styling in general seems to be a bit flaky
Looking for any additional feedback on these items as well. Thanks!
I'll start by saying that I'm a massive GWT fan, but yes there are many pitfalls, but most if not all we were able to overcome:
Problem: Long compile times, as your project grows so does the amount of time it takes to compile it. I've heard of reports of 20 minute compiles, but mine are on average about 1 minute.
Solution: Split your code into separate modules, and tell ant to only build it when it's changed. Also while developing, you can massively speed up compile times by only building for one browser. You can do this by putting this into your .gwt.xml file:
<set-property name="user.agent" value="gecko1_8" />
Where gecko1_8 is Firefox 2+, ie6 is IE, etc.
Problem: Hosted mode is very slow (on OS X at least) and does not come close to matching the 'live' changes you get when you edit things like JSPs or Rails pages and hit refresh in your browser.
Solution: You can give the hosted mode more memory (I generally got for 512M) but it's still slow, I've found once you get good enough with GWT you stop using this. You make a large chunk of changes, then compile for just one browser (generally 20s worth of compile) and then just hit refresh in your browser.
Update: With GWT 2.0+ this is no longer an issue, because you use the new 'Development Mode'. It basically means you can run code directly in your browser of choice, so no loss of speed, plus you can firebug/inspect it, etc.
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
Problem: GWT code is java, and has a different mentality to laying out a HTML page, which makes taking a HTML design and turning it into GWT harder
Solution: Again you get used to this, but unfortunately converting a HTML design to a GWT design is always going to be slower than doing something like converting a HTML design to a JSP page.
Problem: GWT takes a bit of getting your head around, and is not yet mainstream. Meaning that most developers that join your team or maintain your code will have to learn it from scratch
Solution: It remains to be seen if GWT will take off, but if you're a company in control of who you hire, then you can always choose people that either know GWT or want to learn it.
Problem: GWT is a sledgehammer compared to something like jquery or just plain javascript. It takes a lot more setup to get it happening than just including a JS file.
Solution: Use libraries like jquery for smaller, simple tasks that are suited to those. Use GWT when you want to build something truly complex in AJAX, or where you need to pass your data back and forth via the RPC mechanism.
Problem: Sometimes in order to populate your GWT page, you need to make a server call when the page first loads. It can be annoying for the user to sit there and watch a loading symbol while you fetch the data you need.
Solution: In the case of a JSP page, your page was already rendered by the server before becoming HTML, so you can actually make all your GWT calls then, and pre-load them onto the page, for an instant load. See here for details:
Speed up Page Loading by pre-serializing your GWT calls
I've never had any problems CSS styling my widgets, out of the box, custom or otherwise, so I don't know what you mean by that being a pitfall?
As for performance, I've always found that once compiled GWT code is fast, and AJAX calls are nearly always smaller than doing a whole page refresh, but that's not really unique to GWT, though the native RPC packets that you get if you use a JAVA back end are pretty compact.
这篇关于最大的 GWT 陷阱?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
