GWT

From Zanecorpwiki

Contents 1 Pros 2 Cons 3 Considered Harmful 4 Summary 5 Notes

Pros

• The UiBinder stuff (build interfaces out of XML) is nice a nice option. I haven't seen a similar offering from the AJAX camp (though I expect to).
• In my experience, the Java tool set is the best available and much (though not everything) in the Java tool stack is GWT compatible.
• GWT is probably the best way to get JavaScript into the enterprise.^{[notes 1]}
• Overall excellent general documentation and support, though there are some thin spots.

Cons

My only really severe criticism of GWT is ecological. I talk about this in the next section. For now, let's go over the less important technical quibbles:

• Not really a problem with GWT itself, but if you don't already know AJAX, you should learn plain old JavaScript style AJAX fist. The asynchronous conventions are more elegant and natural in JavaScript.
• GWT's HTML is horrible. You don't need to get too complex before you end up with a dozen nested tables. There's zero semantics in the DOM.
• Forget the instant turnaround inherent in AJAX development; a simple "Hello World" compile on modern hardware takes 30-60 seconds.^{[notes 2]}
• GWT is too clever for it's own good sometimes. Dig around in GWT enough and you'll find plenty of rough spots. The project has a real problem with introducing clever ideas, but never doing the drudge work necessary to polish things.^{[notes 3]}
• On a related note, GWT tends to address problems by adding even more cleverness, when in fact just simplifying the original approach would be much more productive and useful.^{[notes 4]}
• GWT looks like Java but it's not. Even basic stuff, like Math is not available and you won't be able to plop in your own libraries without extending some GWT object. You could say that JavaScript isn't Java so this is a wash, except JavaScript doesn't confuse you on the point.

Considered Harmful

I've honestly grown to like GWT, which is why it pains me to conclude that GWT should be considered harmful. The problem is that GWT competes with web services, but doesn't implement the social contract of web services.^{[notes 5]}

The idea of a neutral backbone is key to the web services idea.^{[notes 6]} I don't think GWT even considers itself part of the web services crowd. They talk about accessing web services from GWT, but they don't really talk about GWT as a web service.

Clearly GWT is not a web service. However, every time you're using GWT, you're supplanting a web service.^{[notes 7]}

Summary

I want a world of rich web services, and having a company like Google push an anti-web service is really a shame. Especially since GWT could be web service compatible so easily. Instead, we have a technically impressive tool set that essentially does what applets where meant to do: implement Java on the browser. Party like it's 1998.

But this is 2010. Technical tricks aren't interesting anymore, what web developers should be thinking about is ecosystem. Ecosystem means REST+XML web apps, consumable, mashable, scriptable, empowering services across agnostic communication channels.

Professionally, it's kind of like the old saying: "You'll never get fired for buying IBM." GWT is safe and it'll make lots of people happy. But by the same token, GWT is not a platform for innovation or integration. It's the best old-school platform.

I'll develop in GWT and be happy doing it. I could even see myself recommending GWT in certain cases. But GWT has no part in what I find exciting or important about web development writ large. There's no big picture with GWT. There's no evolution or emergence. There's no excitement.

Notes

1. ↑ The combination of available tools and technical features (like strong typing) make JavaScript particularly challenging for large, mixed-skill teams. The same factors make Java ideal for large, mixed-skill teams. I.e., JavaScript makes it's very easy to shoot yourself in the foot; less so with Java.
2. ↑ There's lots GWT could do to speed up this compile. For dev code, don't do all the optimizations and don't bother to emit multiple versions of the code. Let me tell you the browser I'm using and get me the code as fast as possible. So this *should* get fixed... if it weren't for the next problem.
3. ↑ You find a number of excellent introductions, but can't seem to find any real world examples or intermediate questions. There's a serious issue in CellTable that's been active for over six months at the time I write this. The behavior is fine, but the issue isn't well documented, how to get the more standard/expected behavior isn't laid out anywhere. I've seen this "clever" GWT behavior interact poorly the pager and table to produce more serious erroneous behavior and the docs and examples are simply not sufficient to elucidate the point.
4. ↑ GWT "Hosted" mode, used for development, is a case in point. Hosted mode's raison d'être must be the long compile times. There are some things you can do in hosted mode (like GWT log) which don't work in dev mode, but there are obvious and simple remedies to those problems. The compile problem is the only obvious sticking point as far as I'm concerned. But this raises the question: why not just make the compile cycle shorter? I've already outlined a very, very simple change to the compiler that would cut compile time by 80% (for dev, just target the browser the developer is using). Remove code optimization and other stuff, and there's little question that you could get development compiles to be much faster than hosted mode. This would allow the developer to always test on the real thing and remove a big idiosyncrasy from GWT development.
5. ↑ With 2.0, there is a REST-add on third party library that could help on this point. But I haven't used it, and in any case, even if you *can* do good neutral REST, the fact that you have to jump through hoops to get it is a pain.
6. ↑ REST+XML/JSON being the clear winners. Things like SOAP, XMLRPC, and GWT's custom serialization protocol have their place but IMO are inferior to REST+XML/JSON.
7. ↑ Unless you plan to implement it both ways... which I can't imagine is a good idea. The overhead isn't worth it, just go AJAX and drop GWT.