The rapid development cycle that we had in the beginning of the project seemed to disappear. Occasionally some strange GWT bugs started popping up, but figuring out what was wrong was very difficult GWT is by nature Java compiled into JavaScript, and tools like Firebug would give a non descript JS error message. This was several years ago though, around GWT 1.5 or so.

I don't have any GWT 2 experience and I should have emphasized this, however I witnessed another project (a year ago) based around GWT 2 and although with capable programmers, they found GWT to be a burden rather than a benefit, and frankly the result looked horrible.

There are features of GWT that I love the most when developing front-end code: resource bundle (auto-gen CSS sprites both the images and in Java code, no more hacky solution), i18n, UiBinder, JUnit (provided you 'architect' the code using MVP), great JS compiler (pruning dead code, producing multiple outputs for browser specific).

GWT infrastructure is definitely years ahead of anything out there in the market.

Having said that there are a few things that I missed from using normal tools like HTML/CSS/JS: fast refresh/update, debugging inside firebug vs attaching your IDE to debug front-end stuff. In general, development in GWT is slower if you don't have fast machines :)

Have you tried out the new SuperDevMode? It lets you use sourcemaps to debug the java code directly in the browser. Only works with Chrome currently, I think. I tried it out a bit but it felt a bit clunky, and I actually prefer debugging in Eclipse to firebug/chrome, I think. Couple seconds of startup time don't worry me as much as others, I guess. I use the time to think through what should happen and where problems could show up.

At any rate I agree with you on how good the tooling support for localization/css/etc is - I think the learning curve is too steep for most people? The size of the getting started guide is pretty crazy, and there is a lot of confusing deprecated stuff, especially in the panels (some for html quirks mode (IE6), some for standards mode...)

Learning curve of the GWT API itself was okay, but the setup ceremony is not (preparing IDE, build, mavenizing, the whole end-to-end from start to finish). I don't know if this can be improved since this may be inherent culture from the Java world.

But like anything in this world: you get some, you lose some (e.g.: no silver bullet). At this time, it's a matter of preferences and specific to each individual situation.

If you have a well-defined project, GWT may suit you well. But if you need something that change quickly and frequently, preparing GWT may be yet-another-too-technical stumbling block.

https://developers.google.com/web-toolkit/articles/superdevm...

I agree very much with your last statement though - hacking something together with no concern for future changes/requirements in Java nearly always ends in catastrophe.