[nostrademons]

You've left out a third option: using a mature pure-JavaScript library like JQuery, Closure, or YUI.

IMHO that's the best of the options, because you can fall back to pure JS if you need extra flexibility or speed, and yet still don't have to deal with cross-browser bugs.

[freebsd_dude]

ok yes I know about those libraries...I guess what Im asking is why use GWT when such libraries exist?

[nostrademons]

If you have a piece of algorithmic code that really needs to exist on both the server or the client, and maintaining two versions of it will be too much of a pain. That's why Wave uses it (the Wave team would probably give you other reasons too, I've heard they like it, but that's the only technically defensible one IMNSHO).

If you want to have the same code run on both the server and client, your only options (that I know of) are GWT, server-side JS like Rhino or V8 or Node.js, and Pyjamas. GWT's the most mature of those.

Also, a social reason to use GWT (and perhaps the real reason Wave uses it) is if you know Java and don't want to learn JavaScript. This doesn't hold much water with me - what sort of a programmer wouldn't want to learn a new language? and JS is a pretty nice one all things considered - but it's convincing for lots of other folks.

[bmelton]

This.

One of my developers is crazy about GWT, and has shoe-horned it into a number of apps that he's primed, and it's proven to be problematic for a number of reasons.

The main problem we have is that a lot of our apps fit into a larger portal, so we have to worry a LOT more about JavaScript and CSS collisions, and generated JS/CSS just doesn't work well for that. Outside of a portalized environment, it might not be THAT bad, but for us, it's proven painful.

In the event that you find yourself duplicating your server side code and client side code, or writing excessive form validation to match server-side constraints, something like GWT is probably the way to go.

[freebsd_dude]

thanks for the great response