Link Details

Answer : yes yes yes.


Now all we need is WYSIWYG GWT

:-P

No, not every webapp is Gmail. Not every webapp needs the "Desktop" L&F that GWT apps provide. Sometimes it is just fine to render some html with a few active ajax widgets.

GWT sucks at emulating "page transitioning". You cannot stuff anything in a single page.
,

You don't quite say this, but for clarity Gmail is not implemented using GWT (it predates it). Google Wave is.

True, but it is the same type of application.

GWT is not only good for Gmail-type web apps. In my last project, we introduced GWT for the creation of new pages, while keeping the L&F of the old Struts-based pages (many of those pages were ported as well). Using GWT was much more productive, and the resulting UI was more responsive.

Ajax is only used with GWT-RPC. The rest is DHTML.
,

Did you use a GWT module per Struts page? Or did you use one module that managed the screen-flow itself without a page-refresh?

We created one top-level GWT module for each use case of the application. Most use cases have more than one page. There were also top-level GWT modules created as reusable business components, mostly used for the selection of domain entities in use case-specific pages.

There was one top-level GWT module which took over the main application menu, from which all pages for use cases were opened. Some of these pages were implemented in JSP/Struts, others in GWT.

It is easy to embed GWT modules inside JSP pages (a GWT module can use HTML element ids to interact with the outer page). Navigating from GWT pages to JSP/Struts pages and back is also possible, although more difficult to implement (it can be encapsulated in a reusable GWT module at the infrastructure layer, though).

So you had 1-n jsp page/s per use case and included a gwt nocache script in each of them? Sounds interesting.. did the js-load time have negative effect on the pageflow? Was clicking through the app really fast?

No, we created new use case implementations in GWT and discarded the old JSP/Struts code (for some of them only, others remained in JSP/Struts). We also introduced the use of GWT reusable components into existing JSP pages, to avoid having two different implementations of the same functionality.

GWT pages are normally much faster to download than the equivalent JSP/Struts pages; and after the initial download of the GWT browser-specific ".html" file (which BTW is cached by the browser), the responsiveness is much better, due to the use of Ajax through GWT-RPC.

To put it in simpler terms, did you have one big module or a lot of tiny modules per use-case with some shared code?

We had a bunch of top-level GWT modules plus another bunch of reusable modules to be inherited in the top-level ones (200+ modules in total 8^). By "top-level" I mean that they are not inherited by other GWT modules.

In practice, having "one big module" should always be avoided in a GWT app (unless it is really small), since Java->JavaScript compilation time is significant, and the resulting script files would be too large. Perhaps this is the biggest mistake people make with GWT.
,

Interesting approach. I am thinking about splitting the views of my one big module into several small ones, so that the are accessed through their own jsp pages / hyperlinks.

Guess then I dont need to reinvent something like "spring mvc" in my gwt client code.
,