View Full Version : GXT: Keeping up with GWT

Alex Bertram
18 Oct 2009, 6:37 AM
Hi All,

I've been using GXT for about a year and it's been largely a great experience. It's clearly one of the best GWT libraries out there, and the fact that it's (largely) java makes good things like code pruning possible. However, when I started working the GWT trunk a few months back, and started using the Story of Your Compile (SOYC) functionality to improve code size, I ran into a few ugly skeletons in the GXT code closet, as well as a few ideas about how GXT could take better advantage of the GWT compiler.

I'm an open-source user of GXT (See our project at http://code.google.com/p/activity-info) so I'm willing to put some code where my mouth is, but it would be great to have a commitment from the ExtJs team not only to new features (can't wait for LiveGrid though!) but improving the performance of existing features.

Here a few of the issues that I see:

1. DogCatHorse classes that prevent code pruning.

I think this may be a hold-over from javascript days but a common pattern throughout GXT is the use of runtime flags to add/subtract behavior. The MessageBox class is a perfect example: the class uses an enum field to decide whether to add a TextBox, a TextArea, or a ProgressBar to the Dialog during the afterRender event. The result is that even if you only ever use MessageBox.info(), nearly the whole form package (TextField, Field, TextArea, etc) gets pulled into your code, resulting in about a 15k penalty. Now, I use the form package extensively, but I'd prefer to relegate that to later split points when it's needed.

Ideally, rather than branching during run time, we'd have several subclasses of MessageBox that each add the different types of functionality: ProgressMessageBox, PromptMessageBox, etc. (I'm attaching a patch that does just that and is also backwards compatible with existing code)

Other candidates for refactoring include Window (6.3 k), ComboBox (7+k and a particular bete noir)

Simple subclassing won't always work-- for the Window class I'm experimenting with some kind of decorator pattern that would allow the developer to combine behavior at compile time. For example, sometimes I just want a simple, typically GXT stylish, non-resizable, non-movable, non-maximizable window in my initial code fragment. Why should I have to pay for all the other funtionality that I don't want?

2. Tame the remaining js from ExtJs

I was shocked to discover that 25k worth of compiled, obfuscated js is generated from the Ext class, regardless of what I use! I assume the four domains involved (DomQuery, Format, Template, and DomHelper) were left intact for reasons of expediency, but it's time to take advantage of the fact that we're developing on the GWT platform and not in pure JS. Ray Cromwell's GQuery library is an excellent example of the optimization possible (both in terms of code size and speed) when we take advantage of the GWT compile phase to build queries, templates, etc, rather than waiting to parse and execute them at runtime.

There may be some exceptional cases where runtime evaluation of Templates or DomQuery's are necessary, but I'd go out on a limb and say 90% of use cases could be addressed with compile-time code generation. (In my app, it's a solid 100%)

3. Embrace ResourceBundles

I'm excited to see GXT take advantage of ImageBundles in some places, but I still notice a lot of a 300 byte "left hand corner" etc images being loaded individually, which kills performance. (at least on 3.5 kb/s VSATs, maybe no one in LA cares about this!) Some of this may be linked to support for runtime theming, but speaking for myself, the priorities for our app are usability and performance and being able to change colors mid execution doesn't figure in the top 50. Multiple/custom themes can be supported at compile time and would simply result in additional permutations.

In the same vein, it would be exciting to see future versions of GXT take advantage of bundling CSS -- I would love to see the 145 kb gxt-all.css file replaced by a ResourceBundle that allows pruning of css at compile time -- or at worst, splitting of the css between different fragments as needed.

Anyway, that's my 2 cents. Is there anyone else out there with similar priorities?


22 Oct 2009, 3:41 AM
Thanks for your detailed report.

We are already working on this. GXT 2.1 will add some functionality to minimize code size. For example is the Ext class no longer loaded all at once, but only the parts that are needed when they are needed. This means that if you do not use the Templates for example, they are not part of the compiled output.

However most things require changes that are too big to be in a minor release. We can target ResouceBundle for example first with GXT3.

22 Oct 2009, 5:23 AM
Short question, is GXT == Ext GWT? Or are they two separate projects?

22 Oct 2009, 5:32 AM
No, GXT is Ext GWT.