28th Mar, 2008

Google Web Toolkit Follow-up

It’s been almost a year since I wrote Why Google Web Toolkit Rots Your Brain and I think that post deserves a follow-up.

I still get significant traffic to that post and the occasional comment or two. (Some people calling me an idiot or praising my criticisms.) I think most of the comments were warranted. I certainly didn’t know a whole lot about GWT and was wrong about a few things.

So here’s a rundown:

Things I was wrong about

Any web toolkit is bad

No toolkit is bad in any sense. They are good in that they can speedup development times for areas a developer is weak in. It can become difficult to fix bugs created/part of the toolkit, but that will probably be rare.

The way a toolkit can be bad is in it’s implementation. (Ignoring necessary standards, restricting features)

You lose the benefits of the target language

While this is true that you do lose the flexibility of JS when programming, there are benefits of using Java. I don’t like Java too much (although it was my first programming language), if your dev team knows Java well, stick with it. And you can embed JS directly (neat!) if you need to.

GWT does browser sniffing

I would still call this a poor design decision for a JS library, but in order to increase performance (which is becoming a hot topic these days), it’s mostly warranted.

GWT is bloated

While it does create lots of files, the user only downloads 1 JS file. That is a good thing in terms of performance because that 1 file is only what the user needs.

Things I was correct about

GWT ignores web standards

I’ve taken a look again at the GWT examples and the HTML is still pretty bad. Do we still need to use the <center> tag? I agree many people want to be insulated from browser quirks, but it could be done with proper, standards-based markup similar to YUI or jQuery UI. Semantic markup would make GWT apps easier to navigate for blind users too.

If there was 1 part of GWT that I would pick to fix, this would be it.

I would also say that a large majority of Google’s code ignores web standards. Even their accessible search uses display:none for a form label, effectively hiding from people using screen readers, their target audience. Google News, which could be rich with headers, paragraphs and lists, sadly is full of br’s, td’s and font tags.

Using semantic markup could also mean using a different stylesheet for mobile devices instead of completely different HTML.

GWT doesn’t gracefully degrade

While I’m not 100% sure it’s possible to gracefully degrade all GWT widgets and apps, some degradation is necessary. Turning off Javascript yields a blank screen.

Tabbing between elements would be nice, it’s possible to partially navigate in Yahoo! Mail via the keyboard, and it’s a pretty complex web app.

Finally

There are some good parts to GWT and some not so good parts. There are a few cases where it would make sense, but most of the time I’d recommend a good JS library instead. I don’t believe HTML and Javascript need to be extracted to such a high level. If you have the time, learn Javascript and use a Javascript library.

I hope this follow-up was useful, feel free to add your comments or thoughts about GWT, I’m sure we can get another good discussion going!

Responses

GWT isn’t just a widget framework. By far, the biggest and most important component is the compiler. It seems like you still haven’t spent any significant time with GWT or the GWT community.

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? :)

We hate tables for layout. I use firebug extensively, and make sure that our app has nice generated code.

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.

I think the issue is, if you want to do layout with CSS in GWT, then the widget panels would be much tighter bound with CSS. Consider doing cross browser 3-column liquid layout in GWT with tables, vs doing it with CSS. With CSS, the widgets become very much dependant on CSS, and I think they originally wanted GWT to be agnostic to the user provided stylesheet, unlike MyGWT and other libs which are very much bound to the CSS that ships with them.

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.

Ray, I don’t see your point. Your entire site with GWT relies on a modern browser with js enabled – why could you not ship a css file?

You still don’t seem to get it.

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).

Categories