Biggest GWT Pitfalls? [closed]

Answer 1

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

Answer 2

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

Answer 3

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.

Answer 4

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.

2. addWidget(widget) will call widget's removefromparent()

Answer 5

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.

Answer 6

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;
...
fname.setText(person.getName());
faddress.setText(person.getAddress());
...

• 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'.