Apart from the argument of Wicket's simplicity (that is, Wicket is a simpler system IMHO) and GWT's responsiveness in the client (GWT's client side state and JavaScript - potentially complex client side code) and GWT's greater potential for scaling, what is the argument for using GWT over Wicket?
Personally I've done a lot of Wicket development, but have only had a quick look at GWT a long time ago.
In my opinion the biggest benefit of GWT is allowing you to work with one programming language - Java, with all the goodness that it brings.
Together with CSS, they form a powerful pair.
To put it another way, you can mostly forget Javascript and HTML.
Whether that's an advantage or not mostly depends on your skills and requirements. We've had this same debate internally and in the end one team chose Wicket and another GWT.
I can think of several reasons why GWT is a better choice than Wicket, for typical business web apps:
It's somewhat not fair to compare GWT with wicket (or likewise) since they are really coming from 2 different camps. The former is a framework for building JavaScript front-end applications while the latter is a classic Java web application framework.
So the points below are not as much as GWT vs. wicket but rather general list that was compiled when we decided to use GWT for advanced JavaScript/AJAX web application:
The genius behind GWT is that you work solely with java. They did a great job with RPC making it almost transparent to the programmer. A lot of times you feel you're coding more like a desktop app instead of an application with a truly defined client and server side.
The advantages are, basically, that GWT is a tool to build javascript-based client, thus, it's best suited if you want a javascript-based client.
Wicket centers on the server, and while it makes it quite easy to embed javascript into stateless pages, server-side state handling is the more natural approach.
One must note that the architectures are very different.
With GWT, your architecture turns into client-server, a thick client on the browser, making calls to 'procedures' (services) to the server, sending and receiving data.
With Wicket (and other server-side-centric component frameworks, like JSF and Tapestry), the architecture is a more 'traditional' 3-layer one, and what is sent and received are pages or fragments of the pages, not pure data.
While you can certainly blend both to adapt to the other architecture, it simply wouldn't be very natural.
People tend to focus on 'which is easier to use' (which is completely subjective, depending on your background), or 'which is more beautiful and has more components', but one should not underestimate the architectural difference, which affects the approach you have to take to handle aspects like security and scalability.
I've been involved in a GWT based project for the past few months. I was, having been part of the Wicket development team for years, looking forward to a change, and expected a lot from GWT (which I've always touted as another great Java framework).
Honestly, I am disappointed when it comes to working with GWT. I feel - my whole team in fact - that productivity took a big hit. Theoretically GWT is great. But when you factor in the quirks and limitations of the framework, mediocre error reporting (particularly when it comes to serialization errors), the long compile times (anywhere between 3 - 10 minutes, and our project isn't even that big yet), the fact that when all is said and done, you still need to test for all browsers and find tweaks and workarounds, the fact that it produces a huge initial download (almost an MB, which we're cutting back gradually, but with a lot of effort), etc, etc, I feel Wicket is much easier and quicker to work with.
I don't hate working with GWT. It's still a lot better than most Java frameworks. It's just that I expected a lot more from working with it; I even expected it to be possibly nicer than Wicket. But in the end, it is just not imho. Hopefully GWT 2.0 will improve a lot of things, and hopefully some of the quirks of the Eclipse plugin will be straightened out soon too.
One advantage of Wicket over GWT would be that Wicket can handle the case where you want to provide a fallback for clients who don't have Javascript enabled. GWT is whole-hog for Javascript, Wicket allows you to gracefully degrade.