Not that GWT is perfect, it has some legitimate drawbacks (speed with complex data sets due to JS, search engine friendliness, testing complexity [though testing IS there - which is not true of many other RIA approaches], toolkit v framework and patterns and number of widgets, and more), but the stuff you note is no reason to trumpet what you were “correct” about.

Pretty much everything in the previous article is obviously based on a misunderstanding of what GWT is (it actually IS for building a complete application, or at least can be, and it’s certainly not bloated, for instance).

For the record, GWT does actually now support standards mode (not technically “now,” 1.5 supports it, and an RC is out – not a final). Though, in the real world, there are actually many good reasons NOT to use strict compliance (unless your goal is just compliance, over usability).

As for degrading, that would not be a GWT problem, but a JS problem in general. So yes, in terms of overall approach, you have to deal with degrading on your own, but that’s no different than any other JS based offering (or for that matter, any offering). (Tabbing and focus and keyboard events are all perfectly do-able also, not sure what you meant there, in terms of that and degrading, but that support is actually one of the things I would put in the GWT plus column, not a negative.)

Seems like, as Sean notes, you may want to do more sprinkling of widgets into your current web site, rather than building an application. GWT is web based, and can be integrated with existing stuff piece meal, but, IMO, it’s real leverage is in creating a complete rich *client* application – using JavaScript as it’s assembly language (as I think Arno Puder once put it – when talking about XML11, not GWT, but same idea).

So, you could make a TriplePaneLiquidLayoutWidget, which uses only DIVs, but you would then have to force the user to deploy your stylesheet via the module.

MyGWT/Ext go to the extreme, they perform layout not just in CSS, but in JavaScript. Needless to say, this has some downsides.

For example, first thing you should do is create your own “div” classes, “p”, “span” etc…

class Div extends Widget { // prob something else really
public Div(String style){
setElement(Dom.createDiv());
setStyleName(style);
}
}

That way you are programming like the rest of the world. GWT’s panel abstractions are crazy, and unecessary. Anyone who does webdev can understand div, span, p, a etc- so they should be available.

2. Graceful degradation can only occur with ajax enhancements, so your point is moot. if you want to add functionality you can do that with GWT, but I woudln’t. GWT is really for gmail style applications, which need two implementations (one for js, one for others).

If you want a fat client, use GWT (GWT/ext or mygwt are good candidates). If you want to sprinkle ajax functionality into an application that degrades gracefully, use jquery, moo or one of the other great frameworks.

Me personally – we develop fat clients, and use gwt and are very happy with it.

GWT for example, can do progressive enhancement if you want to, you just write providers for it. It would slow down compile times, but a GWT progressive enhancement toolkit would probably smash jQuery’s performance due to the way GWT deferred binding works. There’s multiple GWT UI libraries already, you’re not stuck with what google provides in the UI package.

GWT is not bloated. Most JS libraries are larger and slower. GWT supports i18n, l10n, and a11y in version 1.5 to an extent far superior than most hand written html/js apps.

Also, I’d say you’re cherry picking situations. I just went to biz.yahoo.com and saw them using the dreaded CENTER and FONT tags. Recognize, that Google is a huge company and not everyone codes HTML the same, just like Yahoo.

I used to be a member of the W3C working groups working on standards, and the reality is, although properly written HTML and CSS is a joy to behold, it’s just too much effort for the average developer to make apps 100% semantic, accessible, internationalized, localized, mobilized, and progressively enhanced. It’s cool when someone makes some small demonstrations of this ability, but the difficulty is one reason why developers need toolkits and tools.

Did you forget to put Aural CSS annotations in your sites?