sorted by: recent | see : popular

Content Tagged with interview + Google

Today we have Bruce Johnson of the GWT team talking to us about GWT 1.5. He discusses the new features, such as the long awaited Java 5 language support, performance improvements, and much more.

It is very nice to take an application, run it through the new GWT 1.5 compiler, and get an instantly faster running application "for free".

Previously on Ajax Pioneer Week...

• Alex Russell of Dojo
• John Resig of jQuery
• Sam Stephenson of Prototype

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

Google has announced some big news for Ajax developers at Google Developer Day. The announcement is Google Gears, an open source runtime to allow you to build Offline Web applications.

Some may think "hmm, what about Dojo Offline?" The great news is that the Dojo crew were in the loop wrt this project, and Brad has ported Dojo Offline to use Google Gears as the base platform.

This is fantastic news, as it means that Dojo and Google are working together, instead of fragmenting. The end result is that the open Web will end up with a much better offline solution.

We interviewed Brad Neuberg, who is working on Dojo Offline thanks to SitePen.

The discussion was a lot of fun, and covered Brad's thoughts on the offline problem, and how Google Gears and Dojo Offline fit together.

I can't wait to see what the community comes up with, especially to solve the tough syncing problems.

Without further ado, listen to the interview.

ps. I apologize for the un-produced feel of this podcast. We got to do the interview at the last minute, and wanted to get the content out there for you in a timely manner.

Frank Sommers has interviewed Scott Blum of Google on the compilation process that GWT goes through to get your Java code to convert to JavaScript.

Scott answers:

• Could you start by giving us an overview of the GWT development process?
• What are the biggest differences in the JavaScript the GWT generates for the various browsers?
• What happens to a Java class when it's compiled into JavaScript?
• What are prototype-based objects?
• What types of Java code are the hardest to translate to JavaScript?
• You mentioned that browser-specific functionality is brought into the compile process from external libraries. Can you explain how that works?
• Once you have those browser-specific versions, how do you deploy them so that each browser gets only the code aimed for it?
• You said earlier that JavaScript is more flexible than Java. In what way do you take advantage of more flexibility in JavaScript to get, say, better performance, or more concise code?
• In addition to excellent Java developer tools, what do you think are the biggest differences for a developer between writing a browser-based application in Java versus writing that app directly in JavaScript?
• What are the GWT compiler's current limitations in translating Java code to JavaScript?

A lot of fantastic detail in there for you. What else would you like to know from Scott?

Over at InfoQ, they have a short interview up with GWT Tech Lead Bruce Johnson. The conversation covers the motivation behind the creation of the GWT, reasons for going with a Java to Javascript compiler rather than pure Java technology in the browser, and the blooming of various third party GWT widget libraries. I thought that his response to the questions of open sourcing GWT was a little disappointing:

We've talked about that possibility from the beginning, so yes. Open-sourcing the tools right now could be more of a distraction than a help. It wouldn't serve GWT users if we took our eye off the ball by starting lots of discussions about the plumbing of GWT when we want to be focusing on making GWT the best it can be for developers. We'll periodically revisit the question as GWT evolves a bit more.

I would think that many more developers would consider using GWT for their client projects if they had adopted a BSD or Apache style license.