It’s been four months since I first wrote about my experience starting to use GXT and freshly diving into a 2.0-M1 upgrade. Since then my project has upgraded to 2.0-M2, 2.0-M3, RC1, RC2, and finally 2.0 GA, with even a couple svn trunk builds in between for good measure. In fact after M2 I stopped writing about because it was just more of the same messy, things-don’t-work-like-they-used-to-or-at-all-and-worse-are-different-in-every-browser shananegians every time. I kept hoping that our experience was simply an artifact of so many changes in 2.0, their dev team being clearly overwhelmed, and would still converge on some form of synergistic vision by the final release. I was sadly mistaken.

GXT fails, and this will be the last time I bother to comment on it unless it spontaneously improves before I stop using/thinking about it entirely. My project is removing it where possible, minimizing its use when necessary, and hoping to leave it in the dust by way of GWT 2.0 and incubator advancements over time.

Some examples of the types of issues still present (albeit changing flavors regularly) in GXT 2.0 final are:

• Component and/or layouts only render correctly – or at all – when wrapped in a specific type of parent component that otherwise has no bearing on its functionality
• Many components, including the really visible ones like Grid, render differently in each browser, or sometimes not at all (especially in Chrome)
• Components behave in wildy different ways when aspects of their state such as hidden/visible or enabled/disabled are set prior to render, during render, or after render, e.g. calling hide() before something is displayed causes it to appear malformed and non-functional rather than being hidden
• Tooltips – and popups in general – don’t display, display in random locations, refuse to hide, or render incorrectly when re-used; in fact unconstrained use of “new” keyword any time you need to display something has become a necessary anti-pattern on my team to get things to render correctly
• Funny, but sad, breaking API changes like removing Window.close(), with explanations like “because it never worked like you’d expect it to so you never should have used it anyway”
• Arbitrary (accidental?) functionality tweaks like changing which item is selected by default when you open a new combo box or when which actions on a check box (blur, click, etc.) actually fire the change event; these are superb at breaking UI tests
• Heavy-handed style approaches (think programatically setting element.style from a private method) that make customization difficult
• Continued prevalence of heavy BeanModel-based models and stores and expensive run-time massaging of data; someone should really teach them about generators
• No visible effort to take advantage of, or at last synchronize with, up and coming GWT best practices like MVP, dependency injection, command pattern, and compile-time optimization rather than run-time inflation
• Many things… are still… so slow; forcing your user to choose between waiting while a component spins in IE 7 vs. having it load lightning fast but not work correctly in Safari or Chrome is so web 1.0

I’ve heard that GXT 2.0.1 is just around the corner with “many fixes”. Right.

Recently I shared my GWT 1.6 and GXT 2.0-M1 upgrade experience which was quite underwhelming on the GXT front. In the past week my team went ahead an upgraded to GXT 2.0-M2 to take advantage of some specific changes we’d noticed in svn.

For the most part 2.0-M2 didn’t introduce new breaking changes beyond M1. In our project, the only obvious differences were new parameters to some renderers that were easily converted. Functionally, most things seem to work like M1 as well – just a few minor tweaks here and there. However, on the performance front there seem to be some incremental improvements: one example is TreeTable, where we’ve had problems with render time growing linearly with the number of children (over 100ms/item in IE7 – that’s over a minute for a 100 item tree!). It’s still based on the legacy Table paradigm rather than their newer Grid (see some GXT notes on the difference here), but has improved to the point where we can use it for a moderately sized TreeTable and re-build/render a new TreeTable in under 10 seconds. The existence of Table vs. Grid is a good example of 2.0-M2 still exposing several different architectural approaches to components, but at least the ones being actively pursued seem to be headed in the right direction.

Other than that M2 has been a worthy upgrade from M1. I’d fully expect anyone upgrading from 1.2.x to 2.0-M2 to still experience a lot of pain, but if you’re already on M1 then it makes sense to go ahead and get all these fixes. Our M1 build was actually an svn checkout that already had a couple weeks’ worth included, and M2 is certainly a much higher quality preview than either that or the original M1 release. Moving from M1 to M2 will give you a bunch of fixes and keep you in sync with the API for a very minimal amount of effort.

Recently I commented on a rather severe change in GXT 2.0-M1 with regard to dynamic sizing via percentages not being converted to final HTML as expected with some components. For anyone else experiencing this issue, here’s my support thread which also includes a very simple example app illustrating the problem.

So far our workarounds have been:

1. Explicit fixed sizes, ugly but easiest in some tricky spots (not resize-proof)
2. Fixed sizes derived from parent, e.g. parent passes in its height/width minus any margins and borders (resize-proof only if parent size changes are manually propagated down)
3. Add additional wrappers/children so that the problematic components delegate to, or inherit from, one that works (resize-proof only if parent size changes are manually propagated down)
4. Implement “smart” post-render sizing based on actual height/width of parent (resize-proof as long as sizing methods are called on resize, most robust, probably the most invasive)