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:
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.
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:
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.
I'm working on a project right now that uses EXT GWT (GXT) not to be confused with GWT EXT. There is a difference, EXT GWT is the one that is actually produced by the company that wrote ExtJS the javascript library. GWT EXT is a GWT wrapper around the ExtJS library. GXT is native GWT.
Anyways, GXT is still somewhat immature and lacks a solid community that I feel GWT EXT has. However, the future is with GXT, as it's native GWT and actually developed by the company that made ExtJS. GWT EXT is somewhat crippled as the license changed on the ExtJS library, thus slowing the development of GWT EXT.
Overall, I think GWT/GXT is a good solution for developing a web application. I actually quite like hosted mode for development, it makes things quick and easy. You also get the benefit of being able to debug your code as well. Unit testings with JUnit is pretty solid as well. I haven't yet seen a great JavaScript unit testing framework that I felt was mature enough for testing an enterprise application.
No major pitfalls that I haven't been able to overcome easily. Use hosted mode heavily.
As you are using GWT-ext you will almost never need to touch CSS yourself unless you want to tweak the out of the box look.
My recommendation is to use a GWT "native" widget over a library one where they are close in features.
Re search engine indexing: yes the site will not have navigable URLs normally (unless you are only adding widgets to elements of a regular web site). You can do history back/forward functionality though.
I used GWT and GWT-ext together on a project a while ago. I found the experience quite smooth as web development goes, but my advice would be this:
Don't mix GWT native widgets with EXT widgets. It's confusing as hell, since usually the names are the same (GWT.Button or GWText.Button?)
One thing that happened to me that really made the code more complex than I'd like, was that I wanted a Panel that was
a) dynamically updatable
b) cascadable
GWT native panels are dynamic, Ext panels are cascadable. Solution? A GWT.VerticalPanel wrapping a GWTExt Panel... Chaos. :)
I second the comment from ykagano, the biggest disadvantage is losing the V in MVC. Although you can separate the true ui class from the rest of your client side code, you cannot easily use an HTML page generated by a graphic/web designer. This means you need a developer to translate HTML into java.
Get a wysiwyg ui editor, it will save you lots of time. I use GWTDesigner.
The biggest upside of GWT is being able to forget about cross browser issues. Its not 100% but takes almost all that pain away. Combined with the benefit of hosted mode debugging (as opposed to Firebug which is excellent but not the same as a java debugger) it gives the developer a huge advantage in generating complex ajax apps.
Oh and its fast at runtime, especially if you use a gzip filter.
Especially with the release of UIBinder to allow GWT widgets to be laid out in XML and then coded-behind in Java.
So if you have used other Ajax or Flash design tools, or Silverlight, etc, GWT is very easy to learn.
The major hurdle, if not pitfall, is GWT RPC. The very reason you wish to use GWT is because of GWT async RPC. Otherwise, why not just rely on css to format your page?
GWT RPC is that element that allows your server to refresh data on your server without having to refresh the page. This is an absolute requirement for pages such as stock performance monitoring (or the current national and public debt of the US or the number of unborn babies aborted worldwide by the second).
GWT RPC takes some effort to understand but given a few hours, it should come all clear.
Above that, after putting in some effort to learn GWT RPC, you finally discover that you cannot use JSPs as the service component for RPC, unless ... I have an 8 part (I think) series on my blog on how to use JSP as the GWT RPC servicer. However, since you had not asked for answers but just issues, I shall desist from advertising my blog.
So. I very much believe that the worst roadblocks/pitfalls to using GWT is finding out how to properly deploy GWT async RPC and how to enable it to use JSP servicers.
我们很难将 GWT 代码库与从网页设计师处获得的 HTML Web 模板(具有我们希望 GWT 管理的特定 div id 的静态 HTML 页面)结合起来。 至少在我们使用它时,我们无法让 GWT 与我们网站上未使用 GWT 编码的部分集成。 我们最终让它工作了,但这是一个很大的黑客攻击。
We've had a very hard time marrying our GWT codebase with HTML web templates that we got from a web designer (static HTML pages with specific div ids that we wanted GWT to manage). At least back when we used it, we couldn't get GWT to integrate with parts of our website that were not coded in GWT. We had it working eventually, but it was a big hack.
The Async interface you have to write for each service interface looks like something that could have been automatically generated by the GWT compiler.
Compile times become long for large projects
But for a large Javascript project it's the best choice
GWT 2.4 has fixed many of the aforementioned issues and a great widget library is just coming out of Beta (Ext GWT 3.0.4 a.k.a. GXT), which is written completely in GWT, not a wrapper of a JS lib.
Remaining pain:
Lack of CSS3 selector support, you can use "literal()" in some cases to get around it.
Lack of support for CSS3 and modern browser events like transitionEnd.
Lack of Java Calendar class support (many years later).
Lack of JUnit4 support (5 years and counting).
Lack of clear road map and release schedule from Google GWT team.
Regarding GWT 2.4, Use Firefox when debugging GWT, it alot more faster then using chrome.
And if you'll using only firefox, consider putting this line in your project.gwt.xml file
Also, If you're using eclipse, then add the following under arguments -> VM arguments:
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
You can divide your server and client, and use the following under arguments -> Program arguments: -codeServerPort 9997 -startupUrl http://yourserver/project -noserver
One major pitfall is that sometimes you need to explicitly assign an id to what ultimately becomes an HTML element to be able to use certain CSS styles. For instance: a GWT TabPanel will only do :hover over tabBarItems when the tabBar of the tabPanel has been assigned an id and you specify a :hover on that elementId.
I wrote about some other disadvantages of GWT elsewhere, but they are already covered by rustyshelfs answer :).
I have done a lot of work on GWT recently, and this is wht i have to say:
CSS styling is tricky only sometimes, use IE developer tool in IE and firebug in Firefox to figure out what exactly is happening and you will get a clear idea of what css needs to be changed
You can use tricks to get google to index it. A very famous site is http://examples.roughian.com/ check its ratings at google. A far less famous site is www.salvin.in (couldnt resist to mention that), i optimised it to words: salvin home page (search google for these three words)
I do not know much about GWT-EXT, But i too am of the belief that there is no need to include Third party libraries.
The GWT team make a lot of great improvements in to last year releasing GWT 2.7. One major weakness of GWT was that compilation takes to much time in GWT 2.6 and below. This is now gone GWT has not incremental compile which is super fast and compiles only the changes.
The best way to get reliable facts are from the gwt survey. One of the biggest issues with GWT has always been a long compile time. Fortunately, it's improving very quickly so it won't be a significant issue in the near future. Another pitfall is that GWT is dramatically more complicated because Java is a more complicated language that resists bad coders every step of the way. In addition, compiling adds a layer. For example, js interop requires a little boilerplate. The fundamental issue is that GWT wasn't designed to be simple. It was designed from the ground up for extremely complicated web apps and the entire community consistently prioritizes, performance, code quality, architecture etcetera over easy coding.
Remember that you can use js in GWT at any point so if you are struggling with GWT consider using js. At the end of the day GWT is js so you can do anything in GWT that you can in js. In fact, most GWT projects use js. The problem is that GWT is drastically more complicated. Nevertheless, it's sometimes worth the extra complexity.
It's worth noting that GWT 3.0 will bring massive improvements.
Pitfalls I ran into
1. Different behaviour in superdev mode. E.g. Someclass.class.getName() works absolutely fine in Superdev mode and returns the fully qualified name of the class. In productive mode this does not work.
addWidget(widget) will call widget's removefromparent()
GWT is a technology masterpiece. It unites client and server programming making it one coherent application - the way software was written before "layering", and the way it should be written. It eliminates different skills sets, miscommunication between team members, and generally the whole Web Design phase: both the artistic and programming. And it is the closest you'd get to mobile e.g. Android development. In fact GWT was designed to generate different native UIs, not just HTML. Though it requires enormous discipline to ensure such decoupling - to keep your inner layers presentation-agnostic.
The first mistake you should avoid, which took me four years to realize, is using third-party extensions like EXT-GWT aka GXT and SmartGWT. It is very tempting to start using their pretty desktopish widgets instead of investing in your own styling, but I cannot tell how many problems I had with SmartGWT until I finally got fed up. In short it freezes the core GWT feature set at the certain (pretty outdated) level and then builds on top of it. Also keep in mind, that chiseled desktop look and feel looks silly nowadays, not to mention the sluggish performance, tons of bugs, and compatibility features - especially on mobile devices. You want to stay as close to the native browser controls, as possible i.e. dropdowns rendered as native <select> elements, not some custom-painted controls.
Thanks to mobile trends the whole UX is becoming simpler and flatter, so you don't need to do much to style a sharp-looking application. Though if you want "3D" look, there are also gradients. CSS3 made everything easy, and GWT wraps it an elegant object-oriented manner unlike the raw CSS. So don't be discouraged by looking at rather ugly barebones controls in the GWT Showcase. The GWT team intentionally didn't offer any styling, because it it the developer's job.
The rest is pretty much conventional browser programming in strongly typed Java with beautiful concise APIs. But of course never forgetting your code runs inside the browser, so all of the calls are asynchronous e.g. you cannot call GWT-RPC methods in a loop (to populate some list), but need to recursively chain them if you ever come to to this situation.
There are some self-proclaimed "anti-patterns" like don't use GWT-RPC. It's been good to me so far: for 10 years. Simplicity is key. I wouldn't think even a second to sacrifice some marginal performance for code elegance and maintainability. besides this is not where your bottlenecks would be - in the database. Of course mind how much data you are sending to the client.
And if you cannot find or style the existing gadget - read rich HTML5 element set, you can always wrap a third-party one. I did it with a popular jQuery FullCalendar. Not rocket science at all. Everything else like Google Maps and Google Charts has semi-official GWT wrappers.
GWT is perfect. The only reason it doesn't get enough love is because early Internet adopters who still influence the industry didn't come from Computer Science and object-oriented languages to appreciate them. They have either artistic (Photoshop/WordPress) or network (Perl/Python) background.
其他评论者也有一些很好的建议。 我使用的经验法则是像创建标准网页一样创建页面。 然后切出需要动态的部分。 将它们替换为具有 id 的元素,然后使用 RootPanel.get( id ).add( widget ) 填充这些区域。
We have been working with gwt for almost 2 years. We have learned a lot of lessons. Here is what we think:
Dont use third party widget libraries especially gwt-ext. It will kill your debugging, development and runtime performance. If you have questions about how this happens, contact me directly.
Use gwt to only fill in the dynamic parts of your apps. So if you have some complex user interactions with lots of fields. However, don't use the panels that come with it. Take your existing stock designer supplied pages. Carve out the areas that will contain the controls for your app. Attach these controls to the page within onModuleLoad(). This way you can use the standard pages from your designer and also do all the styling outside the gwt.
Don't build the entire app as one standard page that then dynamically builds all the pieces. If you do what I suggest in item 2, this won't happen anyway. If you build everything dynamically you will kill performance and consume huge amounts of memory for medium to large apps. Also, if you do what I am suggesting, the back button will work great, so will search engine indexing etc.
The other commenters also had some good suggestions. The rule of thumb i use is to create pages like you were doing a standard web page. Then carve out the pieces that need to be dynamic. Replace them with elements that have id's and then use RootPanel.get( id ).add( widget ) to fill those areas in.
While you can get a lot of mileage from using something like GWT EXT, any time you use this sort of thin veneer on top of a JavaScript library, you lose the ability to debug. More than once I've bashed my head on the desk because I cannot inspect (inside my IntelliJ debugger) what's happening in the GWT EXT table class... All you can see is that it's a JavaScriptObject. This makes it quite difficult to figure out what's gone wrong...
Not having someone on your team who knows CSS. From my experience, it didn't matter that the person wasn't expert...it's enough that he has some good working knowledge, and knows the right terms to google when necessary.
Debugging across browsers. Keep an eye on Out of Process Hosted Mode[1][2][3], hopefully coming in GWT 1.6... For now, you just have to get things good with hosted mode, then use the "Compile/Browse" button, where you can play with other browsers. For me, working on Windows, this means I can view my work in FireFox, and use FireBug to help tweak and make things better.
IE6. It's amazing how different IE 6 will render things. I've taken the approach of applying a style to the outermost "viewport" according to the browser so that I can have CSS rules like:
.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.)
Not "unable to be overcome" but a bit of a pain for something basic.
Date handling:
GWT uses the deprecated java.util.Date which can lead to unexpected behaviour when dealing with dates on the client side. java.util.Calendar is not supported by GWT. More info here.
I'll add some points to the ones already mentioned:
Databinding/validation. GWT doesn't have a databinding/validation support out of the box, although there are some projects on this area starting to emerge. You'll find yourself writing alot of this:
Lazy loading. Since gwt is on the client side, lazy loading is really not an option. You'll have to design your RPCs and Domain Objects carefully in order to
send all your object data that is needed
avoid eager fetching all of your data
You'll have also to make sure that you will not send proxies/non serializable objects. hibernate4gwt can help you with these points.
UI design. It is harder to visualize an UI in java (Panels, Buttons, etc) than in html.
History support. GWT does not ship with a History subsystem, nor does it ship with any subsystem for nice urls or statefull bookmarking. You'll have to roll your own (although it has support for History tokens, which is a start). This happens with all AJAX toolkits AFAIK.
IMHO, GWT is missing a framework that has out of the box support for all of the issues mentioned on this 'thread'.
发布评论
评论(24)
首先我要说的是,我是 GWT 的忠实粉丝,但是,确实有很多陷阱,但大多数(如果不是全部的话)我们都能够克服:
问题: 随着项目的增长,编译时间很长编译它所需的时间也是如此。 我听说过 20 分钟编译的报告,但我的平均约为 1 分钟。
解决方案:将代码拆分为单独的模块,并告诉 ant 仅在更改时才构建它。 此外,在开发时,您可以通过仅针对一种浏览器进行构建来大大加快编译时间。 您可以通过将其放入 .gwt.xml 文件中来实现此目的:
其中 gecko1_8 是 Firefox 2+,ie6 是 IE 等。
问题: 托管模式非常慢(至少在 OS X 上)并且与您编辑 JSP 或 Rails 页面等内容并在浏览器中点击刷新时获得的“实时”更改相差甚远。
解决方案:您可以为托管模式提供更多内存(我通常为 512M),但它仍然很慢,我发现一旦您对 GWT 足够好,您就停止使用它。 您进行大量更改,然后仅针对一个浏览器进行编译(通常需要 20 秒的编译时间),然后只需在浏览器中点击刷新即可。
更新:对于 GWT 2.0+,这不再是问题,因为您使用新的“开发模式”。 它基本上意味着您可以直接在您选择的浏览器中运行代码,因此不会损失速度,而且您可以使用 firebug/inspect 它等。
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
问题: GWT 代码是 java,并且对布局 HTML 页面有不同的心态,这使得采用 HTML 设计并将其转换为 GWT 变得更加困难
解决方案:您再次习惯了这一点,但不幸的是将 HTML 设计转换为GWT 设计总是比将 HTML 设计转换为 JSP 页面之类的操作慢。
问题:GWT 需要一些时间来理解,而且还不是主流。 这意味着大多数加入您的团队或维护您的代码的开发人员都必须从头开始学习
解决方案:GWT 是否会成功还有待观察,但如果您是一家控制谁的公司如果您聘用了 GWT,那么您始终可以选择了解 GWT 或想要学习 GWT 的人员。
问题:与 jquery 或普通 javascript 相比,GWT 是一把大锤。 需要更多的设置才能实现这一点,而不仅仅是包含 JS 文件。
解决方案:使用 jquery 等库来完成适合这些任务的较小、简单的任务。 当您想要在 AJAX 中构建真正复杂的东西,或者需要通过 RPC 机制来回传递数据时,请使用 GWT。
问题:有时,为了填充 GWT 页面,您需要在页面首次加载时进行服务器调用。 当您获取所需数据时,用户坐在那里看着加载符号可能会很烦人。
解决方案:对于 JSP 页面,您的页面在变成 HTML 之前就已经由服务器呈现,因此您实际上可以进行所有 GWT 调用,并将它们预加载到页面上,以便瞬时负载。 有关详细信息,请参阅此处:
通过预序列化 GWT 调用来加速页面加载
我从来没有遇到过任何 CSS 样式问题,开箱即用,自定义或其他,所以我不知道你所说的陷阱是什么意思?
至于性能,我总是发现编译后的 GWT 代码速度很快,而且 AJAX 调用几乎总是比整个页面刷新要小,但这并不是 GWT 所独有的,尽管使用本机 RPC 数据包时会得到JAVA后端非常紧凑。
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:
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.
我现在正在开发一个使用 EXT GWT (GXT) 的项目,不要与 GWT EXT 混淆。 有一个区别,EXT GWT 实际上是由编写 ExtJS javascript 库的公司生产的。 GWT EXT 是 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/
I'm working on a project right now that uses EXT GWT (GXT) not to be confused with GWT EXT. There is a difference, EXT GWT is the one that is actually produced by the company that wrote ExtJS the javascript library. GWT EXT is a GWT wrapper around the ExtJS library. GXT is native GWT.
Anyways, GXT is still somewhat immature and lacks a solid community that I feel GWT EXT has. However, the future is with GXT, as it's native GWT and actually developed by the company that made ExtJS. GWT EXT is somewhat crippled as the license changed on the ExtJS library, thus slowing the development of GWT EXT.
Overall, I think GWT/GXT is a good solution for developing a web application. I actually quite like hosted mode for development, it makes things quick and easy. You also get the benefit of being able to debug your code as well. Unit testings with JUnit is pretty solid as well. I haven't yet seen a great JavaScript unit testing framework that I felt was mature enough for testing an enterprise application.
For more information on GWT EXT:
http://gwt-ext.com/
For more information on EXT GWT (GXT):
http://extjs.com/products/gxt/
没有我无法轻松克服的重大陷阱。 大量使用托管模式。
当您使用 GWT-ext 时,您几乎永远不需要自己接触 CSS,除非您想调整开箱即用的外观。
我的建议是使用 GWT“本机”小部件而不是功能接近的库小部件。
重新搜索引擎索引:是的,该网站通常不会有可导航的 URL(除非您仅向常规网站的元素添加小部件)。 不过,您可以执行历史后退/前进功能。
No major pitfalls that I haven't been able to overcome easily. Use hosted mode heavily.
As you are using GWT-ext you will almost never need to touch CSS yourself unless you want to tweak the out of the box look.
My recommendation is to use a GWT "native" widget over a library one where they are close in features.
Re search engine indexing: yes the site will not have navigable URLs normally (unless you are only adding widgets to elements of a regular web site). You can do history back/forward functionality though.
不久前我在一个项目中同时使用了 GWT 和 GWT-ext。 我发现随着 Web 开发的进行,体验非常顺利,但我的建议是:
不要将 GWT 本机小部件与 EXT 小部件混合。 这真是令人困惑,因为通常名称是相同的(GWT.Button 或 GWText.Button?)
发生在我身上的一件事确实使代码比我想要的更复杂,那就是我想要一个面板
a) 可动态更新
b) 可级联
GWT 本机面板是动态的,Ext 面板是可级联的。 解决方案? 包裹 GWTExt 面板的 GWT.VerticalPanel...混乱。 :)
但是,嘿,它有效。 ;)
I used GWT and GWT-ext together on a project a while ago. I found the experience quite smooth as web development goes, but my advice would be this:
Don't mix GWT native widgets with EXT widgets. It's confusing as hell, since usually the names are the same (GWT.Button or GWText.Button?)
One thing that happened to me that really made the code more complex than I'd like, was that I wanted a Panel that was
a) dynamically updatable
b) cascadable
GWT native panels are dynamic, Ext panels are cascadable. Solution? A GWT.VerticalPanel wrapping a GWTExt Panel... Chaos. :)
But hey, it works. ;)
我赞同 ykagano 的评论,最大的缺点是在 MVC 中失去了 V。 尽管您可以将真正的 ui 类与其余客户端代码分开,但您无法轻松使用图形/Web 设计器生成的 HTML 页面。 这意味着您需要一名开发人员将 HTML 翻译成 java。
获取一个所见即所得的 ui 编辑器,它将节省你大量的时间。 我使用 GWTDesigner。
GWT 最大的优点是能够忘记跨浏览器问题。 它不是 100%,但几乎消除了所有痛苦。 结合托管模式调试的优势(相对于 Firebug,Firebug 非常出色,但与 Java 调试器不同),它为开发人员生成复杂的 Ajax 应用程序提供了巨大的优势。
哦,它运行时速度很快,特别是如果您使用 gzip 过滤器。
I second the comment from ykagano, the biggest disadvantage is losing the V in MVC. Although you can separate the true ui class from the rest of your client side code, you cannot easily use an HTML page generated by a graphic/web designer. This means you need a developer to translate HTML into java.
Get a wysiwyg ui editor, it will save you lots of time. I use GWTDesigner.
The biggest upside of GWT is being able to forget about cross browser issues. Its not 100% but takes almost all that pain away. Combined with the benefit of hosted mode debugging (as opposed to Firebug which is excellent but not the same as a java debugger) it gives the developer a huge advantage in generating complex ajax apps.
Oh and its fast at runtime, especially if you use a gzip filter.
有点偏离主题,但如果您遇到持续存在的问题,irc 上的 #gwt 频道非常有帮助。
Slightly off-topic, but the #gwt channel on irc is very helpful, in-case you have a persistent problem.
GWT 非常简单直观。
特别是随着 UIBinder 的发布,GWT 小部件可以在 XML 中布局,然后在 Java 中进行编码。
所以如果你使用过其他Ajax或者Flash设计工具,或者Silverlight等,GWT是非常容易学习的。
主要障碍(即使不是陷阱)也是 GWT RPC。 您希望使用 GWT 的真正原因是 GWT 异步 RPC。 否则,为什么不直接依靠 css 来格式化你的页面呢?
GWT RPC 是允许服务器刷新服务器上的数据而无需刷新页面的元素。 这是股票表现监控(或美国当前的国家和公共债务或全球每秒流产的未出生婴儿数量)等页面的绝对要求。
GWT RPC 需要一些努力来理解,但只要几个小时,它就会变得清晰。
除此之外,在付出一些努力学习 GWT RPC 之后,您最终发现不能使用 JSP 作为 RPC 的服务组件,除非......我的博客上有一个关于如何使用 JSP 的 8 部分(我认为)系列作为 GWT RPC 服务程序。 然而,由于您没有寻求答案而只是提出问题,因此我将不再为我的博客做广告。
所以。 我非常相信,使用 GWT 的最大障碍/陷阱是找出如何正确部署 GWT 异步 RPC 以及如何使其能够使用 JSP 服务程序。
GWT is pretty straight-forward and intuitive.
Especially with the release of UIBinder to allow GWT widgets to be laid out in XML and then coded-behind in Java.
So if you have used other Ajax or Flash design tools, or Silverlight, etc, GWT is very easy to learn.
The major hurdle, if not pitfall, is GWT RPC. The very reason you wish to use GWT is because of GWT async RPC. Otherwise, why not just rely on css to format your page?
GWT RPC is that element that allows your server to refresh data on your server without having to refresh the page. This is an absolute requirement for pages such as stock performance monitoring (or the current national and public debt of the US or the number of unborn babies aborted worldwide by the second).
GWT RPC takes some effort to understand but given a few hours, it should come all clear.
Above that, after putting in some effort to learn GWT RPC, you finally discover that you cannot use JSPs as the service component for RPC, unless ... I have an 8 part (I think) series on my blog on how to use JSP as the GWT RPC servicer. However, since you had not asked for answers but just issues, I shall desist from advertising my blog.
So. I very much believe that the worst roadblocks/pitfalls to using GWT is finding out how to properly deploy GWT async RPC and how to enable it to use JSP servicers.
我们很难将 GWT 代码库与从网页设计师处获得的 HTML Web 模板(具有我们希望 GWT 管理的特定 div id 的静态 HTML 页面)结合起来。 至少在我们使用它时,我们无法让 GWT 与我们网站上未使用 GWT 编码的部分集成。 我们最终让它工作了,但这是一个很大的黑客攻击。
We've had a very hard time marrying our GWT codebase with HTML web templates that we got from a web designer (static HTML pages with specific div ids that we wanted GWT to manage). At least back when we used it, we couldn't get GWT to integrate with parts of our website that were not coded in GWT. We had it working eventually, but it was a big hack.
但是对于大型 Javascript 项目来说这是最好的选择
But for a large Javascript project it's the best choice
GWT 2.4 已经解决了许多上述问题,并且一个很棒的小部件库刚刚从 Beta 版中出来(Ext GWT 3.0.4 又名 GXT),它完全用 GWT 编写,而不是 JS 库的包装。
剩下的痛点:
GWT 2.4 has fixed many of the aforementioned issues and a great widget library is just coming out of Beta (Ext GWT 3.0.4 a.k.a. GXT), which is written completely in GWT, not a wrapper of a JS lib.
Remaining pain:
对于GWT 2.4,调试GWT时使用Firefox,它比使用chrome要快得多。
如果您只使用 Firefox,请考虑将此行放入您的 project.gwt.xml 文件中。
另外,如果您使用的是 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
Regarding GWT 2.4, Use Firefox when debugging GWT, it alot more faster then using chrome.
And if you'll using only firefox, consider putting this line in your project.gwt.xml file
Also, If you're using eclipse, then add the following under arguments -> VM arguments:
-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m
You can divide your server and client, and use the following under arguments -> Program arguments:
-codeServerPort 9997 -startupUrl http://yourserver/project -noserver
Also, to prevent refreshing your server on each change, use JRebel
http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/
And here's a live demo
http://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY
一个主要的陷阱是,有时您需要显式地为最终成为 HTML 元素的内容分配一个 id,以便能够使用某些 CSS 样式。 例如:当 tabPanel 的 tabBar 已分配了 id 并且您在该 elementId 上指定 :hover 时,GWT TabPanel 只会在 tabBarItems 上执行 :hover。
我写过一些其他GWT 的缺点 其他地方,但它们已经被 rustyshelfs 的答案覆盖了:)。
One major pitfall is that sometimes you need to explicitly assign an id to what ultimately becomes an HTML element to be able to use certain CSS styles. For instance: a GWT TabPanel will only do :hover over tabBarItems when the tabBar of the tabPanel has been assigned an id and you specify a :hover on that elementId.
I wrote about some other disadvantages of GWT elsewhere, but they are already covered by rustyshelfs answer :).
我最近在 GWT 上做了很多工作,这就是我不得不说的:
我对GWT-EXT不太了解,但我也相信没有必要包含第三方库。
祝你的决定好运:)
I have done a lot of work on GWT recently, and this is wht i have to say:
I do not know much about GWT-EXT, But i too am of the belief that there is no need to include Third party libraries.
Best of luck on your decision :)
GWT 进行浏览器嗅探而不是功能检测,您的应用程序将无法在某些浏览器(特别是新浏览器)上运行,
以下是该问题的一些参考:
以下是对功能检测的一些参考:
摘自JavaScript 框架比较 - 维基百科
GWT does Browser Sniffing instead of Feature Detection and your application will not work on some browsers (specially new ones)
Here are some references of the problem:
Here are some references to Feature Detection:
Extracted from Comparison of JavaScript frameworks - Wikipedia
GWT 团队在去年发布的 GWT 2.7 中做出了很多重大改进。 GWT 的一个主要弱点是在 GWT 2.6 及更低版本中编译需要很长时间。 现在这种情况已经消失了,GWT 没有增量编译,增量编译非常快并且仅编译更改。
GWT 2.7 现在具有(来源):
The GWT team make a lot of great improvements in to last year releasing GWT 2.7. One major weakness of GWT was that compilation takes to much time in GWT 2.6 and below. This is now gone GWT has not incremental compile which is super fast and compiles only the changes.
GWT 2.7 now has (Source):
获取可靠事实的最佳方法是从 gwt调查。 GWT 的最大问题之一始终是编译时间过长。 幸运的是,它正在迅速改善,因此在不久的将来不会成为一个重大问题。 另一个陷阱是 GWT 更加复杂,因为 Java 是一种更复杂的语言,每一步都会抵制不良编码人员。 另外,编译又加了一层。 例如,js 互操作需要一些样板文件。 根本问题是 GWT 的设计并不简单。 它是为极其复杂的网络应用程序从头开始设计的,整个社区始终优先考虑性能、代码质量、架构等,而不是简单的编码。
请记住,您可以随时在 GWT 中使用 js,因此如果您在 GWT 中遇到困难,请考虑使用 js。 归根结底,GWT 是 js,因此您可以在 GWT 中做任何在 js 中可以做的事情。 事实上,大多数GWT项目都使用js。 问题是 GWT 要复杂得多。 尽管如此,有时额外的复杂性还是值得的。
值得注意的是,GWT 3.0将带来巨大的改进。
The best way to get reliable facts are from the gwt survey. One of the biggest issues with GWT has always been a long compile time. Fortunately, it's improving very quickly so it won't be a significant issue in the near future. Another pitfall is that GWT is dramatically more complicated because Java is a more complicated language that resists bad coders every step of the way. In addition, compiling adds a layer. For example, js interop requires a little boilerplate. The fundamental issue is that GWT wasn't designed to be simple. It was designed from the ground up for extremely complicated web apps and the entire community consistently prioritizes, performance, code quality, architecture etcetera over easy coding.
Remember that you can use js in GWT at any point so if you are struggling with GWT consider using js. At the end of the day GWT is js so you can do anything in GWT that you can in js. In fact, most GWT projects use js. The problem is that GWT is drastically more complicated. Nevertheless, it's sometimes worth the extra complexity.
It's worth noting that GWT 3.0 will bring massive improvements.
重用 RPC 服务对象。
它会导致竞争条件,其症状看起来像是应用程序挂起。
Re-using RPC service objects.
It causes race conditions with symptoms that look like the app hanging.
我遇到的陷阱
1. superdev模式下的不同行为。 例如,Someclass.class.getName() 在 Superdev 模式下工作得非常好,并返回类的完全限定名称。 在生产模式下,这不起作用。
Pitfalls I ran into
1. Different behaviour in superdev mode. E.g. Someclass.class.getName() works absolutely fine in Superdev mode and returns the fully qualified name of the class. In productive mode this does not work.
GWT 是一项技术杰作。 它将客户端和服务器编程结合起来,使其成为一个连贯的应用程序——软件在“分层”之前编写的方式,以及它应该编写的方式。 它消除了不同的技能组合、团队成员之间的沟通不畅,以及整个网页设计阶段:艺术和编程。 它是最接近移动(例如 Android)开发的。 事实上,GWT 旨在生成不同的本机 UI,而不仅仅是 HTML。 尽管它需要大量的纪律来确保这种解耦 - 保持你的内层与表示无关。
您应该避免的第一个错误是使用第三方扩展,例如 EXT-GWT 又名 GXT 和 SmartGWT,我花了四年时间才意识到这一点。 开始使用他们漂亮的桌面小部件而不是投资于自己的样式是非常诱人的,但我无法说出我在 SmartGWT 中遇到了多少问题,直到我最终厌倦了。 简而言之,它将核心 GWT 功能集冻结在某个(相当过时的)级别,然后在其之上进行构建。 另请记住,如今那种轮廓分明的桌面外观和感觉看起来很愚蠢,更不用说缓慢的性能、大量的错误和兼容性功能——尤其是在移动设备上。 您希望尽可能靠近本机浏览器控件,即呈现为本机
由于移动趋势,整个用户体验变得更简单、更扁平,因此您不需要做太多事情来设计外观清晰的应用程序。 不过,如果您想要“3D”外观,也可以使用渐变。 CSS3 让一切变得简单,GWT 以优雅的面向对象方式包装它,这与原始 CSS 不同。 因此,不要因为看到 GWT Showcase 中相当丑陋的准系统控件而气馁。 GWT 团队故意不提供任何样式,因为这是开发人员的工作。
其余的几乎都是使用强类型 Java 进行的传统浏览器编程,具有漂亮简洁的 API。 但当然永远不要忘记您的代码在浏览器内部运行,因此所有调用都是异步的,例如您不能在循环中调用 GWT-RPC 方法(以填充某些列表),但如果您遇到这种情况,则需要递归链接它们情况。
有一些自称的“反模式”,例如不使用 GWT-RPC。 到目前为止,这对我来说一直很好:10年了。 简单是关键。 我不会想到为了代码的优雅和可维护性而牺牲一些边际性能。 除此之外,这不是你的瓶颈所在——数据库中。 当然要注意您向客户端发送了多少数据。
如果您无法找到现有小工具或为其设置样式 - 阅读丰富的 HTML5 元素集,您始终可以包装第三方小工具。 我用流行的 jQuery FullCalendar 做到了。 根本不是火箭科学。 其他一切(例如 Google 地图和 Google 图表)都有半官方的 GWT 包装器。
GWT 非常完美。 它没有得到足够喜爱的唯一原因是,仍然影响该行业的早期互联网采用者并不是来自计算机科学和面向对象语言,因此无法欣赏它们。 他们具有艺术(Photoshop/WordPress)或网络(Perl/Python)背景。
GWT is a technology masterpiece. It unites client and server programming making it one coherent application - the way software was written before "layering", and the way it should be written. It eliminates different skills sets, miscommunication between team members, and generally the whole Web Design phase: both the artistic and programming. And it is the closest you'd get to mobile e.g. Android development. In fact GWT was designed to generate different native UIs, not just HTML. Though it requires enormous discipline to ensure such decoupling - to keep your inner layers presentation-agnostic.
The first mistake you should avoid, which took me four years to realize, is using third-party extensions like EXT-GWT aka GXT and SmartGWT. It is very tempting to start using their pretty desktopish widgets instead of investing in your own styling, but I cannot tell how many problems I had with SmartGWT until I finally got fed up. In short it freezes the core GWT feature set at the certain (pretty outdated) level and then builds on top of it. Also keep in mind, that chiseled desktop look and feel looks silly nowadays, not to mention the sluggish performance, tons of bugs, and compatibility features - especially on mobile devices. You want to stay as close to the native browser controls, as possible i.e. dropdowns rendered as native <select> elements, not some custom-painted controls.
Thanks to mobile trends the whole UX is becoming simpler and flatter, so you don't need to do much to style a sharp-looking application. Though if you want "3D" look, there are also gradients. CSS3 made everything easy, and GWT wraps it an elegant object-oriented manner unlike the raw CSS. So don't be discouraged by looking at rather ugly barebones controls in the GWT Showcase. The GWT team intentionally didn't offer any styling, because it it the developer's job.
The rest is pretty much conventional browser programming in strongly typed Java with beautiful concise APIs. But of course never forgetting your code runs inside the browser, so all of the calls are asynchronous e.g. you cannot call GWT-RPC methods in a loop (to populate some list), but need to recursively chain them if you ever come to to this situation.
There are some self-proclaimed "anti-patterns" like don't use GWT-RPC. It's been good to me so far: for 10 years. Simplicity is key. I wouldn't think even a second to sacrifice some marginal performance for code elegance and maintainability. besides this is not where your bottlenecks would be - in the database. Of course mind how much data you are sending to the client.
And if you cannot find or style the existing gadget - read rich HTML5 element set, you can always wrap a third-party one. I did it with a popular jQuery FullCalendar. Not rocket science at all. Everything else like Google Maps and Google Charts has semi-official GWT wrappers.
GWT is perfect. The only reason it doesn't get enough love is because early Internet adopters who still influence the industry didn't come from Computer Science and object-oriented languages to appreciate them. They have either artistic (Photoshop/WordPress) or network (Perl/Python) background.
我们与 gwt 合作已近两年了。 我们吸取了很多教训。 我们的想法如下:
不要使用第三方小部件库,尤其是 gwt-ext。 它会破坏你的调试、开发和运行时性能。 如果您对如何发生这种情况有疑问,请直接与我联系。
使用 gwt 仅填充应用程序的动态部分。 因此,如果您与许多字段进行一些复杂的用户交互。 但是,请勿使用附带的面板。 使用现有的库存设计师提供的页面。 划出包含应用程序控件的区域。 在 onModuleLoad() 中将这些控件附加到页面。 这样您就可以使用设计器中的标准页面,并且还可以在 gwt 之外进行所有样式设置。
不要将整个应用程序构建为一个标准页面,然后动态构建所有部分。 如果你按照我在第 2 条中建议的操作,这种情况就不会发生。 如果您动态构建所有内容,则会降低中型到大型应用程序的性能并消耗大量内存。 另外,如果您按照我的建议操作,后退按钮将会很好用,搜索引擎索引等也会很好。
其他评论者也有一些很好的建议。 我使用的经验法则是像创建标准网页一样创建页面。 然后切出需要动态的部分。 将它们替换为具有 id 的元素,然后使用
RootPanel.get( id ).add( widget )
填充这些区域。We have been working with gwt for almost 2 years. We have learned a lot of lessons. Here is what we think:
Dont use third party widget libraries especially gwt-ext. It will kill your debugging, development and runtime performance. If you have questions about how this happens, contact me directly.
Use gwt to only fill in the dynamic parts of your apps. So if you have some complex user interactions with lots of fields. However, don't use the panels that come with it. Take your existing stock designer supplied pages. Carve out the areas that will contain the controls for your app. Attach these controls to the page within onModuleLoad(). This way you can use the standard pages from your designer and also do all the styling outside the gwt.
Don't build the entire app as one standard page that then dynamically builds all the pieces. If you do what I suggest in item 2, this won't happen anyway. If you build everything dynamically you will kill performance and consume huge amounts of memory for medium to large apps. Also, if you do what I am suggesting, the back button will work great, so will search engine indexing etc.
The other commenters also had some good suggestions. The rule of thumb i use is to create pages like you were doing a standard web page. Then carve out the pieces that need to be dynamic. Replace them with elements that have id's and then use
RootPanel.get( id ).add( widget )
to fill those areas in.我们遇到的陷阱:
虽然您可以通过使用 GWT EXT 之类的东西获得很多好处,但任何时候您在 JavaScript 库之上使用这种薄层,您就会失去调试能力。 我不止一次地把头撞在桌子上,因为我无法检查(在我的 IntelliJ 调试器内)GWT EXT 表类中发生了什么......您所看到的只是它是一个 JavaScriptObject。 这使得找出问题所在变得非常困难...
您的团队中没有了解 CSS 的人。 经验,这个人不是专家并不重要……只要他拥有一些良好的工作知识,并且在必要时知道谷歌的正确术语就足够了。
跨浏览器调试。 密切关注进程外托管模式[1][ 2 ][3],希望在 GWT 1.6 中出现。 .. 现在,您只需使用托管模式让一切顺利,然后使用“编译/浏览”按钮,您就可以在其中使用其他浏览器。 对于在 Windows 上工作的我来说,这意味着我可以在 FireFox 中查看我的工作,并使用 FireBug 来帮助调整并使事情变得更好。
IE6。 令人惊奇的是 IE 6 所渲染的事物有多么不同。 我采取了根据浏览器将样式应用到最外层“视口”的方法,这样我就可以拥有如下 CSS 规则:
最后,确保您使用可以帮助您的编辑器。 我使用 IntelliJ——它有很多 GWT 智能。 例如,如果我尝试使用 JRE 模拟未处理的类,它会让我知道; 如果我为小部件指定了样式,并且尚未定义该样式,则代码会显示红色小波浪...或者,当查看 CSS 时,它会告诉我何时在 a 中指定了冲突的属性单一规则。 (我还没有尝试过,但我知道版本 8 具有更好的 GWT 支持,例如保持“本地”和“异步”RPC 接口和实现同步。)
Pitfalls that we've run into:
While you can get a lot of mileage from using something like GWT EXT, any time you use this sort of thin veneer on top of a JavaScript library, you lose the ability to debug. More than once I've bashed my head on the desk because I cannot inspect (inside my IntelliJ debugger) what's happening in the GWT EXT table class... All you can see is that it's a JavaScriptObject. This makes it quite difficult to figure out what's gone wrong...
Not having someone on your team who knows CSS. From my experience, it didn't matter that the person wasn't expert...it's enough that he has some good working knowledge, and knows the right terms to google when necessary.
Debugging across browsers. Keep an eye on Out of Process Hosted Mode[1][2][3], hopefully coming in GWT 1.6... For now, you just have to get things good with hosted mode, then use the "Compile/Browse" button, where you can play with other browsers. For me, working on Windows, this means I can view my work in FireFox, and use FireBug to help tweak and make things better.
IE6. It's amazing how different IE 6 will render things. I've taken the approach of applying a style to the outermost "viewport" according to the browser so that I can have CSS rules like:
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 2.0 预计将在未来几个月内发布,解决了所讨论的许多问题。
Google I/O 大会上的 GWT 2.0 预览视频
GWT 2.0, which is supposed to come out sometime in the next few months, solves a lot of the issues discussed.
GWT 2.0 Preview Video at Google I/O
不是“无法克服”,而是对于一些基本的事情有点痛苦。
日期处理:
GWT 使用已弃用的
java.util.Date
,这可能会导致在客户端处理日期时出现意外行为。 GWT 不支持java.util.Calendar
。 更多信息请参见此处。相关问题示例:
Not "unable to be overcome" but a bit of a pain for something basic.
Date handling:
GWT uses the deprecated
java.util.Date
which can lead to unexpected behaviour when dealing with dates on the client side.java.util.Calendar
is not supported by GWT. More info here.Related problem examples:
我将在已经提到的内容中添加一些要点:
恕我直言,GWT 缺少一个对该“线程”中提到的所有问题提供开箱即用支持的框架。
I'll add some points to the ones already mentioned:
IMHO, GWT is missing a framework that has out of the box support for all of the issues mentioned on this 'thread'.