Google Web Toolkit isn’t just another way to create mediocre Ajax applications
Bruce Johnson, Project Lead of The Google Web Toolkit (GWT) talks to IndicThreads about the GWT framework, it’s capabilities, the team mission and more. He talks about how GWT helps developers build high-end Ajax applications using Java and without worrying about the cross-browser quirks.
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…”
IndicThreads >> Which tools do you think simplify GWT development? Are you planning to provide built-in support for IDEs other than Eclipse?
Bruce Johnson>> We designed GWT so that it would naturally work with any Java IDE. Even though it seems to be magically” integrated in to the IDE, GWT is actually totally independent of the IDE you’re using. I’ve seen tutorials on how to make GWT work with every Java IDE that I’ve ever heard of. There are several nice Eclipse plug-ins, including one from Instantiations that provides WYSIWYG form development. IntelliJ IDEA also has a really nice GWT plug-in. I have also heard great things about the NetBeans GWT plug-in.
” We designed GWT so that it would naturally work with any Java IDE…”
IndicThreads >> GWT does not have the fancy widgets that some other toolkits/ javascript libraries have, so would you advise architects to use GWT for the asynchronous communication but use other Ajax libraries for effects?
Bruce Johnson >> It seems like the GWT widget story is shaping up well over the last six months. These days you can find most any widget you want either in the core GWT distribution or in third party open source libraries. In terms of architecture, I’d suggest designing a solid, fast, highly-usable application first, and worry about style and effects secondarily. Those latter things are important, but you can typically adjust CSS styles and add effects later as icing on the cake. There are several existing effects libraries for GWT, both native Java ones as well as GWT/Scriptaculous bindings.
“ There are
several existing effects libraries for GWT, both native Java ones as well as
GWT/Scriptaculous bindings…“
IndicThreads >> Can GWT be integrated easily with popular javascript libraries like Dojo and Scriptaculous?
Early in the design of GWT, we knew that people would need to integrate existing JavaScript libraries with GWT code. That’s why we created the JavaScript Native Interface (JSNI). JSNI lets you implement Java native
methods using handwritten JavaScript. That means that you can combine JavaScript source and Java source at will, making it straightforward to create Java classes that delegate to JavaScript libraries. We used JSNI to create the GWT bindings for Google Maps, Google Gears, and so on. Regarding Dojo and Scriptaculous, I’ve seen libraries that already do integrate them with GWT, as well as integration of several other popular UI libraries, including YUI and JsExt.
” Early in the design of GWT, we knew that people would need to integrate
existing JavaScript libraries with GWT code…”
IndicThreads >> With GWT, are we moving further away from thinking of web applications in terms of pages to thinking of the application as a whole? Do you think traditional MVC web frameworks that revolve around pages would become irrelevant?
Bruce Johnson >> There will certainly be a mixture of server-side and client-side control for the foreseeable future. But GWT does make it easier to write much larger chunks of client code, so I expect that many applications will indeed move a lot of the MVC–type logic to the client. Doing more on the client is particularly important in high-stakes applications that can really benefit from the increased responsiveness of a smarter client. You can see by reading the GWT Developer Forum that As developers become more proficient with GWT, they start to see less and less need for having complex server-side logic and state The ideal application architecture from a scalability standpoint is a smart client and stateless server. This arrangement works very well with load balancing, because any request can be routed to any free server, which in turns makes failover nearly automatic.
” As developers become
more proficient with GWT, they start to see less and less need for having
complex server-side logic and state…”
IndicThreads >> The 1.4 Release Candidate of GWT has some interesting features like ImageBundle. Can you elaborate on the new features in 1.4 and any other exciting new features lined up for release?
Bruce Johnson >>
GWT 1.4 was a huge release with features that span a wide variety of areas. It included a ton of bug fixes as well. In terms of widgets, it includes splitters, rich text, suggest box, and several more. There are some major compiler optimizations that improve both the size and speed of the compiled JavaScript. There is also other library functionality, including formatting and parsing of date/ time value and numbers, and the very popular ImageBundle. The GWT 1.4 blog post tells the full story (http://googlewebtoolkit.blogspot.com/2007/08/gwt-14-release-and-out-of-beta.html).
” We’re really proud of ImageBundle because
it clearly demonstrates the kinds of effective win/wins you can get with GWT…”
Regarding ImageBundle specifically, it is a code generation library that automatically combines multiple small images into a single cacheable image using the “CSS sprites” technique.We’re really proud of ImageBundle because it clearly demonstrates the kinds of effective win/wins you can get with GWT, making both code easier to write and more performant simultaneously.
IndicThreads >> What’s the overall direction that GWT is taking?
Bruce Johnson>> We will continue to look for ways to make GWT easier to use and great for interoperating with other client-side technologies while continuing to produce better, faster output. The team is extremely passionate about this mission because we realize that by enabling developers, we are indirectly helping millions of end users, which is very gratifying.
” We are indirectly helping
millions of end users…”
IndicThreads >> Thanks for talking to IndicThreads Bruce. Wish you the very best.
Bruce Johnson >> It is my pleasure. I look forward to discussing GWT more with you as it continues to evolve.
Related
I like to use google web tools.