GWT 1.6 and GXT 2.0-M1 upgrade experience


This past weekend I had a chance to upgrade a GWT/GXT project earlier than expected. We’ve had considerable pain on the current version of GXT and hoped this might lessen it; sadly, the grass was not much greener on the other side.

GWT for its part was a fairly straightforward process, even with all the significant “breaking” API changes like a new war-based project layout, new eventing model, new compiler, and revamped hosted mode (see the complete list here). The steps involved were essentially:

  • Bring in the new jars
  • Move resource directories and web.xml into the new preferred war location
  • Fix compile errors (mostly new event/listener type and getters/setters replacing public members)
  • Change the compiler and hosted mode classes to the new ones, with the new args
  • Toy with the hosted mode and build classpaths so that Selenium is in the classpath first for unit tests, but GWT is first for hosted mode (because our project uses Selenium for UI tests and both Selenium and GWT are nice enough to bundle Jetty – and different versions, no less – as dependencies; Selenium, please move to Jetty 6 already!)

Additionally, each developer on the project had to disable/re-enable their GWT profile in Eclipse to have it detect 1.6 mode and re-create any run targets (not a big deal really, since the GWT Eclipse plugin makes this much easier than before!).

We have run into one intermittent problem worth noting: When attempting to run our client with a mock services stack (simple web.xml with local servlets that return test data), hosted mode will occaisonally freeze on startup. Debugging has revealed that our RPC calls are initiated but never returned. Base on the randomness and timing of the freeze it almost looks like a race condition where the mock services aren’t deployed as fast as the client, and hosted mode gets stuck in a loop waiting for the return on a call that was never received. Since our application has a rather custom setup where we run RPC against a different context in production (separate services war inside the same container), and this is also something we’ve attempted to mock, it’s not bad as a single issue; our workaround is to simply run the mock service stack externally on Jetty via an ant task and use hosted mode solely for deploying the client.

GXT on the other hand was a nightmare. GXT issues were the main driver behind our early upgrade – since the 2.0 release date keeps moving we decided to bite the bullet now and try M1 in hopes that it would fix more than it breaks. The obvious breaking changes were minimal – just some type changes, event differences, and slight re-arrangement of classes. But in terms of functionality the visual layout of the application was immediately wrecked on upgrade due to a number of blatant bugs (or very questionable behavior changes). Note that after our initial run-through we downloaded the very latest 2.0 snapshot from svn (as of 4/26/2009) and built that with similar results:

Percentage/pixel sizing problems
On components using a CardLayout (like TabPanel), height and width percentages get changed into raw pixels. In other words, calling setHeight(“100%”) results in HTML with height=100px embedded in it. This is incredibly annoying and I can’t overstate how thoroughly it breaks an application. Since our application sizes very dynamically and we intentionally avoid fixed size like the plague, it immediately became a mangled cluster of 100×100 boxes. Entertaining yes, but difficult to fix. We’ve ended up implementing a mixture of fixed heights/widths on the affected components and trying to delegate more explicitly to parent sizes until there’s a permanent fix.

Tighter coupling
Components seem less designed for extension, or at least more tightly coupled to each other and the DOM; for instance, several components that we’d extended and overridden onRender() for specific functionality blew up spectacularly, requiring that we override and assuage other methods to make them content again. The changes aren’t bad, but a framework doesn’t feel well thought-out when I’m forced to hack things one way in release x, then hack them a different way in release y.

CSS changes
To the GXT team’s credit the CSS tags used by objects are largely unchanged, however the css behavior and default values of many components are different; this was mostly an impact where we’d intentionally hacked things in CSS to make them look correct cross-browser and the hack was no longer necessary (or worse, now causing an issue). Our bad for hacking, but again, it sucks when a framework forces you into this, then keeps changing it.

New features incomplete
Any of the big “new” features we tried like HBoxLayout and VBoxLayout seem incredibly incomplete or broken. For example, attempting to use a VBoxLayout resulted in a panel rendering partially in the correct spot with its children lined up at the bottom of the screen, below the rest of the application; source inspection revealed some serious div madness going on. Based on this state of fail we’re not planning to dive further into any new features until it’s GA.

All in all the net change in GXT 2.0 as of M1 seems to be slightly better performance and a mild set of new features, yet with most of those new features broken and some very serious and annoying core bugs such as the percentage/pixel issue. I really hope they’re hard at working fixing these, as the pushed release date may suggest, and that the final release has some honest documentation on ALL breaking API changes and known issues, especially since documentation is something GXT has always lacked. I would highly recommend against anyone taking 2.0-M1 unless pain is something you enjoy, considering the serious issues and the fact that none of the new features feel usable yet.

GWT 1.6 by contrast is a no-brainer; if you’re lucky enough to be building an app with core GWT and homegrown components and/or another library this will probably make your life much easier. The war layout makes for even tighter integration with Java and is great for projects that are a mix of GWT and static content or other UI technologies. And the new configurability of the compiler makes parallel compilation or even disabling some browser permutations as easy as a few compiler args or lines in your .gwt.xml.

To the Ext guys: I really hope you have something better in store for us by 2.0 GA! The team I work on has many developers who’re new to GWT development and have backgrounds in custom AJAX, Flash, or C# UI’s. GXT 2.0 is continuing to build their impression that this technology is a hack that brings the “worst of both worlds”: they see a complex framework that’s lacking many features, yet is difficult or impossible to extend in a way that will be a) consistent cross-browser and b) not break completely on upgrade. Combined with the lengthy build/deploy time to test small changes in real browsers, it’s feeling like a net loss vs. straight AJAX (in JavaScript) or, better yet, another RIA technology completely such as Flash or Silverlight.

It’s worth noting that none of the pain points I’m belaboring, especially when it comes to CSS weirdness and cross-browser testing, are anything unexpected for traditional web application development. But they should not be the norm for GWT: a library on top of GWT that experiences all these pitfalls with regularity seems to miss the point. We expect something in return for long compile times and difficult-to-debug generated code; certainly more than just the convenience and familiarity of Java versus JavaScript.

But as someone heavily vested in a GXT project, here’s hoping even more that it shapes up a bit by 2.0 GA!

, ,

  1. #1 by Pete Williams on April 29, 2009 - 9:16 am

    Thanks very much for sharing this – it’s certainly made me think twice about biting the bullet just yet. Hopefully we’ll see significant improvements by GA.

  2. #2 by Dustin on May 1, 2009 - 12:05 am

    You’re welcome. I’ll post an update when we take on the conversion from M1 to GA. I’m hoping it’s a non-event for the sake of getting sleep that weekend!

  3. #3 by Darren on May 1, 2009 - 1:49 am

    Thanks for this. We have dabbled in GXT 1.2 just to see what it’s like. We may think twice about this, as our experiences are mirroring yours. I think GXT needs to break away from ExtJS and use more of the GWT library. It just feels wrong at the moment.

  4. #4 by James on May 1, 2009 - 8:48 am

    Why on earth are you writing a whinge article on upgrading to a new version of an extension to GWT?

    I am using 1.2.4 now and for me it is great. When 2 goes gold, maybe even has a few releases under its belt then I will make the transition.

    Instead of having a cry why not write about some problems you have had and how you have fixed them?

    P.S. I don’t work for extjs just don’t want this article to shun people away from using a great extension, especially when all the hate is based on a pre-release.

  5. #5 by Dustin on May 1, 2009 - 10:16 am

    James :

    Why on earth are you writing a whinge article on upgrading to a new version of an extension to GWT?

    I am using 1.2.4 now and for me it is great. When 2 goes gold, maybe even has a few releases under its belt then I will make the transition.

    Instead of having a cry why not write about some problems you have had and how you have fixed them?

    P.S. I don’t work for extjs just don’t want this article to shun people away from using a great extension, especially when all the hate is based on a pre-release.

    I understand that this release is not GA. The reason my team decided to risk a pre-GA upgrade to begin with was to address the many issues we were running into in 1.2.3; knowing we could not complete out product without rolling many of our own widgets on the current functionality, we’d have to upgrade in the next few months anyway and are intentionally absorbing the pain sooner to give us a better idea of where we stand.

    I don’t think GXT is a bad extension, and many of the basic components work well. However my premise for using it has been to take advantage of rich features such as advanced layout, resizing/dragging, heavily tweaked trees and tables, complex forms, data binding, and validation. In all of these areas the quality has lagged severely behind what I’ve experienced with other technologies in this space. With all due respect to GXT they’re not a collection of widgets for My First Website, and have staked claim to being a real RIA competitor and charge a healthy fee for commercial licenses and premium support. That’s the bar I’m holding them to.

  6. #6 by Trey on May 1, 2009 - 9:07 pm

    We are using GXT but trying to get it out of the application. Our alpha release had a lot, our beta will have less and I hope to have it all out this summer when we upgrade to GWT 1.6. It is beautiful but creates so many headaches and I think it is easier to create our own components and use the GWT incubator to fill in the gaps.

  7. #7 by Charlie on May 3, 2009 - 6:32 am

    I agree that GXT 2 new features are broken and incomplete. Clearly it was rushed to get out before their conference. Moreover I’m not pleased by the major version upgrade from 1.x to 2 for the feature set added. And having used GXT 1.x for only a limited period we have to pay an upgrade fee. Our management wasn’t too pleased by this and we are most likely going to go with an alternate solution (mosaic or smartgwt)

  8. #8 by Olivier on May 3, 2009 - 1:12 pm

    We’re using GXT 1.2 on our current project and we’re less than pleased with it. A large part of our code is made of workarounds for GXT inconsistent behaviour and very questionable design choices (for example see my post about GXT’s MVC package: http://blog.gerardin.info/archives/40). I was hoping that 2.0 would take a more serious approach, but it doesn’t seem to be the case. Let’s wait until the release, but if they don’t get it together by then, I’m afraid a lot of people will leave the boat like Trey.

  9. #9 by luosheng on May 15, 2009 - 12:14 am

    thanks ,very thanks for GXT

  10. #10 by Peter on June 3, 2009 - 10:20 am

    Dustin, great article. I’m looking into using GXT 2.x for a new commercial product. We’re starting from scratch. We’d very much like to use a GWT toolkit …but something richer than what Google offers. GXT seems to fit the bill, until I came across your posts here.

    I’d like to know, now that GXT 2.0 has officially released, if your experience is any better. Or are the bugs sufficiently prohibitive that you would not recommend using this technology?

  11. #11 by Dustin on June 3, 2009 - 12:27 pm

    Peter :

    Dustin, great article. I’m looking into using GXT 2.x for a new commercial product. We’re starting from scratch. We’d very much like to use a GWT toolkit …but something richer than what Google offers. GXT seems to fit the bill, until I came across your posts here.

    I’d like to know, now that GXT 2.0 has officially released, if your experience is any better. Or are the bugs sufficiently prohibitive that you would not recommend using this technology?

    Hi Peter, my team was in a similar situation (wanting to focus on building our product – not building components) when we picked GXT as our primary framework. From a pure performance/stability standpoint our upgrade to M2 has been an improvement over M1, and for new development you won’t have to deal with many of the upgrade pains we encountered having started on 1.2.x; in that respect it’s in a good place to start using right now. They still haven’t released a final 2.0 but it should be dropping very soon.

    However, in terms of the architectural strategy GXT as a whole is still pretty divergent from where GWT is heading. Two examples are their MVC implementation (GWT is leaning strongly towards an MVP approach), and the use of runtime constructs like BeanModel as the base type for their stores that back most of the complex components (Grid, Tree, etc.), where GWT is trying to move all late binding/optimization into the compiler. If you start dealing with complexities like multiple modules or endpoints, shared code, and wanting to do dependency injection with something like Gin (Guice for GWT), GXT’s architecture will get in the way even more. This dichotomy – GWT coming at things from a Java perspective, while GXT still often feeling like quickly ported JavaScript – makes it very difficult to use GXT as ad-hoc components and not let it creep into (and even take over) the fundamental design of your application.

    All that said, given that GXT still has some of the best looking and functional widgets for grids, comboboxes, resizing, drag & drop, and a whole host of others, I think it still makes sense to use it in moderation, but would try hard to think of it as a set of widgets and not embrace the whole framework. I’d take the time write some adapters around the components you need (building BeanModel stores, etc.) so that they’re isolated, and build the core stuff – your RPC calls, any client-side caching, MVC/MVP, etc. – the “right” way, resisting the urge yield to the GXT conventions just for the sake of expediency. I usually like to keep an open mind and favor a framework’s conventions rather than fight them (all other things being equal), but this burned us badly with GXT. Maintaining that separation will keep you decoupled from their architecture for one of two future scenarios: GXT starts growing closer to the GWT approach, in which case you have a clear place to handle the next big GXT upgrade that changes everything (again :) ), or when the next-best-thing comes along to replace GXT you’ll have a clean place to cut over in your view/widgets rather than throughout the application.

    This the approach I’m taking with new development and recommending to other teams just coming onto the GWT bandwagon at our company.

    Has anyone else started using GXT 2.x for new development, and what would you suggest?

  12. #12 by Peter on June 9, 2009 - 5:14 pm

    So, seems to me that just about any UI needs data objects that support the following capabilities:
    - Properties identification: all objects need to be able to identify their list of properties, and be able to return the value for any property
    - Change detection: all objects in the system should be able to detect when one of their properties has changed
    - Notification: all objects should be able to notify listeners when a change to a property has occurred
    - Dirty support: objects should know if anything w/i has changed. If changes have occurred, a comit ability to persist those changes
    - Comparison: all objects need the ability to compare their values with the values of other objects (supports sorting on any property)
    - Communication: all objects need to be updated regularly with new values available at the server end.

    Likewise, just about any remote UI needs lists that support Filtering, Sorting, Column specification, and Chunking.

    What’s my point? GXT has these abilities already built into it with BaseModel and Store objects. You indicate that you would maintain a strong separation between these GXT mechanisms (BaseModel & Store), and “my” model objects. I’d like to know more about your recommendations.

    Here are some possible solutions:
    1) I modify “my” objects to all extend BaseModel
    2) I create adapters to convert “my” objects into a comparable new set of BaseModel-derived objects
    3) I modify the GXT UI widgets to directly support “my” objects (which already provide all the abilities mentioned above)

    Thoughts?

    Peter

  13. #13 by Dustin on June 9, 2009 - 7:01 pm

    Here are some possible solutions:
    1) I modify “my” objects to all extend BaseModel
    2) I create adapters to convert “my” objects into a comparable new set of BaseModel-derived objects
    3) I modify the GXT UI widgets to directly support “my” objects (which already provide all the abilities mentioned above)

    I think it depends on the scope of “my” objects. Assuming the’re entirely in client code I think it’s reasonable to use #1. For data coming out of DTO’s from RPC calls (like a list of data that will populate a grid) I would not go so far as to let BaseModel creep into your DTO’s, and instead do #2 where the DTO gets converted to the appropriate client-side model which does extend BaseModel. I’ve found the component’s backing model often needs to be different from the retrieved data anyway (probably an argument for MVP).

    Another irony to keep in mind is that all of the features BeanModel providers aren’t always as applicable as they seem. For example, in all our complex grids we have custom cell renders and sorters for each column anyway so the value of property-style field accessors is minimal. I’ll admit that state detection/change notification is useful, and on complex forms we’ve often just tagged our POJO model objects with BeanModelTag so that we can arbitrarily generate a BeanModel when it’s useful inside a form to do data binding while the form is open/active, yet still have the API in and out of the component be the unwrapped POJO.

  14. #14 by Luke Lee on August 6, 2011 - 2:07 pm

    GXT has inconsistent behavior. Folks who use it often have to spend considerable time and effort on work-arounds. :( Not a good choice if it can be avoided.

  15. #15 by Joe Cramer on August 18, 2013 - 7:37 am

    I have use the GXT myself and there are much better systems than this. I guarantee you most of your time will be spent making a go around to make it work. This isn’t the blog to recommend other things but if someone would like to contact me I have a few good ideas other than GXT and the behavior which is unpredictable

(will not be published)