Now with GWT 2, what are the advantages over wicket and likewise?

Question

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 -

Answer 1

I am newbie to GWT, but after some study I have found GWT is 'suitable' for my new project of web application for its client-focus that make me feel like coding a desktop application. Today we have high-performance client ready to run application at client side. My application can be done solely in Java, and OOP java class give a chance to build our own ready-to-use framework for our team.

Answer 2

There are few other advantages of wicket over GWT that I find.

1. GWT will not work with a browser where javascript has been disabled . (this is rare though). Wicket always falls back to normal http requests if javascript is not available.
2. GWT applications are one page application this makes bookmarking and using browser tabs abit hard. With wicket you choose to create one page application or multiple page applications. You can make the pages bookmarkable if you wish.
3. In GWT, creating your own components is not always easy. In wicket, since you are working with raw html, css and even javascript making custom components is very flexible. You can even wrap an existing jquery or dojo component very easily.
4. Since GWT involves compiling java to javascript, you can only use the java classes that have been emulated by the GWT Compiler. This can be limiting. Wicket is a server side framework and you can use all the java you want.
5. Working with CSS and web designers is much easier with wicket that GWT.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.