Interview and Book Excerpt: Pro Web 2.0 Application Development with GWT
1. It seems that as time goes by, GWT is gaining more momentum in the Java community. Because of that there have been quite a few publications about developing Web Applications with GWT. What differentiates your book from the rest? What do you think are its strong points?
My general critique of programming books is that they spend the first half going over really basic things that are easily learned with a quick tour of the API and documentation and then the second half has some fun, small examples of how to do a specific advanced feature. They're a good read, but then when you sit down to develop your application, you realize that you have no idea how to solve some of the fundamental integration issues surrounding your technology. I prefer to learn by example, so I've always wished that I could just get the source code to a big site. Learning GWT, if I spent X of my time figuring out GWT I spent 3X that much time integrating it with Maven, Spring Security & MVC, Hibernate & SiteMesh and 5X that time figuring out the right architectural patterns. Plain vanilla GWT is easy. It's the integration details that are complex. So that's what this book is. A walking tour through the 15,000 lines of ToCollege.net source code. My hope is that this book should be able to help people get over the hump quicker. Specific to GWT I think that one of the hardest things to figure out is how to break up your application into re-usable components. There's a lot of different ways to do this and a lot of conflicting advice. I think it's worth it's weight in gold to see how one methodology plays out in the context of a full site before you go and implement your own.
2. GWT is one way of developing Web 2.0 Applications with Java. What made you choose it from the other options?
My first startup (MyHippocampus) was my attempt at a generalized knowledge storage device, a bit like Chandler (from Dreaming in Code), but with a lot of ideas about visualization. At first the rich visualization was a Flash application, but that's a long way out of my comfort zone and I hated the clunkiness of connecting a Java server to a Flash app. I'd done a lot of Swing work before, so GWT felt really natural and I loved being able to reuse the same objects on the client and server. I wasn't sure whether GWT was going to be able to handle all of the flash-like UI that I threw at it, but it just ate it up.
3. GWT 1.5 was released recently and your book is based on the 1.5 version. What are the most valuable additions for you in this latest version of GWT?
I think the answer to this keeps changing over time. At first GWT 1.5 was really just a way to start using Java 1.5. Now it's just an amazing release. The compiler optimizations are astounding. It's a GWT mantra that over time your code is going to get faster and faster without changing a line because of improvements to the GWT compiler. See Ray Cromwell's awesome GWT Extreme presentation. http://timepedia.blogspot.com/2008/06/google-io-gwt-extreme-presentation.html to see what kind of impact this can have. ImageBundles aren't entirely new, but they will knock your socks off the first time you use them. 30 images in one HTTP request that caches forever with no heavy lifting on your part? Yes please. They've been cleaned up in 1.5 because of the annotation support and there is some great code in the incubator that allows you to extend this idea to other types of resources.
4. In your book you have a special chapter that explains how to optimize GWT sites for search engines. Making AJAX applications searchable is a requirement that many times is forgotten or not implemented correctly. For a developer building a Web Application with GWT, which do you think are the most important issues he has to pay close attention to, in order to take advantage of the full capabilities of the toolkit and Web 2.0?
Well, SEO is clearly a must have feature for some applications and it's something that's hard to do with a rich app. I think the ToCollege.net solution is a lightweight and unintrusive way to open your RIA up to search engines. The other major concept in the book is my heavy use of the command pattern. It's a recurring theme, because it allows me to use the same architecture to protect against XSRF attacks, integrate with Hibernate, add client side caching, and is a natural way to make your site offline capable using Google Gears. Finally, the book spends a good amount of time on security, since I think this is a pretty overlooked topic as well.
6. One of the features that most developers using GWT praise is that they can stay away from checking all the different browser quirks. Do you find this to be GWT strongest point?
Now that's a question! I have to say that I think there's something to that. It's interesting and a bit ironic, but I think my growing fondness for REST actually encourages the view that the web platform as we know it is holding us back. REST can be a real pleasure to use, but I often feel like it would be much better to operate in a world where the server was just concerned with running the REST services and the client was in charge of everything to do with the UI. The richer the client gets, the uglier it gets to rewrite functionality in both places and the stranger it feels to put application logic on the server. The article on InfoQ about SOFEA and ThinServerArchitecture has really affected my thinking on this. I think GWT fits into this picture perfectly. You get one codebase that works on both client and server, and you can move the MVC stack to the client and off the server, which is great for scalability and user experience. But the original question was whether we need something new. I guess I don't see why. I would say that we may be reaching the end of application logic on the server, but not the browser as user agent. The browser is ubiquitous and GWT let's you shoehorn an amazing amount into it, and if you need more, Google Gears is here to stay. Finally if you need to go beyond that, something like Java WebStart is (finally) a decent option.
9. As the GWT toolkit evolves, what are the new features that you would like to see in future releases?
Hmm, you want my pipedream? I would love to have GWT work on dynamic language source. Yes, I know, you'd lose the superb refactoring support and some of the advantages that GWT brings to large teams, but developing GUI's just scream for dynamic languages. Being able to intermix Groovy for some of the more dynamic elements of a GWT project would be really interesting.
Nenad V. Nikolic
In Java, RESTful web services can be easily developed using JAX-RS (a.k.a. JSR-311 which has reached final 1.0 spec recently). I've used the reference implementation - Jersey, which after some initial analysis, even a couple of months ago, seemed like the cleanest solution that can be easily introduced into any web project.
Web client based on GWT could be made RESTful (implementing all the four most popular HTTP verbs resembling CRUD operations, incl. HEAD and OPTIONS) by subclassing the <code>com.google.gwt.http.client.RequestBuilder</code>. Currently, GWT does not support PUT and DELETE still, blaming Safari for a bug that was resolved more than 2 years ago (could it be that no one cared until now?). Looking around for a quick solution, I've noticed project GWT + Asynchronous REST that seemed to have started down this path but only for servers based on Rails. As you might know, Rails tunnels PUT and DELETE methods inside a POST request which is a REST anti-pattern.
Last but not least, by introducing such a level of separation, the distinction between client and server functionality and code would be made more clear not to mention reusability needed in Web 2.0 apps. The server side could be made thinner and scaled more easily, both from the performance and development effort points of view, while maintaining loose coupling with easily developed rich web clients. As we've all witnessed, web apps tend to increase in complexity more on client side, as evolution from Web 1.0 to Web 2.0 has proven.
I believe this approach might help REST cross the chasm from server-side to client-side web software development. That would lead to greater adoption of GWT as well resembling what Rails has done for Ruby language, ultimately leading to true chasm crossing - into the mainstream development of Web 2.0 applications.
In a nutshell, I would like to see RESTful GWT.