Pathfinder Development » Angry at GWT

Angry at GWT

Dietrich Kappe, Thursday, May 24, 2007 @ 4:45 am

Ryan Doherty is an angry man. What is he angry about? He is angry at GWT. Why is he angry?

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.

Ryan sprinkles his gunpowder over four points in his blog entry, Why Google Web Toolkit Rots Your Brain:

Any time you program one language in another, you lose all the benefits of the target language
GWT completely ignores the fact you are creating a website, NOT an application
GWT is bloated
GWT does browser sniffing

Let me rebut the easiest ones first. So what I think that Ryan is trying to say with the web site versus applications statement is that we are developing web applications, not just applications. So emphasis is on "web." And Ryan thinks that if you are writing a web application, you should use web standards, not the funky, ugly code that GWT produces. I say make the code as ugly and funky as possible. Write clean Java code, then let the GWT compiler deal with generating the target Javascript code. As they improve the compiler, the quality of the HTML/Javascript/CSS will improve without my having to change my application code.

As for the browser sniffing, the GWT generates different code for different browsers and, once again, it is compiled. As new browser types and versions come out -- a very likely scenario in the world of mobile devices -- you don't have to decorate your code with lots of excess conditionals to test for browser properties. All those extra conditionals add up. And you'll have to rewrite your code (or library) to support other browser types and versions as they come out.

Now, is GWT bloated? Ryan's example is "Hello, World!" Not exactly a fair test, since most of the code there is setup and Java lib code; it would be better to look at a larger example. Plus, he counts in all of the alternate files for different browsers. Since they are generated by the compiler and don't have to be maintained seperately, you should count only one of them. Beside, he counts them in lines, not bytes. Last, lines of generated code versus lines of hand written code is misleading. Since many Javascript libraries do lots of initialization on loading and on object creation, you really have to count its memory footprint, not it's linecount.

As to losing the benefits of the target language, there are benefits and drawbacks to all languages. I'd say that for large, complex systems, a strongly typed language has its advantages. As I've already written, dynamically typed languages like Javascript have some pitfalls:

But code completion and tools are a bit of a red herring here. I've always felt uncomfortable with programming languages that depend on good programmer behavior -- essentially obeying code level idioms -- to allow for the development of large, interdependent systems. Alex Russell, in my interview with him, argued that Javascript was a "more powerful" language than Java and cited this paper by Lutz Prechelt that claimed to show that scripting languages are moe powerful and productive than the statically typed, OO languages (in part -- it's a simplification of the thesis). I agree that I can do in 1 hour in Perl what it would take me 10 hours in Java. I might even hope, as a single developer writing my own well understood style of OO Perl, to write a large application more quickly in Perl than in Java. But add in multiple developers, and you start to enjoy the complexity problem that Bruce Johnson mentioned. The same, in spades, goes for Javascript.

Ryan's complaints soundly eerily like those of the assembly language programmers throwing thier verbal sabots into the gears of early compilers. They would produce code that was bloated, poorly written, slow, etc. Programmers who used these higher level languages would rot their brains. That battle has been settled in favor of the compilers. No one would write substantial amounts of assembly code these days. The humans have lost.

With the likely inclusion of Tamarin (the ActionScript Virtual Machine 2) in future versions of Mozilla browsers, what's to say that future versions of GWT won't produce compiled bytecode for the Firefox platform?

Technorati : ajax, editorial, gwt

Topics: Ajax Frameworks, Editorial, GWT, Javascript

agile ajax

Comments: 5 so far

“Now, is GWT bloated? Ryan’s example is “Hello, World!” Not exactly a fair test, since most of the code there is setup and Java lib code; it would be better to look at a larger example.”

That’s the same excuse Sun used for the overly verbose “Hello World” in Java itself.

I don’t think it holds water, to say that is an unfair test.

Perhaps it would be accurate to say that GWT is indeed less suitable for small, simple, compact scripts — but — it is very well-suited to meeting the needs large, complex applications.

Comment by Joe Grossberg, Thursday, May 24, 2007 @ 11:09 am
Wow, I honestly never thought that my post would generate so much interest.

Yep, I was wrong about a few things with GWT. The Hello World example was a bad way to try to show GWT is bloated. I’m know thinking it’s not as bloated as I thought it was.

I still think GWT creates poor quality code (JS, HTML & CSS) and that you can create clean, semantic HTML, CSS and JS while creating the same exact applications/tools/widgets that GWT does.

And I’m not angry that GWT allows developers to create cool apps. I use jQuery, YUI and extJS and I’m happy we have these toolkits.

I don’t think the argument that Java creating Javascript is akin to C++ compiling to Assembler. Java and Javascript are both modern languages. The difference is more syntactical than abstraction.

I think you can write good or bad code in any language. Why should Java inherently create better code? Lots of arguments either way and I’m not convinced.

Comment by Ryan Doherty, Wednesday, May 30, 2007 @ 1:48 am
Java -> Javascript is hardly at all like C++ -> Assembler: C[++] is an abstraction on top of Assembler and designed to be automatically reduced to it. Neither Java nor JavaScript, however, is meant as an abstraction on the other–instead they’re largely incompatible abstractions. E.g.,

* Java uses class-based objects, JavaScript uses prototype-based objects.
* Java has static typing, JavaScript has dynamic.
* JavaScript has closures.
* JavaScript has first-class functions.

So not only are they different, but JavaScript is actually considerably more powerful. JavaScript can emulate most of the features of a class-based object system, but Java cannot emulate a prototype-based system. ‘Advice’ requires only a handful of lines to implement in JavaScript but requires language extensions in Java. Java can’t emulate closures or first-class functions (though of course you can write an interpreter in Java for a language with these features, like Rhino). Etc., etc..

So if anything, using Java to generate JavaScript is more like writing Assembler to generate C++. Which, to put it mildly, is a technique with few reasonable applications.

Comment by Joshua Paine, Wednesday, May 30, 2007 @ 10:18 am
“GWT completely ignores the fact you are creating a website, NOT an application”

GWT is intended for web applications development, not web sites. It’s fundamentally different from web frameworks such as Struts, Spring MVC, RoR etc. GWT is about developing web apps like desktop apps - and it benefits from it.

Comment by vaskas, Saturday, June 9, 2007 @ 2:00 am
Re: “… but JavaScript is actually considerably more powerful…”

Let’s say that power means “the amount of work done per unit of time.”

It could be said that development is made up of these types of work:

- Design
- Prototyping
- Learning the Language
- Writing New Code
- Understanding Old Code
- Refactoring
- Debugging New Code
- Debugging Old Code
- Reading Other People’s Code
- Debugging Other People’s Code
- Making Use of Libraries
- Making Libraries
- Refactoring Libraries
- Updating to Refactored Libraries

JavaScript and dynamic languages in general do well in some of these areas but not others

For example, “Writing New Code” seems to be the area of focus for advocates of dynamic languages, who see a big power gain there, and possibly in “Learning the Language”.

It seems to me, however, that Java is just as powerful as Javascript in the other categories, and much more powerful if you use an IDE with support for completion and refactoring.

Comment by Dobes Vandermeer, Sunday, March 2, 2008 @ 12:39 pm