Why Google Web Toolkit Rots Your Brain

Note: I have closed comments and written a follow-up post. Please post any comments there, thanks!

I heard about the Google Web Toolkit a while ago and it never sat quite right in my head. “Write Java that writes Javascript? This can’t be good.” After digging a bit through its generated code, my assumptions were correct.

I could probably write a senior dissertation on why the GWT (or any other web toolkit probably) is just plain bad, but I’ll stick to 3 or 4 main points.

Any time you program one language in another, you lose all the benefits of the target language

This isn’t just specific to GWT, it happens with any code generation. When you are using one ‘source’ language (Java) to program in another ‘target’ language (Javascript), any niceties and benefits of the target language are lost. You will only think in the source language. It’s similar with spoken languages, sometimes there just isn’t a good translation for certain words or phrases in French for English or English for French.

Paul Graham wrote a great comparison of languages in his book Hackers and Painters, so I’ll use his examples because they will be better than mine, :)

Say you need a function that takes a number n and returns a function that takes another number i and returns n incremented by i.

In Javascript the code looks like this:

function foo(n) {
    return function(i) {
        return n += i } }

In Java, it really isn’t possible, Paul Graham’s example that he borrowed from Ken Anderson says this is as close as you can get:

public interface Inttoint {
    public int call(int i);
}
public static InttoInt foo(final int n) {
    return new Inttoint() {
        int s = n;
        public int call(int i) {
            s = s + i;
            return s;
        }};
}

The only problem with this code (aside from the fact it’s incredibly bloated compared to the Javascript version) is that it only works for integers. Oops.

Now pretend you needed to write this problem in Java to write it in Javascript. Could you do it? You could if you hard-coded it, but then you have only solved your problem that one time.

The issue is your source language just can’t understand differences in the target language without significant or downright impossible coding. You might as well just write your Java as if Javascript worked the same way. Any benefits or niceties of your target language are just plain ignored.

GWT completely ignores the fact you are creating a website, NOT an application

This one is a huge issue for me. Many smart people and groups have been advancing web standards, layered semantic markup, accessibility, graceful degradation, progressive enhancement and more. GWT just completely ignores this. “Program in Java, and everything is taken care of!” What if I’m blind? Have Javascript turned off? (Blank page) Use a keyboard? (The reason I raise the keyboard issue is that in order for a form button to work for both a mouse click and keyboard enter is to attach TWO event handlers instead of just creating a form and attaching an event handler to its submit event).

GWT goes against everything we’ve worked towards in web development. Many of their widgets and layouts create endless tables, rows, and columns littered with inline CSS, “center” and “align” tags. It’s a disgrace to the web industry as a whole and a HUGE step backwards.

I think this problem is a subset of a larger problem. Google uses the web as a thin layer on top of their technologies. The web layer is a very small, unimportant part of their applications.

GWT is bloated.

Let’s examine how many lines of code are written and generated for a “Hello World” program. (Click on a button, get a Javascript alert box with “Hello World”)

Files written manually:

  • Hello.java : 20 lines

Files generated:

  • 1F4D87B2C98472D82FC9C3D073EE779F.cache.html : 330 lines
  • 1F4D87B2C98472D82FC9C3D073EE779F.cache.xml : 8 lines
  • 8A9E9BC47299054FFD3152D7300314F6.cache.html : 330 lines
  • 8A9E9BC47299054FFD3152D7300314F6.cache.xml : 8 lines
  • 68005B0D796B54D5D78280E1C5DFA3A8.cache.html : 329 lines
  • 68005B0D796B54D5D78280E1C5DFA3A8.cache.xml : 8 lines
  • B3D8C6C5F322CA1C97E93F4EA131CF0B.cache.html : 330 lines
  • B3D8C6C5F322CA1C97E93F4EA131CF0B.cache.xml : 8 lines
  • com.google.gwt.sample.hello.Hello.nocache.html : 105 lines
  • gwt.js : 591 lines
  • Hello.html : 9 lines
  • History.html : 20 lines

In order to do the same thing with pure, clean HTML and JS it takes 2 files and about 50 lines of code.

GWT does browser sniffing

Once you get into any JS development you learn quickly that it’s a much better idea to sniff for browser properties instead of browser versions. It’s browser agnostic and provides forward and backward looking code. Suppose one day browser X gets a new feature that was in browser Y that is the proper and faster way? Don’t worry, your code automagically works and performs better.

The reason GWT does browser sniffing is to load completely separate JS files for each browser. I can’t imagine attempting to debug a large application created by GWT. Especially if for one reason or another you are on a machine that doesn’t have GWT or Java. Good luck!

And more…

I have a few other problems with the GWT, but I’ll stop here. The bottom line is GWT doesn’t give a damn about the web and treats it as an inconvenient interface that needs to be avoided at all costs. And it does, but to a terrible outcome. The developers obviously do not understand the paradigms and principles of the web. It’s amazing the amount of work they put into creating this Java based toolkit when quite possibly a lesser amount of time could have been spent working on a great Javascript/HTML/CSS library (YUI, jQuery, Ext, Scriptaculous) that would promote web standards.