PDA

View Full Version : Is GXT too far removed from GWT?



algesten
11 Sep 2008, 7:21 AM
Admittedly I've only spent a few hours trying to get a feel for Ext GWT, but I get this uneasy feeling that it will not work well for me. There documentation is a bit lacking, but I have no trouble reading code, so this will not put me off. To get my stuff "right" I was basing my first tries on the Mail example app. I copied file structures, mvc setup, widgets etc.

First off I get hit by various rendering bugs. If I just point my Safari browser to http://extjs.com/mail/ and refresh a couple of times, the login box will occasionally have a "too deep" shadow which goes away if you drag it around a bit. On a similar note if I just remove the call to setClosable() (which strangely is done by the view in the sample), I get some rendering glitches where the dialog title close button appears a bit here and there. Trivial things, but not slick.

More seriously when I again point Safari or Firefox to http://extjs.com/mail/ and try tabbing between the fields, the focus never jumps on to the buttons. Firefox sort of indicates that the whole background behind the dialog is at times focused. I haven't been able to solve this with setting tab index.

When I first picked up GXT I was under the impression it was a widget library, however studying it in more detail, I get the feeling that it's actually more than that. Rather than just providing fancy widgets based on GWT's widgets, it has a whole own layer of DOM manipulation, event handling etc - it's not an extension to GWT's widgets. My point is illustrated by that all GXT widgets inherit from a base class Component. Consequently GXT's Button has nothing to do with GWT's Button, they don't even use the same event handling mechanisms for registering a click (same goes for all standard widgets: Container != Panel, DialogBox != Dialog).

I assume the design choice to do this is driven by a need to provide fancier stuff than is possible within the boundaries of plain GWT. Consequently there is "doubling up" of code going on. For instance modal dialog boxes requires some browser specific DOM trickery to fade out the background etc, this is now solved in both GWT and GXT. Such trickery comes with bugs and where Google has a team to fix in GWT, it appears to be one done by one man in Ext (this is no criticism - Darrell is doing an tremendous job by the looks of it).

My worry when it comes to us adopting GXT is that we are risking putting a lot of eggs in one basket, that the distance between GWT and GXT is introducing a whole new layer of bugs I need to work around. I'm currently looking into whether it's possible to use GXT "just a little bit" - i.e. not adopting the whole panel, mvc, etc. But just using the widgets I'm really after such as data binding pagination tables, date pickers etc - but within the realms of plain GWT.

Thoughts, comments?

TheBuzzer
11 Sep 2008, 8:22 AM
ya gxt is like another framework. it uses gwt on top of it but there are really still javacode and not completely just java. I would say it is eaiser to make stuff using just gwt but gxt provides advance widgets that are more powerful but yet harder to setup.

eugenparaschiv
11 Sep 2008, 12:05 PM
I have the exact same worries about GWT. The thing is I made my choice and adopted it for a large project, but as I go deeper inside the API (I've been working with it for the last two months), I see the same things over and over: a lot of double functionality; I understand that GXT cannot build on top of GWT (which is by no means plain), but I would very much have liked it to be extending and not replacing GWT. I'm looking at the panels and many seem to be pretty much the same thing, and it just seems a waste of effort to mirror that in GXT if they already work so well in GWT. That would evidently mean the API would have to be developed with interoperability in mind, but this isn't the case now. Probably because they wanted to make things similar to EXT-JS, their JavaScript library. The GXT approach is not bad in any sense of the word, but it would be nice to have more developers working on the project, as the work is inhuman for just one man (or perhaps very very few). Anyway, I'm committed for now.
Eugen.

algesten
11 Sep 2008, 10:33 PM
Thanks for your comment Eugen,

Have you thought about what impact your choice of GXT have had for your project? Any UI development will encounter issues that needs working around, but do you have a feeling of the overall timing implications GXT have had. Has it been a net saving in time?

In terms of technology I'm mainly after the data binding/presentation framework such as paginated tables and dynamic trees and some other fancy widgets.

Martin

eugenparaschiv
11 Sep 2008, 10:58 PM
Hi - I can say that, in some areas, it has saved a lot of time. For instance, it has an internal MVC implementation that GWT doesn't (it does, but it's third party so...). I was after the data binding as well, and GXT does provide that, but only for some widgets: Table/Grid, Lists, Trees and that's about it. More advanced data binding is reserved for the 1.2 release (which should come out in about 3 month I think). I have not explored the data binding in GWT (in fact, I'd be interested to know if there is any, and not third party). The integration part feels like a limit (I'm now trying to integrate some GWT widgets in my design, and see if there are any problems); there are some visual bugs (the library IS very very new), and hopefully there will be some new developers working on the project soon. If you are considering GXT for a project, you should know that the code is very poorly documented. I was just browsing through GWT code and was amazed by how well documented it is, but then again, this is normal practice and the GXT developers are probably just to few to begin documenting the API. One last thing. If you want to have an idea of where things are going with GXT, look at the EXJ-JS examples (the same company does that as well). It feels like an older, more mature API.

sheesh-kebab
13 Sep 2008, 7:38 AM
I also feel it would be beneficial to provide a better level of interoperability between GWT and GXT - e.g. being able to easily use GXT widgets in GWT layouts and vice versa. However, not sure whether it's going to be technically feasible, given all the browser development nightmare that IE6 causes and truly "inhuman" (or rather no-sane-developer-would-ever-touch-it type thing ;) ) effort that goes into getting RIA stuff to work across browsers.

thatone
6 Mar 2009, 2:51 PM
Yes, I agree.

We have used GXT in a large RIA project. But we are starting to consider moving back to using GWT layout panels because the GXT layout mechanisms seem to make it difficult to do dynamic flowing layouts without forcing inline CSS width/height on contained widgets.

But we like many aspects of GXT like model binding and loading, grids and many other widgets.

But we want a cleaner separation of CSS and code so...

Can anyone share their experiences with using GXT widgets in GWT containers? Is it super tricky? worth trying?

openian
8 Mar 2009, 8:36 AM
Thanks for your comment Eugen,

Have you thought about what impact your choice of GXT have had for your project? Any UI development will encounter issues that needs working around, but do you have a feeling of the overall timing implications GXT have had. Has it been a net saving in time?

In terms of technology I'm mainly after the data binding/presentation framework such as paginated tables and dynamic trees and some other fancy widgets.

Martin


Hi Martin,

I've been using GXT since the MyGWT days. I'd have to say it saves a lot of time in terms of rapid prototyping.

This is my personal opinion that may or may not apply to all people:

In general, GXT is good for:
1) Rapid Prototyping
2) Data Entry
3) Internal App

GXT is not good for:
1) Look-n-Feel of Web App (in particular with HTML links/images)
2) Layout
3) CSS modification

There were several times where I tried to customize GXT UI-wise (not binding or behavior wise) to make it more like a web-app, so far the experience looks like this:
- it's hard to modify/extend the UI code
- it's hard to read the code because it does so many DOM trickery
- leaky abstraction (sooo bad)
- upgrade will break my own code
- sins are waiting to be made (doing dangerous things)
- their Component lifecycle is undocumented (and this is the CORE central of everything)

As you all have notice, the documentation is very poor. The tutorial is for beginner to get start up and running immediately. The code is overly complex because it has to do a lot of UI manipulation during interaction.

It doesn't play nice with GWT due to its own life-cycle and quirky ways of solving things. You could make it work with GWT, but it'll take some effort and a lot of knowledge on how the rendering and layout mechanism work, which in itself is a challenge due to poor documentation.

If you want to create an in-house application where you can tell your boss that:
- it may not possible to do X (X=layout,widget,handle specific behavior)
- it is possible, but we have to do workaround, commit sins, break things during upgrade, do you still want to do it?

If you want to create a public-facing website that would last for eternity, stay away.

If you want your app to look and feel more like a regular web-app (say, twitter, flickr or whatnot). Here's why:

1) most web-apps rely on links to navigate around

GXT is notorious with links. You can use raw HTML, but that may or may not break few things. Links itself is not enough, sometime you need to attach a listener to it. Not to mention due to the fact that GXT is rich, you might end up with listeners stepping into each other logics. (Say you want to be able to select a row in a grid and do something, at the same time, the grid contains a column that is a link to jump to other place, what happen when you click on the link?).

2) some web-apps have true and pure flow layout

Say, your table/grid extends infinitely (causing the scrollbar of overall window to show up). Is this doable with GXT? probably not. There's a reason why SWING isn't the most popular desktop library/framework out there. Thus the decision to adapt that paradigm from SWING may or may not be a good idea for GXT.


All in all, like anything in life, it's all about choice:

You choose GXT, you loose some of the web-app flexibility

You choose GWT, you loose some of GXT features (binding, validation)

If you can accept GXT AS-IS, feel free. If you need to do customisation, AVOID at all cost. I don't believe in "minimum customisation" requirement. Once you push it a little bit, you're going to push it more.

openian
8 Mar 2009, 9:04 AM
Martin,

Take a look at this thread as an example of how GXT under-the-hood looks like:

http://extjs.com/forum/showthread.php?t=60400

Instead of doing it the GWT way, we see hardcoded stuffs here and there.

baskor
9 Mar 2009, 8:56 AM
GWT is primarily a Java to JavaScript compiler. It has other features like RCP, History management and a widget library, but still it is a mainly a Java to JavaScript compiler.

You don't have to use the built in History Management, RCP or the standard Widgets. The GXT team has chosen not too use the standard GWT Widgets; so what?

I really like GXT for developing Rich Internet Applications. I've had some troubles with bugs and lacking documentation, but I knew that risk when I started my project. GXT is a relatively new project and I believe and hope that the GXT team will focus on stability and better documentation after the 2.0 release. I love how fast features have been implemented, and would also have prioritized new features over stability. Now I think we soon have enough features and should get more stability.

Once more, GWT is a Java to Javascript compiler; not a widget library.

openian
9 Mar 2009, 9:54 AM
GWT is primarily a Java to JavaScript compiler. It has other features like RCP, History management and a widget library, but still it is a mainly a Java to JavaScript compiler.

You don't have to use the built in History Management, RCP or the standard Widgets. The GXT team has chosen not too use the standard GWT Widgets; so what?

I really like GXT for developing Rich Internet Applications. I've had some troubles with bugs and lacking documentation, but I knew that risk when I started my project. GXT is a relatively new project and I believe and hope that the GXT team will focus on stability and better documentation after the 2.0 release. I love how fast features have been implemented, and would also have prioritized new features over stability. Now I think we soon have enough features and should get more stability.

Once more, GWT is a Java to Javascript compiler; not a widget library.

I think we are all aware of what GWT is. It has been noted, debated, argued in other forums when the discussion of JS vs GWT arise.

This particular discussion is talking/exploring the GXT approaches/designs, what to avoid, what GXT is good for, what GXT is bad for, etc.

And the "so what if GXT doesn't use the GWT way"... well.. there are implications of that decisions right? I don't think it should be taken lightly.

jbaxter
9 Mar 2009, 2:14 PM
Just to weigh in with my 2c worth.

In terms of widgets, GXT is to GWT as SWT is to AWT.

To elaborate, GWT is like the old AWT: clunky and fugly. Look how far Sun got trying to impose their own look 'n feel (AWT then Swing). 'nuff said. SWT is much more popular primarily because it looks and behaves natively. GXT is more-or-less doing the same thing for GWT as SWT did for AWT/Swing. And in terms of design, GXT looks a lot like SWT under the hood.

I know who I am betting on :)

Kutu
9 Mar 2009, 4:06 PM
Just to weigh in with my 2c worth.

In terms of widgets, GXT is to GWT as SWT is to AWT.

To elaborate, GWT is like the old AWT: clunky and fugly. Look how far Sun got trying to impose their own look 'n feel (AWT then Swing). 'nuff said. SWT is much more popular primarily because it looks and behaves natively. GXT is more-or-less doing the same thing for GWT as SWT did for AWT/Swing. And in terms of design, GXT looks a lot like SWT under the hood.

I know who I am betting on :)

Probably. I can't say that GWT is more native that GXT. GWT is for web-app while GXT attempts to emulate desktop in web browser. This is a different situation to compare with SWT, AWT, SWING.

Now talking about native, I've been seeing discussions where the GXT layout can't flow like a normal HTML would, grid needs specific size, and the list goes on.

jbaxter
9 Mar 2009, 4:21 PM
GWT is for web-app while GXT attempts to emulate desktop in web browser.

A few people have said this. I'd be interested in some examples because I don't really understand the distinction. I started out coding my app in GWT but switched to MyGWT (and then GXT) because the widget collection in the latter was prettier and more functional. I have to say I didn't feel a huge transition in coding style; both GWT and GXT are desktop-like paradigms with their layouts, windows, listeners, widgets etc.

The main difference I see is purely a java-style one: GWT feels like it is written by ex-employees of Sun, if you know what I mean, whereas GXT feels like it is written by someone whose first language was javascript, not java :)

Kutu
9 Mar 2009, 7:39 PM
A few people have said this. I'd be interested in some examples because I don't really understand the distinction. I started out coding my app in GWT but switched to MyGWT (and then GXT) because the widget collection in the latter was prettier and more functional. I have to say I didn't feel a huge transition in coding style; both GWT and GXT are desktop-like paradigms with their layouts, windows, listeners, widgets etc.

The main difference I see is purely a java-style one: GWT feels like it is written by ex-employees of Sun, if you know what I mean, whereas GXT feels like it is written by someone whose first language was javascript, not java :)


Let's start with Grid cannot expand (or flow) to infinity. That Grid must have a size dead set.

jbaxter
10 Mar 2009, 10:23 AM
Let's start with Grid cannot expand (or flow) to infinity. That Grid must have a size dead set.

Ok. Kinda the nature of the Gridly beast to be fixed-sized, but I take your point. AFAIK GWT's grid is also fixed size so that's not a distinguishing feature. You want something more like GWT's HTMLTable?

Kutu
10 Mar 2009, 3:45 PM
Ok. Kinda the nature of the Gridly beast to be fixed-sized, but I take your point. AFAIK GWT's grid is also fixed size so that's not a distinguishing feature. You want something more like GWT's HTMLTable?

Afaik GWT grid needs the number of columns and rows, not pixel size. Plus you can resize it in the future if the number of columns and rows grows.

abickford
17 Mar 2009, 6:40 AM
Your analysis is correct, it is very far removed from GWT. GXT pretty much reinvents everything from widgets, containers, events, rendering, layout managers, etc.

We did one project using GXT and I have to say it was the most expensive (in dev hours) project we've ever done by far. This is in contrast to projects done w/vanilla GWT, JSP, Struts, Swing, SWT (but not eclipse RCP), html/javascript/css and SwixML (an xml wrapper over swing). I don't mean this as a flame or whatever, that's just the experience we had.

One example: Me and another dev both literally, independently, spent an entire day trying to get a grid to property fill a panel in window. I'm not exaggerating, there are many posts on these very forums about other people who have had similar issues solving this very problem. This should be a trivial task.

The event API is very, very confusing. You have to use the javadoc to see what events a widget even supports: both explicitly and inherited. The API is not very type safe - passing strings into methods that are only documented in the javadocs i.e. Field.setMessageTarget(String "some value"). This is not how java APIs are generally written.

That being said, the end result does look nice. Perhaps these things bother me more because I'm more of a Java developer and have certain expectations. If you are coming more from the javascript background and are more dependent on the docs, the learning curve may be a joy.

Hopefully the GXT devs don't delete this post.

sven
17 Mar 2009, 6:58 AM
For Field.setMessageTarget(String "some value"):

It also support element ids. If we would only have side, tooltip and title we could easily use an enum. But as you also can set an elementid to set the errormessage, we have to use string here.

abickford
17 Mar 2009, 7:35 AM
For Field.setMessageTarget(String "some value"):

It also support element ids. If we would only have side, tooltip and title we could easily use an enum. But as you also can set an elementid to set the errormessage, we have to use string here.

In that case I would expect an overloaded flavor: one with the predefined behaviors via an Enum, another w/a string that can use an id.

That's exactly what I mean when I say as a javascript developer you may be thrilled w/GXT, as a java developer, not so much. Ultimately, you've compromised a clean Java API to facilitate leaking your abstraction. I think it's great you have an innerHtml approch because it's a real world need but I don't feel it should be a first class citizen. This just shows more of the javascript/html slant to the API. Why isn't there an overloaded flavor that takes a container for the error message? Isn't this arguably the the OO GWT way of adding children to parents vs innerHtml?

jbaxter
17 Mar 2009, 4:34 PM
We did one project using GXT and I have to say it was the most expensive (in dev hours) project we've ever done by far. This is in contrast to projects done w/vanilla GWT, JSP, Struts, Swing, SWT (but not eclipse RCP), html/javascript/css and SwixML (an xml wrapper over swing).

Part of the reason for GXT taking longer is this is not an apples-to-apples comparison.
- Swing and SWT are desktop toolkits. No messy HTML to deal with. APIs can be as clean as you want them to be, and have evolved over centuries (well, nearly :-) ).
- JSP and Struts are great for simple things, but to relate my own experience: at one point I got very frustrated with GXT (probably something to do with nested layouts - that always bites) and in a minor internal hissy fit started to recode the whole app in JSP/Struts. 5 minutes later I realised that I had left behind the option of using JSP/Struts a long time ago - it simply cannot support the complexity of user interface that GXT can.
- GWT doesn't give you the sexy, consistent look 'n 'feel of GXT.
- html/javascript/css are great if you are an expert web developer. What I love about GXT is that I can get almost as good-looking and snappy UI without needing to know all the cross-browser tricks and without needing to be a great designer.That said, no doubt GXT could be better designed, but given the speed of progress it's pretty darn good.

abickford
18 Mar 2009, 5:00 AM
Part of the reason for GXT taking longer is this is not an apples-to-apples comparison.
- Swing and SWT are desktop toolkits. No messy HTML to deal with. APIs can be as clean as you want them to be, and have evolved over centuries (well, nearly :-) ).
- JSP and Struts are great for simple things, but to relate my own experience: at one point I got very frustrated with GXT (probably something to do with nested layouts - that always bites) and in a minor internal hissy fit started to recode the whole app in JSP/Struts. 5 minutes later I realised that I had left behind the option of using JSP/Struts a long time ago - it simply cannot support the complexity of user interface that GXT can.
- GWT doesn't give you the sexy, consistent look 'n 'feel of GXT.
- html/javascript/css are great if you are an expert web developer. What I love about GXT is that I can get almost as good-looking and snappy UI without needing to know all the cross-browser tricks and without needing to be a great designer.That said, no doubt GXT could be better designed, but given the speed of progress it's pretty darn good.


I fully understand the pros and cons of all those approaches and I agree w/most of what you said. For context, these are mostly CRUD apps w/ACLs and workflows, pretty standard stuff.

I just wish GXT was as easy to use and consistent (API/Behavior wise) as GWT. I was simply trying to show that I have experience in almost every 'flavor' of java UI and sharing my experience as it relates GXT. Perhaps 2.0 will get there. Right now, it's a really high price to pay in productivity for that look and feel over GWT. But it's still better than JSF :)

jadrake75
18 Mar 2009, 8:15 AM
One aspect I really find lacking (this is not really a GXT issue but a general GWT/Browser issue) is the inability to do background tasks ala SwingWorker style. I know you can invoke a DeferredCommand, but it still does not really execute as a background task and if your task is long running or CPU intensive it locks the screen.

I was reading that it looks like Google Gears has the WorkerPool: http://code.google.com/apis/gears/api_workerpool.html. Has anyone used this with GXT?

It looks promising for doing long running (I am talking > 500 ms) tasks for the user, but as far as I know there is not really a good "integration" with GWT/GXT, meaning that the user really needs to invoke these as native JS and I would think trying to update components in GXT could be troublesome (as well as emitting events to your controllers).

Does anyone have examples using this?

jpnet
18 Mar 2009, 8:52 AM
I was reading that it looks like Google Gears has the WorkerPool: http://code.google.com/apis/gears/api_workerpool.html. Has anyone used this with GXT?

It looks promising for doing long running (I am talking > 500 ms) tasks for the user, but as far as I know there is not really a good "integration" with GWT/GXT, meaning that the user really needs to invoke these as native JS and I would think trying to update components in GXT could be troublesome (as well as emitting events to your controllers).


I would like Google to enable GWT code to run in the thread (via Gears of course). I've encountered this same difficulty of being forced to use native JS. I have essentially put this off until another solution comes along. One hasn't yet. So if anyone does have any experiences I would also love to hear about them.

-JP

abickford
18 Mar 2009, 9:38 AM
http://code.google.com/p/gwt-google-apis/

GWT api's for: gears, maps, gadgets, etc.

BTW, these are supported by the GWT team so should be supported for a while.

jpnet
18 Mar 2009, 9:43 AM
http://code.google.com/p/gwt-google-apis/

GWT api's for: gears, maps, gadgets, etc.

BTW, these are supported by the GWT team so should be supported for a while.


Yes. Look at the WorkerPool support for GWT. Unfortunately, you can't write GWT code to run in a thread. You must use native JS.

-JP

thatone
19 Mar 2009, 9:09 AM
Part of the reason for GXT taking longer is this is not an apples-to-apples comparison.
- Swing and SWT are desktop toolkits. No messy HTML to deal with. APIs can be as clean as you want them to be, and have evolved over centuries (well, nearly :-) ).
- JSP and Struts are great for simple things, but to relate my own experience: at one point I got very frustrated with GXT (probably something to do with nested layouts - that always bites) and in a minor internal hissy fit started to recode the whole app in JSP/Struts. 5 minutes later I realised that I had left behind the option of using JSP/Struts a long time ago - it simply cannot support the complexity of user interface that GXT can.
- GWT doesn't give you the sexy, consistent look 'n 'feel of GXT.
- html/javascript/css are great if you are an expert web developer. What I love about GXT is that I can get almost as good-looking and snappy UI without needing to know all the cross-browser tricks and without needing to be a great designer.That said, no doubt GXT could be better designed, but given the speed of progress it's pretty darn good.

If you're using GXT as-is, then I would agree 100% of your last bullet-point. But if you're going to do theme customization, you're in a great pain.

Take the trigger-icon as an example. Try switching it to use your own icon (not the one that comes with GXT [search/magnifying icon]) w/o doing too much work or digging in firebug.

jbaxter
19 Mar 2009, 9:51 AM
If you're using GXT as-is, then I would agree 100% of your last bullet-point. But if you're going to do theme customization, you're in a great pain.

Take the trigger-icon as an example. Try switching it to use your own icon (not the one that comes with GXT [search/magnifying icon]) w/o doing too much work or digging in firebug.

TriggerField.setTriggerStyle() doesn't work?

thatone
19 Mar 2009, 1:57 PM
TriggerField.setTriggerStyle() doesn't work?

This is the image that they use:

http://extjs.com/explorer/images/default/form/trigger.gif

each icon is approximately 17 pixel wide. You can't just drop a single icon and hope everything to work correctly.

sdc
20 Mar 2009, 2:58 AM
GXT is to GWT as SWT is to AWT.

I see more GWT as a small JDK, with a compiler, the emulated JRE and a small widget library that you can compare to AWT.
What I think and expect from GXT is to be comparable to Swing or SWT in terms of design and features.
I don't think that GXT is the best choice if you want to develop a web site and that's not what I am expecting from it (vanilla GWT should be good for such needs). It is hardly better for a RIA.

If you develop a RIA with GXT, you don't have to care about the look and feel, you can just ignore the CSS. Also, in most cases, you even don't have to know that you develop a web app instead of a desktop app. You just work with high-level concepts : layouts, widgets, listeners.

Of course, the API maturity is hardly far from Swing. A lot of generics are not consistent. In some cases, you have to hardcode the size of a container, even if you already hardcoded the size of the children. And there are a lot of minor issues that you can fortunately workaround (especially if you are a web developer and you know HTML/CSS/javascript/browsers principles). There is also a lack of documentation.

So for me the major issue is the maturity. I don't see the use of GXT "a little bit" (just use some widgets in a plain GWT app) if the API is mature. As far as I see in the trunk, there will be some nice API improvements (and nice features). Not enough but I hope next features will focus on stability and design improvements.