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…
Source: Ajaxian
Original Article: http://ajaxian.com/archives/gwt-a-year-later-was-it-the-correct-level-of-abstraction