Take the 2-minute tour ×

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!

share|improve this question
Lately I've noticed some GWT-based websites coming up correctly in my Google search results, even though the underlying html doesn't include the information I'm searching for (examples.roughian.com has several of these sort of results). It appears that the Google indexer must be doing some intelligent javascript rendering in order to figure out what would actually show up on a page once everything loads up. –  StriplingWarrior Dec 15 '09 at 18:34

21 Answers 21

up vote 205 down vote accepted

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:

















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.

share|improve this answer
We've run into several issues where various styles/positioning commands didn't seem to "take" - styles not being used where they should have been, or the sizing of an element seeming to ignore the request to make it 100%. Same as many regular CSS challenges - quite possibly a lot of user error! –  agartzke Sep 19 '08 at 6:16
@agartzke yeah that's CSS for you, and it mostly has nothing to do with GWT. That's why we employ highly skilled designers to do that kind of thing for us. Getting it right in 4 different browsers is never an easy task. –  rustyshelf Sep 19 '08 at 6:22
There's many exiciting new features coming later this year that greatly improve lots of these issues. Out-of-process Hosted Mode (OOPHM), CssResource (stylesheet obduscation/minification), UiBinder (aka 'Declarative UI'). –  Mark Renouf Jun 17 '09 at 20:37
I'm realling looking forward to 2.0 but I have to disagree with GWT being the sledge hammer. If thats the case then jQuery and JavaScript are a cludge, at best. My point being that I get no re-use, I end up copy-pasting a lot of things (say: a text box on 4 pages that behaves identically in each place). That's not to say you should toss all your old applications out. I would (almost) never use GWT to add capability to an existing html/js application. Also CSS Resources are in the incubator and I like them: stackoverflow.com/questions/1066250/gwt-html-file-with-css/…. –  Chris Ruffalo Jul 2 '09 at 18:33
You can re-use JQuery just as much as you can re-use GWT, I don't think that's a valid argument. They both support inheritance, and then can both be packaged for reuse (.jar file for GWT, .js file for JQuery). I stand by what I said GWT is a sledgehammer, you have to code it in Java, you have to compile it, you have a whole lot more things to manage. If you want to break a brick wall though, you pick the sledgehammer. It's not a critiscm it's a valid point. The right tool for the right job. –  rustyshelf Aug 27 '09 at 0:25

We have been working with gwt for almost 2 years. We have learned a lot of lessons. Here is what we think:

  1. 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.

  2. 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.

  3. 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.

share|improve this answer
I opened a question regarding your answer at stackoverflow.com/q/10025656/138585. I'll appreciate if you can have a look. –  Elad Apr 5 '12 at 9:04

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:

    .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.)

share|improve this answer

GWT 2.0, which is supposed to come out sometime in the next few months, solves a lot of the issues discussed.

  • Create layouts using an html/xml like syntax
  • Dynamic Script Loading - only the essential JS will be downloaded initially. The rest will be downloaded as needed
  • In-Browser Hosted Mode - This might take care of the hosted mode speed issues discussed, among other benefits
  • "Compiler Optimizations" - Faster compilation, hopefully

GWT 2.0 Preview Video at Google I/O

share|improve this answer

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:

share|improve this answer
Two years later, and this is still the case. It remains quite annoying for doing date math on the client. –  Joseph Lust Mar 19 '12 at 16:18
The issue is the translation (compilation) from java.util.Calendar to JavaScript. You may also have a look at the GWT's class CalendarUtil, How to use java.util.Calendar in GWT and How to do calendar operations in Java GWT? How to add days to a Date?. Cheers ;) –  olibre Nov 15 '13 at 16:48

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:
TextField fname, faddress;
  • 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'.

share|improve this answer
GWT does ship with a history system, e.g. History.newItem("myItem", false); will put #myItem in the url, for easy bookmarking. To handle someone loading a bookmark with your app, simply use History.addValueChangeHandler(myHandlerMethod); –  Ztranger Nov 18 '09 at 20:12
It's not a history system per se, it's just a mechanism for writing tokens to URL and handling token changes notifications. You will still have to write all the app code to handle history change. –  Miguel Ping Nov 19 '09 at 10:34

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/

share|improve this answer
Since this question is still active and getting votes, I thought I would provide an update. I completely ditched GXT (2009-2010) because I didn't like Sencha Inc's business practices. I then subsequently ditched GWT. I dreaded using JavaScript for so long as I use to hate it. That is, until I really understood it. Now I almost exclusively develop in Node.js/AngularJS. Toss in Bootstrap 3 and you can make an awesome looking website in far less time than GWT. The future is JavaScript, the earlier you embrace it, the better developer you'll be. –  JP Richardson Nov 15 '13 at 20:58

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.

share|improve this answer

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. ;)

share|improve this answer

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.

share|improve this answer
Didn't know about the gzip filter - thanks for that tidbit. –  agartzke Sep 20 '08 at 2:11

Slightly off-topic, but the #gwt channel on irc is very helpful, in-case you have a persistent problem.

share|improve this answer
which IRC network is the channel on? –  tovare Oct 18 '08 at 21:06
It's on freenode (irc.freenode.net). And it's actually ##gwt, but you'll be forwarded to it if you type #gwt. –  stian Oct 8 '09 at 19:00

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.

share|improve this answer
I would like a link to your blog articles ;) –  ms-tg Jan 3 '12 at 19:05
h2g2java.blessedgeek.com –  Blessed Geek Jan 19 '12 at 23:58

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.

share|improve this answer

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.
share|improve this answer
  • 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

share|improve this answer

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

share|improve this answer

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 :).

share|improve this answer
Generally assigning IDs is not a bad thing if you plan to do test using Selenium. –  Petteri Hietavirta Oct 22 '08 at 21:02

I have done a lot of work on GWT recently, and this is wht i have to say:

  1. 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
  2. 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.

Best of luck on your decision :)

share|improve this answer

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

share|improve this answer

Re-using RPC service objects.
It causes race conditions with symptoms that look like the app hanging.

share|improve this answer
Antony could you elaborate on this. I'm making an RPC call to the server and am expecting the GUI to be responsive until the request comes back but it appears to hang. –  Brett Hannah Jul 27 '11 at 11:35

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.

  1. addWidget(widget) will call widget's removefromparent()
share|improve this answer

Your Answer


