29th Apr, 2007

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.

Responses

Some people don’t use Hibernate because it generates SQL. Other don’t use C because it generates ASM…

@dgirard

From what I know of Hibernate, you can write your own SQL in it and it doesn’t generate improper SQL. I think there’s a difference there.

Sometimes you can use one language to generate another, but you will have a tradeoff. Many ORM toolkits don’t completely abstract away from SQL, they just abstract the common stuff.

I have no experience with C, so you’ve got me there ;)

Sounds like some of your criticism of GWT is based on a bit of misunderstanding of the philosophy behind it. If you haven’t read it, the GWT charter might shed some light on the GWT approach:

http://code.google.com/webtoolkit/makinggwtbetter.html

A couple of specific things I want to clarify:

- GWT doesn’t need to own the page; it can interop very well with HTML, CSS, and JS libraries

- GWT lets you mix in JavaScript directly with Java source, so you can use whichever language suits your need for different purposes; see http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.JavaScriptNativeInterface.html

- Regarding your comment that “GWT is bloated”, you might be interested in a similar blog article written by Hallvord Steen: http://my.opera.com/hallvors/blog/2007/03/27/how-to-say-hello-world-with-javascript The comments discuss some of the non-obvious benefits of the GWT compiler, and specifically address why it is a mistake to infer too much from the “Hello” example.

While you may still choose to disagree with some of the technical decisions in GWT (e.g. browser-sniffing vs. capability detection), perhaps you’ll take my word for it those decisions lead to some very significant size, speed, and usability advantages in GWT code.

@Bruce

I’m glad you didn’t take my criticism too hard, :)

Thanks for offering counterpoints. I’m glad to hear my first interaction with GWT wasn’t completely accurate and that it’s not as bad as I thought.

It’s pretty cool (although could be confusing) that you can inline JS with your Java.

I’m still on the side of using pure JS libraries. Personal preference with its own benefits/drawbacks.

Good luck with GWT!

Ryan,

I posted this on my site when it first came out and I agree with you.

This seemed a little strange for Google to take this particular path. I was expecting an online IDE or something. :-)

http://www.dcs-media.com/webx0/Detail.aspx?ArticleId=336

Responding to C and Hibernate example:

I think code generation makes sense if you use a more expressive language to generate code in a more verbose, less expressive one, to avoid mechanical work.

In this sense it makes perfect sense to automatically generate ASM, SQL. As for Javascript/Java I completely agree with the first point. In this sense it would make more sense to generate java code from javascript.

Just a quick comment. I think the intended benefit of GWT is that you can use the type safety and refactoring comfort of Java to program against a browser framework. And as usual, it’s not a question of “all or nothing”, but a tradeoff of different advantages and disadvantages.

GWT is useful for creating web applications, not necessarily web sites. Web applications focus on functionality provided to the users of the app, while sites focus on the presentation of the information. There is big difference between the two.

You’ve got it all wrong. Counterpoints for all:

1. You lose the benefits of the target language.

Ah, but you gain the benefits of the source language. Just to give you a specific example: You can’t use reflection in GWT which means the entire code base is 100% statically analysable. GWT excludes a method if you never use it with perfect accuracy. No JS toolkit will ever offer this as smoothly as GWT can, because JS is not statically typed.

Also, you can program in Javascript (using the JSNI mechanic) if what you want to do is better suited to JS. You can even interact between JS and Java quite easily.

2. website vs. app.

“completely” ignores? No. It’s certainly intended for ‘app-like’ sites, like e.g. gmail. However, you do get working back/forward buttons and URLs that you can save and bookmark. You just need to do some minor logistical effort to make it work - it’s called the GWT History system.

gmail doesn’t work well for blind people either. This is certainly a problem. HOWEVER, GWT builds web APPS not web PAGES. There’s a crucial difference. You can embed web PAGES in GWT, no problem. (HTMLPanel and the HTML widget are one strategy. You can also embed GWT on an existing page and use GWT simply to change what’s there for extra functionality).

bloat: bull. GWT produces some of the smallest files in the toolkit business. Serious-sized GWT apps are 50k or so. The initial ‘cost’ is heavier than usual but from there the size increments very slowly.

You also make a very crucial mistake when listing the directory contents: You didn’t use firebug’s NET tab. Only ONE of those .cache.html files is loaded for any one browser. Each version of the .cache.html file contains code tailor-made for a certain ‘type’ of browser. GWT can generate a lot of those files, if you end up with a lot of types (For example: IE-english is one type, IE-spanish is another, Gecko-compatible-english would be a third, etcetera). Because each edition only contains what’s neccessary for that specific version, GWT is smaller than code that tries to if/then its way around browser quirks.

Just because in GWT the whole browser sniffing issue is more visible doesn’t mean there are reasonable alternatives out there that don’t use it. It’s just that most other toolkits integrate their sniffing into a single .js file so you don’t “see it”.

GWT does actually sniff browser properties to a large extent. Currently GWT sniffs on rendering engine only (gecko v. webkit/konqueror v. opera v. ie), and optionally tries to pull in version data, but if it can’t match the version to something it knows, it just matches it to the nearest version. I highly doubt we’ll be seeing other rendering engines in the near future that would be capable of running gmail-like sites in the first place. So, give GWT some time to evolve beyond the sniffs. Rome wasn’t built in a day.

FWIW, it won’t be too difficult to create a fifth ‘browser-type’ path that simply checks, live, what way a browser appears to want something (e.g.: do we have an attachEvent or an addEventListener method?) - however that particular set of versions of the cache.html file will be considerably larger. The best of both worlds: Any browser will work, past or future (at least as well as using any other framework or hand-rolled JS will), but if you use any of the browsers that together make up 99% of the market, it works better and downloads faster. What’s not to like?

For someone who starts his post off with his prejudice on his sleeve, you’ve managed to brilliantly confirm you knew the outcome of your test beforehand, and you’d be damned if actual effort to learn what you’re ranting about would get in the way of your opinions. Well done. Open minds are for wimps!

programming for the web is a complete mess. pure JS/html/css is a nightmare. GWT is a step in the right direction, i won’t go back to what i was using, but the best idea would be to blow up this disaster we call web applications and start over.

Horrors, this is like writing in C to generate assembly language…hey wait a minute, that is how compilers work!!!

Seriously—there may be drawbacks to their scheme, but in principle you can write optimizers which usually make the automatic translation superior on a large body of code to even skilled target language programmers and …

You wouldn’t complain about the verbosity in the .S compiler intermediate assembly files. In the end what matters is the end result not how we got there. I am not denying that it may be a suboptimal approach for Google’s particular purpose, but it’s not because of the translation idea alone.

I’m not sure I buy your argument about using java to generate javascript. It may be true in this case (I haven’t used GWT), but I don’t think you can make the broad general claim you and Paul Graham make.

For example, rails lets you do a lot of nice stuff with AJAX using partial templates. And when you try to crack open why it’s easy to do AJAX in rails, I think that a big part of it is that you’re replacing one logical description of the page for another.

Instead of thinking about the DOM, in all of its complexity, you’re thinking about a really simple logical structure of a page that flows out of the structure of the template files that are used to generate it. In rails you don’t say, update this part of the DOM — you say, update the part of the page that was generated with this template file.

It seems to me that this is the same kind of translation that you’re talking about when you say that you shouldn’t go from java to javascript. It does suffer from the big problem you point out — you do give up power and nuance. There are things you can do when you tweak the DOM directly that you can’t do when you think of the logical structure of the document as rising out of those partial templates.

But in exchange for giving up that nuance, you get a massively simplified situation, and a great deal of elegance. It’s really easy to use AJAX in rails, and it’s easy to maintain AJAX in reails — that’s a huge win.

I can understand someone saying, “My brain is bigger than yours, and I don’t need this simplification, and I’d rather have the power.” And I can understand someone saying, well, there are things that I need to do that make it impossible for me to accept the tradeoff between power and simplicity.

But I can’t buy the argument that it’s *never* reasonable to make that trade, as a general principle.

Check out the Junction project at
http://scaffold.jupiterit.com

for an open source javascript development enviornment

If you can’t sit down and whack out the code you need in a text editor, [a] it’s already bloated and [b]
all the libraries and toolbars in the world won’t keep you from adding yet another chunk of cholesterol to the World Wide Wienerschnitzel. Practice all you want in your own browser, but LEARN your language(s) of choice before you start publishing stuff. Yeah, I know, it’ll happen right after politicians tell the truth and CNN airs real news.
(Sigh)

I could be wrong here, but I think the real point of GWT is to let the teeming masses of people who know Java and nothing else build ajax sites without learning much new.

The irony is that people who like
GWT agree whole heartedly with his summary - that’s why its good. The web IS an inconvenient piece of crap that needs to be abstracted away so the developer can concentrate on whats important.

“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.”

Uh-huh. Translation “I spent my entire career learning all this stuff and now some idiot can come along and write a web application from a zero-knowlegde base in 3 months? ARRGHHHHH!!!!”

The “terrible outcome” - 100s of kilobytes (kilobytes mind you!!) of bloated, badly structured javascript that can do the same job as 50K of beautifully handcrafted javascript. Emphasis on _same job_.

the bit where he tells google they dont understand the web is priceless.

@Everyone

Good discussion all around, :)

As far as type safety with Java, I really don’t feel and haven’t had a need for it. I started programming with Java and then moved to PHP, JS and Ruby. I haven’t once though “hey, I really need some type safety”. There might be some extreme cases where type safety is necessary, but in my experience I haven’t needed it.

Refactoring can be done in any language, not just Java.

There are some benefits like people have said to use GWT, but I think the outcome outweighs the benefits.

I was wrong with the fact that GWT is all or nothing. I’m glad to hear you can use it as little or as much as you want.

Serious sized JS libraries and/or JS files for web apps/sites are around 50k also. Some less, some more. Jquery is 20k, YUI starts around 3k and can go up to around 30-50k, depending on what you use. And many other JS libraries can do similar if not the same things GWT can do. (tabs, treeviews, history management, etc)

When I listed the files created by GWT, I knew only 1 was downloaded per client. I didn’t explain that, but I knew it.

The Rails framework does make it easy to do Ajax also. It does by default also create inline JS that breaks if JS is turned off. There is a patch for that thankfully. Rails ajax helpers are a little different in that they don’t create huge JS apps, they just add bits of functionality. I don’t think they are in the same league as GWT.

Using Java to write JS is not the same as using C to write assembler. Java and JS were created around the same time and are both high level languages. I’m no expert on C or assembler but I will guess that doing something in C will always be easier than doing something in assembler. Java code vs JS code to do the same task (no GWT) would probably yield similar results in implementation and code length.

I’m not quite sure how programming for the web with js/html/css is a mess. It’s pretty clean. HTML for content, css for presentation and js for behavior. There certainly are issues with the implementation of each, but most are well known and documented. Browsers aren’t perfect, but they are improving.

No idiot could come along and build a web application from zero knowledge. If they could do it with GWT, they could most likely do it with JS and/or a JS library. I’m not angry that GWT can help people do things they normally wouldn’t be able to do, that’s what other JS libraries do too. I’m not happy with the implementation.

We have full JS libraries to help us abstract away from the inconsistencies of browsers. Why should we abstract away into another language when we have a very powerful language built into browsers?

Yeah, I am biased. I think it’s best to develop libraries that help you written in your implementation language. I still took a look at GWT to see how it actually worked.

The web doesn’t need to be abstracted away forever. It needs to be FIXED!

I still think Google doesn’t understand the web completely. Yes, they totally understand how to get apps onto the web, and they are really great. But they don’t seem to have any knowledge of web standards, proper markup, accessibility and graceful degradation/progressive enhancement. This doesn’t relate completely to GWT, it’s to most Google apps.

yeah? well this idiot did. I had not one idea about developing a web application. Learning to use Hibernate took most of that time. The client side was a snap.

type saftey? lines of code? what has that to do with anything? its so obvious that this random and mostly irrelevent collection of ‘points’ youve listed is nothing more than a (poor) attempt to back up your pre-conceived opinion.

If you want to prove anything, show us how a web application implemented in GWT is inferior to build, test, maintain and USE than a web application using whatever grab-bag of tools and techniques you favour.

you cant, because youve never developed a web application in GWT, have you?

About graceful degradation:

I think the solution to graceful degradation is actually the use of a non-JavaScript toolkit (like GWT could be) which does not rely on JavaScript per sé.

For example, consider Wt (http://witty.sf.net), which allows a single implementation of event handling code to be either client-side JavaScript, server-side AJAX-based interaction, or plain CGI/HTML server-side interaction.

Obviously, you can never achieve this when you force the developer to produce JavaScript code. GWT could achieve it, I guess, but they either don’t care about it, or they haven’t realized they could, or they have messed up the design of their library.

Regards,
koen

The simple answer of a few folks here, that what’s the big deal, this is what compilers do, is a flawed argument. Going from C to ASM is from a high-level language to a low-level language. Going from Java to Javascript or Hibernate to SQL is more of a sideways move, and in the case of Hibernate, it could be debated that it’s actually worse, i.e. going from clean and simple SQL to cludgey Java mapping. In fact, Java coders are envious of a few Javascript features, just as they are envious of Ruby.

But I agree with the other posters that there are advantages to GWT, mainly tested code and running on all browsers are the most important IMO, however less important now that there are great Javascript libraries available now like YUI.

One significant point that all GWT-philes here haven’t listed, and was a decisive factor for me, is that the java code you write also runs in a JVM.

I used to write Java code for the server-side, and then translate it to javascript code for the client-side. I cannot describe to you the maintenance headaches. GWT solves this instantly.

BTW, the “hello world” example is such an exageration. It’s like comparing a “hello world” web app done in Struts vs. one done in HTML — irrelevant.

“programming for the web is a complete mess. pure JS/html/css is a nightmare. GWT is a step in the right direction, i won’t go back to what i was using, but the best idea would be to blow up this disaster we call web applications and start over.”

Quite succinctly put. Just to put it in context: I’m somewhat of a JS specialist (not entirely by design, rather by accident) nowadays consulting for large coorporations to straighten out their Ajax nightmares. And it’s a mess out there I tell you.
In the real world, where there are a lot of different responsibilities when it comes to website/webapp creation (designers, backend programmers, frontend programmers, content providers etc), and the problems quickly mound up becoming a maintenance nightmare. Not that any of the technologies are bad, they are good for what they were meant for, but the layering of presentation logic that oh so easiliy can happen, and the fact that JS at the end of the day is a dynamically typed scripting language leads to the aforementioned seemingly inevitable nightterror. Java and similar languages were invented for a reason, and one of them were to insulate the programmer from his own shortcomings. Sorry for the star trek reference, but you need to have a company full of borg and only hire consultants that are borg to work in complete unison, aware of eachothers every thought to make the current hotchpotch that webapplications are, work. Work well anyway. Sure GWT has it’s own set of problems, but they are minescule in comparison. Resistance is futile.

I agree with bruce, GWT builds webapps and not web pages.
Writing code in JS is fun but writing it in gwt is wiser.

I think everyone can agree that javascript dev for crossbrowser is a nightmare on elm st. I also think that a well documented , easy to use library to erase all cross browser inconsistencies is necessary.

So it seems that a big question is: is it better to use JAVA to abstract js or is better to use JS libs to abstract js? or does come down to situation? I could see that using java used for larger and more complicated web apps maybe be more manageable , but could have a steeper learning curve and longer startup time, plus of course you need to know JAVA…. Where JS libs may turn out to be quick and fast but eventually become complicated to manage. These are only guesses because i am just looking into both. Has anyone had experience in yahoo apis, (which look incredible simple) and gwt , and how they compare in feel, ease of use ? and can suggest when to use and when not to, if at all?

As a developer, the question I ask myself is “What is the easiest, most productive technology that will give my users the best experience?” Well, I’ve written web apps in JSF, Rails, Struts and GWT, and the answer is clear: GWT.

Ask me if I care that it doesn’t use CSS for page layout. I’ll ask you, “Does it look good in all browsers?”, to which you reluctantly reply “yes”. Inherent cross-browser compatibility is one in a long list of HUGE pros that GWT has going for it. Sometimes, very rarely, you can have your cake and eat it too.

Also, there are two points that have not been stressed enough. First, GWT does NOT have to control your entire web app; GWT can be embedded as a small part of any web page. Second, GWT provides for writing JavaScript directly, so any limitations of Java-JavaScript compilation are irrelevant.

Switching to GWT is like switching to Spring; you never go back.

This is one of the best threads on GWT I’ve ever Googled. Not too much flame, either.

Just blogged about a similar issue with GWT only from a web designers point of view as someone who is trying to customise the UI for a GWT application - http://markrushworth.com/template_permalink.asp?id=168

I’d prefer reading in my native language, because my knowledge of your languange is no so well. But it was interesting! Look for some my links:

I just want to say this is a great discussion. I am evaluating GWT and so I was looking for some counter points to it. I am biased because I already know Java, but it is great to read some alternate view points. I am leaning towards GWT because I am not a JS expert and I like the idea of having one code base. You do give up some things with GWT, but having one code base (Java) with seamless cross browser support is very tempting. Anyway, I am glad I found this entry. Great job, Ryan.

Categories