IndicThreads >>. Hi Bruce, Welcome to IndicThreads. Could you introduce yourself to our readers?

Bruce Johnson >> I'm an engineering manager at Google. Joel Webber and I started the Google Web Toolkit (GWT) product and founded Google's engineering office in Atlanta, Georgia, where a team of superb engineers develop GWT in close collaboration with the GWT open source community. I've always been passionate about creating development tools in particular because there are so few other areas in computer science that can create so much useful leverage. Plus, compilers are just plain fun.

" Compilers are just plain fun..."

IndicThreads >> . What is the Google Web Toolkit? What was Google's objective behind creating and distributing GWT?

Bruce Johnson >>GWT makes it easy to write AJAX applications for developers who don't speak browser quirks as a second language. Writing JavaScript by hand works acceptably for small projects, but it gets unmanageable quickly for large, team-based projects. You spend 90% of your time working around subtle platform incompatibilities, and because JavaScript lacks modularity, things like sharing, testing, and reusing components can be especially difficult and fragile.
GWT changes the equation by letting you develop and debug your client-side Ajax code using the Java language and the Java tools of your choice. When you’re ready to deploy, GWT can cross-compile your application into a pure JavaScript form that works the identically across most modern Ajax-capable browsers.

" We focus on performance, usability, and internationalization. After all, there are plenty of ways today to create mediocre Ajax applications..."

One of our mottos at Google “Focus on the user and all else will follow”, so it’s worth noting that GWT's overall mission centers just as much on end users as developers. End users deserve reliable, fast applications, and GWT’s job is to help developers deliver that kind of experience. For example, GWT doesn't go overboard on cutesy widgets and gee-whiz visual effects. Instead, We focus on performance, usability, and internationalization. After all, there are plenty of ways today to create mediocre Ajax applications, but there are almost no tools that allow you to create really high-end web applications that also work really well on all modern browsers. It is a complex challenge, and we’ve tried to encapsulate our Ajax experience into GWT.

IndicThreads >> Do developers need to study the GWT APIs if they wish to use GWT? How steep is the learning curve for Java/JEE developers?

Bruce Johnson >>We have been told that The learning curve is mild for developers who have experience with imperative, widget-oriented programming (e.g. Swing). And since GWT centers on the Java language, we have the benefit of being able to use the Javadoc tool to publish API documentation, which makes it easy for developers to figure things out as they go along. Then, if people get stuck, they can always ask for help on the GWT Developer Forum (http://groups.google.com/ group/Google-Web-Toolkit).

" The learning curve is mild for developers..."

IndicThreads >> GWT has a much bigger impact on the overall architecture of the system than any other Ajax frameworks. Could you tell us what's the recommended architecture for a GWT based web application? Should I use JSF/JSP/...? Can I use EJBs easily?

Bruce Johnson >> Even though GWT is a broad toolkit, it actually doesn't require a big impact on your architecture unless you want it to. One of our GWT design mantras is"Only pay for what you use." For example, GWT code doesn't need to control the entire page or anything like that; you can sprinkle a little GWT code onto an existing web application. That was an important use case for us because we would never assume people would be willing to just rewrite their existing web applications from scratch just to use GWT.

" Developers start to see how very convenient it is to have rich client-side state with GWT..."

We have noticed, though, that as d evelopers start to see how very convenient it is to have rich client-side state with GWT, they do tend to gravitate toward converting more of their applications to use GWT and remote procedure calls (RPC). As a result, most of the prominent examples of GWT applications happen to be completely built with GWT, but it doesn’t have to be that way. In terms of back ends, EJBs and so on, it is important to note that GWT is actually a client-side technology, and it plays exactly the same role that handwritten JavaScript does. The only exception is GWT’s optional RPC mechanism. RPC is specifically designed to work with Java on the server, but it plugs into a variety of back end architectures, including servlet containers.

" GWT is actually a client-side technology..."

IndicThreads >> How difficult is it to enhance existing Struts or Spring applications with GWT capabilities? How does one go about the task?

Bruce Johnson >> As I mentioned above, GWT is fundamentally a client-side technology. You can attach a GWT module to any HTML page you like, whether it was rendered via Struts, Spring, or whatever. The intersection between GWT and the back end happens due to GWT RPC, which does integrate directly with various containers. The best place to get started is the GWT Developer Forum – just do a search for “spring”, “struts”, or “hibernate”.
" The best place to get started is the GWT Developer Forum – just do a search for “spring”, “struts”, or “hibernate...”

Page 1 of 2