GWT-Ext to Ext-GWT

Trying both GWT-Ext and Ext-GWT

In trying to make a decision on whether to go GWT-Ext or Ext-GWT I’ve done some reading including the websites of those two technologies, forums, and various blogs like:

The most talked about topic when discussing this comparison seems to be licensing, but I don’t want to spend much time on that.  Instead of comparing the two technologies line by line, I take a small existing vanilla GWT application and add new needed functionality such as drag and drop, resizable columns, sortable columns, and additional layouts.  This was done first using GWT-Ext and then again using Ext-GWT.  The opinions I gather are based on coding with both over a few days.

GWT-Ext Experience

This was actually my second choice, and became my first choice based on comparing the licenses of the two.  My first steps were changing out widgets used and hoping that the underlying code dealing with the model wouldn’t need to be modified (much).  Layouts are one thing I noticed that are considerably different.  Instead of using VerticalPanel or HorizontalPanel, you use a Panel and add a modifier to make it flow vertical or horizontal, much like Swing.  While this is good if you know Swing, and are starting the app from scratch, it can be a pain if converting like i am.

Another difference when dealing with going vanilla GWT to GWT-Ext was rewriting code that handles FlexTable or GridPanel updates or, in other words, the way you get data into the table.  In GWT land, you can treat the FlexTable as the data, much like a two-dim array, and set data to the cells.  GWT-Ext uses something called a Store, which is basically the data itself.  When you add to the Store, the GridPanel gets updated.  There are pros and cons to both methods I suppose, but that’s another discussion.  I will say the reason I stopped using GWT-Ext was because of problems rendering the grid to the screen when using the GridPanel with certain layouts.  I suspected this was due to it being a js wrapper.  It turned out there was a known bug which required a workaround just to get the grid to show.  After spending many hours dealing with this problem and a few others I decided I shouldn’t be wasting my time with something that has problems taking one panel and adding it to another like panel.add(grid).  In GUI building, an operation like that is simple and frequent.

On to Ext-GWT

Last thing I wanted to do was revert back and start again, but here it goes.

One big difference between the two Exts is that GWT-Ext is just javascript wrapper.  It’s visible while configuring because you’ll add scripts and javascript libraries to your public folder.  With Ext-GWT none of that needed to be done.  This is because Ext-GWT is a GWT library and doesn’t wrap javascript.  I like this.

So I start again changing out widgets, and notice that there’s almost no work to be done.  The new widgets use same function calls as old ones.  They did drop the ball on the Button class and it’s listener (actually, I don’t like the way events are coded).  Not sure why you would not stick with a ClickListener and onClick()….but whatever.   The layouts are similar, and they include VerticalPanel as well.  Changing the FlexTable out for the Grid took some work, but less than GWT-Ext.  It does use a StoreList (similar to GWT-Ext’s Store) but I felt it made a little more sense.  There was little time spent correcting column sizes and dealing with autofills, which makes me happy, and there were no issues getting the Grid to show up.

Final Decision

Well, everything was fine but another day has passed and I’m just not 100% happy with Ext-GWT.  Running the hosted browser and compiling has become slower than ever (still faster than GWT-Ext though).  I got to thinking and realized that the only enhanced component I really needed was the Grid over the FlexTable, and I did get the grid setup just like I wanted.  Since one of the things I really hated about Ext-GWT was the event handling code, I asked myself: Do I really need to have all of my buttons, checkboxes, panels, etc in Ext-GWT?  Can’t I just use the fancy Grid and then make everything else using vanilla GWT?  I decided to try this, and not only did it work perfectly, but there was noticably lower load times and increased speed.

My final take is, use vanilla GWT for events and where you can use it.  For GWT components that are missing features you need use Ext-GWT.


  1. Casino 496d8c9639…

    Casino 496d8c9639…

  2. Andrew McVeigh says:

    have you any opinions on SmartGWT? It’s got a better license than Ext GWT. However, it’s a wrapper like GWT-Ext. I think the underlying JS library is probably nicer though.

  3. [...] ที่มา: [...]

  4. Igor says:

    btw, ext-gwt also have an good mvc and simplify communications with server-side

  5. Richard says:

    Actually I have extensive experience with GWT-Ext. I ended up using a hybrid like you discuss above. nesting Ext widgets in flextabels etc.. That said, its a frigin nightmare to get the desired behavior from either EXT once you start mixing containers. but .. I GUESS its kinda worth it, once you figure it out. Like you have to next a flextable in a Window not a RootPane etc…

    I think whats needed in this arena is an alternative lib with a thin wrapper thats used for style and basic composts. One that is 100% GWT and nothing custom. the core functionality that comes stock with GWT is exceptional if you stick to GWT components.

  6. Nick says:

    Richard, I completely agree with your last statement. The base vanilla GWT beats all with functionality, event handling, and interaction with the model. I think what some of these other libs should have done was not put everything including the kitchen sink in with them. There are things that GWT is missing. Add those things and build upon them, but use the underlying model and handlers.

  7. Developer Dude says:

    I looked at both some months ago because I really liked the look and feel – very nice. As I understand it (IIRC), GWT-Ext is just a GWT/Java wrapper around Ext-JS. The problem with both is that the underlying code had a reputation for being ugly (I didn’t look at it myself), but the clincher was the fact that it was a wrapper around JS, which takes away one of the big advantages of GWT – the ability to debug in Java, not to mention all of the optimizing and other features of GWT that Google worked so hard to provide and which in the long run is very important for non-trivial projects.

    Then Ext-GWT came along – okay, not a wrapper of Ext-JS, but native Java – right. Right. But there is still a problem; it didn’t extend GWT widgets. It created it’s own hierarchy from the base up – or at least that was how I remembered it. Which would have presented it’s own set of problems.

    While writing this comment I went and looked at the JavaDocs for Ext-GWT and note that either I was wrong before, or they changed; they do indeed extend GWT widgets. To what degree is something a dev should explore before using the lib in a project. Then there is the code quality – something that takes time and effort to evaluate and I will leave for others at this time.

  8. Nick says:

    I looked into SmartGWT. Here’s a few things I noticed:
    -grid works great. I like the L&F
    -found a few glitches when combining vanilla widgets with Smart’s widgets.
    -you need the entire javascript Smart lib. Not intelligent enough to just copy the portions you need resulting in huge amounts of unused javascript.
    -still in infancy. They’re on 1.0b1 and I’m not sure I want something this untested in a production environment.

  9. Benoit Guerout says:

    Afaik gwt-ext is dead and developers advice to use smart-gwt instead of their project (Due to new ExtJs Licence)

  10. Enlargement says:

    I am amazed with it. It is a good thing for my research. Thanks

  11. Dennis says:

    I have used both GWT and the ExtJs for about a year. Coming from the Java side only, my desire to learn/pour over the JS was not at the top of my list. The downside for me is that while the EXTjs is not always the easiest to work with and implement, my users and boss demanded the slick features present in EXTjs, I did not have much of a choice. The downside for me was/is that when I don’t fully understand why something does not work as intended in extjs, I really can’t use their boards because the answers are generally “modify the JS” and that is not my desire. I have begun to toy with SmartGwt and the features just keep getting better and more attractive looking. While many of the things CAN be done with GWT alone, the ugly factor comes up and unfortunately those that direct me (CIO) know that there is much prettier stuff out there, I have no choice in the end. I know pretty is not always best for me, but in the end, functional but ugly is not good for me either. GWT has bridged the gap that was present before when I used Struts, it was only as pretty as I could make it without employing a web designer for images, now I don’t need them for the most part, and that means my boss can spend that money elsewhere, hopefully on my salary!

  12. Nick says:

    Dennis, very excellent point. There aways seems to be that trade off of looks vs other stuff, and I know there’s a lot of garbage out there thats difficult to use with no support but the showcase or screenshots make the api look great….and of course the higher-ups want to use it.

    As far as web designers…it seems nobody wants to pay for them. The bosses feel that engineers can do it well enough (which is ridiculous) and then the product ends up looking like crap and we get the blame.


Leave a Reply