BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Interview and Book Excerpt: Pro Web 2.0 Application Development with GWT

Interview and Book Excerpt: Pro Web 2.0 Application Development with GWT

Bookmarks
InfoQ is proud to present an excerpt from the book Pro Web 2.0 Application Development with GWT as well as an interview with author Jeff Dwyer.

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.

5. There has been some criticism against GWT and its function as a code generator, with the argument that if you program one language (JavaScript) in another (Java), you lose all the benefits of the target language. What do you think about that?

That's a great question. To be honest, when I first started looking into how to build a rich Web 2.0 app, I wasn't that knowledgeable about JavaScript. It really scared me to think that I was going to have to write oodles of browser specific code to get around IE6 bugs. Recently I've been doing a lot more JavaScript work for my new job at PatientsLikeMe, and I have to say that the JavaScript state of the union is much better than I'd imagined. With time and an open mind, you can right some really clean, unobtrusive, JavaScript. You have take the time to explore the best practices out there though. It's a fun language, but if you just try to write Java in JavaScript you're going to hate it. For good developers JavaScript can be a great thing... up to a point.

The reason GWT was created is that Google found that JavaScript didn't scale to large projects. They've got the best and brightest developers following best practices, but when the app gets big, they found that really solid tooling support starts to trump clean idiomatic JavaScript. I think it's good to keep this in mind when you're thinking about adopting GWT. This wasn't created to be an EZ-AJAX for beginner developers and it's not a tool to help people who can't be bothered to learn JavaScript. It was created because the talented programmers at Google found they were going crazy and tearing their hair out trying to develop larger rich internet applications.

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?

Not really. As I said before, when I came to GWT this was a big selling point, but to be honest I think I'd overestimated the problem. Yes, GWT is a joy to use in this regard, but the JavaScript solutions aren't that bad. There's a lot of prior examples out there and a lot of very solid frameworks. Yes, you sometimes need to think about putting silly shim elements behind popups so form elements don't bleed through, and yes there are some gotchas, but in general the real difficulty with cross browser development is CSS, not JavaScript. Prototype/JQuery/etc are great libraries. So yes, GWT is great in this regards, but I don't want people to run to GWT just to do very basic stuff that's a couple lines of Script.aculo.us. If you're just sexing up a simple site, GWT is quite probably overkill.

7. Do you often have to debug your application in the various browsers, after you have generated your JavaScript files with GWT? How easy do you think it is?

I haven't needed to debug the generated JavaScript on a browser by browser basis since 1.3, and even then it was very solid and my fault 95% of the time. GWT just works. Actually it's even better than that. GWT also saves you from a lot of funny memory problems that even accomplished JavaScript developers miss. GWT saves you from these sorts of gotchas without you even knowing about it.

CSS is another thing entirely though, and for that I do end up compiling. My basic workflow is to first make it work in hosted mode so that the functionality is there and I'm just waiting a couple seconds to refresh between code changes. Next I compile and look at it in Firefox so that I can use Firebug to help me get the CSS right. With that done I'll move the CSS back into the project and see what needs to be done to get IE looking right as well. But no, I haven't needed to output the generated JavaScript in pretty mode in a long long time.

8. Many believe that the creation of code generators like GWT or even elaborate JavaScript frameworks is a sign that the traditional "Web Platform" has reached its maximum potential and should be replace by something more modern. What do you think about that?

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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • RESTful GWT

    by Nenad V. Nikolic,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for a nice review of the book. There are some interesting points made regarding the state of the art of Web 2.0 application development and available approaches.



    I wonder what Mr. Dwyer and everyone else thinks about Web 2.0 application architecture based on RESTful web services for provisioning functional entry points for web clients based on GWT as well. As (an intended) side-effect, which is really one of my intentions here, any web application based on such an architecture would have an open API for any other (non-GWT) client to peruse. Furthermore, if needed, it would be possible to build a security model around such API so that functionality with restricted access would be accessible by GWT clients. Clearly, GWT can be leveraged for implementing/generating the necessary authentication and authorization JavaScript code, which is usually based on specially formatted XHR requests that end up being authorized against protected API methods (i.e. RESTful web services methods) the same way API requests get authorized.



    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.



    Cheers!

    Nenad

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT