I’ve built web sites using PHP and JSP, with ColdFusion, and now with GWT.

One of the biggest problems I’ve run into with PHP and JSP and ColdFusion is that when you obtain information from a user, you commonly wind up flowing your logic through multiple pages. For example, with a shopping cart and checkout page, you wind up flowing a checkout page via a form (and a JSP or PHP landing page which processes the results) to a second page with a form, which flows (via another JSP or PHP page) to yet another page with a form, and so forth. The business logic winds up being separated across multiple HTML pages. We excuse this dividing up a whole bunch of pages across multiple JSP or PHP landing pages (which process the result of the previous page) by trying to invent all sorts of “MVC” like logic that attempts to justify the fact that we have to serve up four separate screens to do essentially one operation. But we’re still dividing up one operation across four separate screens.

What I like about GWT (and AJAX in general, I suppose–though I’m a Java guy, not a Javascript guy) is that I can now put all of this logic on one page. If I need to make an intermediate transaction to the server to validate some element of the form–so be it; it’s not that big a deal to do quick AJAX request and response.

Some people may claim that this is still not as easy as having an application with everything on one box–after all, if you do have to make an intermediate round-trip, you wind up writing something like “doMyRequestWithResponse(new ResponseInterface() {…});”, with the response coming back some time later. But I find that sort of event-driven programming far easier than the sort of “event-driven” type programming that seems to be offered by earlier frameworks.

Sure, it’s a style thing. But I’m far faster throwing together a bunch of widgets in GWT (and debugging them on the fly in Eclipse–cool!) than I am trying to lay out a bunch of HTML for a flow of forms.

In other words, client-server is far easier than server-driven against a dumb (HTML-driven) display engine.