Thursday, June 7th, 2007

GWT a Year Later: Was it the correct level of abstraction?

Category: Google, GWT, Interview

>A little over a year ago, we published an editorial entitled Google Web Toolkit: The correct level of abstraction? In it, Dion raised some important questions about GWT:

  • Isn’t debugging generated Javascript going to be messy?
  • Wouldn’t the large size of the generated Javascript make it’s use infeasible?
  • Where is all of the cool stuff, like effects libraries, etc.?
  • Is generating “assembler” in Javascript really the right level of abstraction?

Now that a year has passed and people have had a chance to experiment and develop with GWT, I thought it would be a good idea to revisit these questions. I interviewed GWT practitioners Dr. Adam Tacy and Robert Hanson, who — aside from working on commercial projects featuring GWT — have just finish their first book on the subject, GWT in Action: Easy Ajax with the Google Web Toolkit. They were kind enough to answer a few of my questions.

Q: Has debugging with GWT been a nightmare akin to the early C++ compilers (or RJS), or has hosted mode solved most of those problems?

Debugging GWT code is as easy as debugging any other Java application. Just open up the Eclipse IDE, and launch the application in debug mode – the key is to really harness the power of the Java IDE and tooling to ease debugging. There may be some quirks here and there, but in general it is a very pleasant experience.

An issue that is sometimes raised by newcomers to the tool is the lack of a “debug window” component for the JavaScript (think of YahooGUI widgets, etc.) – but that basically misses the point of GWT where 99% of debugging can be applied to application logic in your Java IDE. If you want to hang onto the “printf/println” style of debugging, then in hosted mode it is possible to log to the hosted mode console. For client side code, GWT could be improved to allow for Log4J style log levels. But why would you do this in general when you have access to the powerful debugger in your IDE?

Once you get out of the hosted browser and deploy the project to your site, if there is still a need for debugging you can use the same debugging techniques as you would with any other JavaScript application. Some of our favorite tools include Web Developer and Firebug, two add-ons for Firefox.

One of the initial complaints from JavaScript developers was that the JavaScript code generated by the GWT compiler is obfuscated, and impossible to debug. To quote the Ajaxian story from a year ago, “I can’t imagine how scary it will be to have a JavaScript error show up in a browser talking about line 2123 which has “a[b] = push(c)” in it”. The author of that piece missed the rest of the story.

On the few occasions that you have an error that can’t be debugged from the Java IDE, GWT gives you the ability to alter the output of the GWT compiler. You can select from two levels of verbosity (“pretty” and “detailed”) that will emit JavaScript code that can easily be mapped back to the Java source. Once you have your “pretty” or “detailed” JavaScript, you can easily insert debugger commands to be picked up by a JavaScript debugger. You could use this verbose version of the JavaScript code when you deploy your application to production, but it is usually desirable to use the default mode of the GWT compiler, which is to compress the code as much as possible.

At another level, GWT has a powerful concept called Generators, which effectively auto-generates code for you (GWT itself uses them for its RPC, i18n, and JUnit integration approaches). Generators do get a hook into Log4J style log levels, and when running hosted mode or compiling for web mode you can follow the compiler decisions that led to the generation of code you are using – this leads to an easy way of debugging that, for example, could detect that GWT hasn’t picked up the latest locale you added.

We have never had any problems debugging a GWT application – and don’t forget, unless you are trying to do something really at the edge of the underlying technology (DOM, HTML and JavaScript), using GWT lets you concentrate on debugging your application logic rather than on browser differences.

The other benefit of GWT is of course the use of a strongly typed language – which reduces the probability of introducing errors in the first place. In our development experience so far, there has only been one occasion where we’ve had to drop down to JavaScript debugging – and that was really to understand what Opera was doing under one particular circumstance with the underlying DOM!


More…

Related Content:

Posted by Dietrich Kappe at 9:03 am
11 Comments

+++--
3.8 rating from 36 votes

11 Comments »

Comments feed TrackBack URI

There is an issue with GWT. It renders markup code but it does not take into account the page Doctype. The page may look the same is quirks mode but no guaranty if you switch to strict or transitional mode. Looking at GWT examples and forums they all start from tag, not very attractive for standards junkies.

Comment by Bono — June 7, 2007

“Java clearly has some advantages for writing larger applications – modularity, easier to implement common design patterns, type safety”

Spoken by a person who does not understand Javascript. Every design pattern available to Java can be achieved in Javascript. The manner in which you create the design pattern is obviously different.

Actually, because Javascript is so flexible, there are actually many, many more possible design patterns in Javascript than in Java.

Ok. Type safety is lacking, but only until Javascript 2.0 arrives.

Comment by John Hann — June 7, 2007

Bono said: “…issue with GWT. It renders markup code but it does not take into account the page Doctype”

Yup. GWT isn’t perfect, but it is pretty cool. There are a lot of people working on it, and things get fixed in order of popularity. For me, I am more interested with getting xhtml support fixed so that I can get beck to work on my SVG widgets, and maybe even start working on some XUL ones as well.

I would assume the doctype issue will eventually get to the top of the list, I have seen mentions of it before on the forum. If it is a concern for what you are working on, and it is important enough for you to create a fix, you should jump on the contributors list and offer up some patches.

Comment by Robert Hanson — June 7, 2007

John Hann said: “Spoken by a person who does not understand Javascript”

That is fairly presumptuous.

John Hann said: “Every design pattern available to Java can be achieved in Javascript.”

Well… I guess. I have a hard time with the lack of interfaces or abstract classes. Sure, you can implement an OO pattern that uses an “interface” in JS, but I just feel that without some sort of language driven contract it just isn’t the same.

John Hann said: “Type safety is lacking, but only until Javascript 2.0 arrives.”

That will be really cool. I’m just afraid how long it will take to actually see it. First you need adoption, then you need users to upgrade. It toos MS something like 5 years to get IE7 out the door.

Comment by Robert Hanson — June 7, 2007

” I would assume the doctype issue will eventually get to the top of the list, I have seen mentions of it before on the forum. If it is a concern for what you are working on, and it is important enough for you to create a fix, you should jump on the contributors list and offer up some patches.”

“who — aside from working on commercial projects featuring GWT — ”

Why don’t you do it? Aren’t you getting paid for this? I couldn’t care less about making your pockets larger. I stick to my good old JS and HTML.

Comment by Bono — June 7, 2007

Bono said: “Why don’t you do it? Aren’t you getting paid for this?”

No, but I wish I did get paid for doing work on the GWT code. I don’t work for Google.

Comment by Robert Hanson — June 7, 2007

It has been said that design patterns are a sign that your language is broken. You have Visitors because you don’t have multimethods, you have Iterators because you don’t have generators, closures, first-class lists, map/reduce/foldl/foldr/etc.

So sure, JS is so flexible, you can have any module system you want, and in raw C, I can have any form of inheritance I want. The problem is, you have to build all the tools to leverage whatever roll-your-own module system you invent.

For example, if you want to even come close to achieving some of the code size reductions and optimizations that the GWT compiler makes, you have to write a Javascript compiler that has implicit awareness of whatever module and OO idioms you are using. (see my blog post on the GWT compiler)

Why do language zealots have to turn everything into a fight over which language is best? I use both JS and GWT, there is a time and place for both. Would there even be a debate if GWT was a Lisp/Haskell/OCaml to JS compiler? JS is a great language, but the publicly available tools for it don’t make managing gargantuan code bases easy, and don’t produce packed code which is as optimal as it could be.

And if there’s anything that’s going to kill an RIA experience, it’s bloat and load time.

And if there’s anything that kills productivity on a large JS code base, it’s trying to debug it with Firebug vs a Java debugger. My GWT Chronoscope application is 15,000 lines of code, and I debug it with both Java debuggers and Firebug (if browser specific issue), and Firebug’s debugger in no way compares to the productivity of IntelliJ IDEA’s or Eclipse’s.

Comment by Ray Cromwell — June 7, 2007

The comparison with “generating assembly code” is fine, but what about the fact that TCL/TK has been used by productive folks in all of its variations (combined with Python, Ruby, Perl, in its original TCL binding, and so on)…

And what about the fact that the loosely coupled HTML+JavaScript+CSS has been such a partial success up to this date on its own, without being generated like in GWT? :-)

I mean, it’s wonderful that GWT has an engineering approach to Web programming, which could eventually prove to be useful and even become mainstream. Meanwhile, its approach may be too cumbersome which might ensure to it a niche, but not mainstream acceptance necessarily.

I don’t favor GWT because I think it makes development much more painful, and I gather that only by reading this interview, imagine if I had tried it out! :-) But the home hobbyists and the “designers”, like me, may not find GWT so entertaining, which is sad in part as it may mean that GWT won’t become the silver bullet for mainstream use.

That said, cross-browser heavy JavaScript programming is very painful when you need to support Safari, Opera, IE and Firefox, and if GWT allows for more complex JavaScript applications, all the power to it! I want to see very complex JavaScript applications being built, if only to help things improve for me as a user and a developer.

Comment by Joao — June 7, 2007

It’s hard to think there’s not some brainwashing going on when people say “Debugging GWT code is as easy as debugging any other Java application”. That’s clearly a reflexive statement that hasn’t been thought out.

I’d believe “almost as easy”, I’d believe “the benefits of GWT far outweigh the more difficult edge cases in debugging”, but don’t say it’s “just as easy as any other Java app”. The JVM failure behavior is designed to be compatible with the structure of java code (e.g. throwing emailable stack traces _without_ being run in a debugger) — whereas a javascript engine is not designed for that. You have to go into much more depth to prove that there are _no_ extra complexities there.

Comment by Trav — June 8, 2007

The previous comment seems like splitting hairs, and also seems like you’ve never used GWT Hosted Mode. Even when you’re not in debugging mode, you still get stack traces, emailable, with source line numbers, etc you just don’t get them in Web Mode, or if the exception originated in a JSNI method. For all intents and purposes, anyone familar with Java debugging won’t find the experience that much different or alien.

Even within Java, debugging different kinds of apps have different complexities. Debugging standalone Java applications is different than debugging J2EE apps, different than debugging Maven or IntelliJ plugins, or debugging projects which use CGLIB, etc because the container environment that is running the code (especially if the container isn’t open source, is obfuscated, and your code calls into the container) can get in the way in various ways. I could take issue and split hairs over an article that said “debugging JSP is just as easy as debugging a standalone java class”, but to what avail?

How about: “GWT debugging is just like debugging any other Java app, and in 97% of cases, just as easy. In the minority of cases where a browser-centric exception is thrown from a hand-rolled JSNI method, you have to drop back to using Firebug.”

I think you’ve made a good point. That’s fairly damning, and reason enough that people should avoid trying GWT.

Comment by Ray Cromwell — June 8, 2007

As someone who has actually _written_ an application in GWT (www.gtraffic.info) I think I can speak from experience. As long as you stay inside the GWT environment the process of developing an application and debugging it (in hosted mode) is just like you were writing it in java. The difference lies in the fact that you have to work within the constraints of the GWT platform and the subset of the core java libraries that are available to you. Not surprising really but I think that Google have made a pretty good job of focusing on the parts that matter. I have moderate experience of javascript and AJAX (the previous version of the site relied on it), not in the same league as say the Dojo developers. I wouldn’t know where to start to write something like gTraffic in Dojo. All I know is that GWT was a pleasant experience for me and there is certainly an audience of java developers and others for which GWT is a perfect fit.

Comment by Alistair — June 8, 2007

Leave a comment

You must be logged in to post a comment.