GXT 2.0 final fails


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.

,

  1. #1 by José on July 23, 2009 - 2:06 am

    GXT 2.0.1 was just released with “many fixes”

    ;)

  2. #2 by Mark on January 14, 2010 - 6:27 pm

    “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”

    We’re on GXT 2.1.0 and this one still applies. Very aggravating.

(will not be published)