GWT vs Apache Wicket

Kasturi picture Kasturi · Jan 4, 2011 · Viewed 10.5k times · Source

Both GWT and Wicket are stateful, java object oriented based. GWT is completely client based with features like javascript optimization, CSS optimization, and I'm pretty new to Apache Wicket.

The more I read about Wicket the more similar it feels to GWT.

So I guess the question is - What are the differences between GWT and Wicket? Or am I comparing apples to oranges?

Answer

Laurent Grégoire picture Laurent Grégoire · Mar 16, 2012

I have been using both GWT (1.x and 2.x) and Wicket (1.4, 1.5) on a large project for several years now, and both frameworks have their advantages and drawbacks. Both of them are cool and nice, if they are used for what they have been designed for. But you can take the best of both by mixing them together easily.

  • Wicket is really nice and powerful for CRUD websites, with a good separation between the page design (HTML) and the Java code. As long as you do not need powerful client capabilities it's doing it's job very nicely, at the prize of being a bit code-verbose: but that's the prize to pay to be strongly typed: there's no "magic"; refactoring and componentization works like a charm. For large projects it can be easily decoupled and is well designed to work with large teams: people can focus on providing a nice set of core components, other on the presentation layer, etc... The only drawback is for complex behavior on client side, you still need to master Javascript and it can easily become rather complex to mix Wicket and Javascript yourself.

  • GWT is nice when you really need rich behavior capabilities on your client (GMail-like application). The main problem with GWT is that it look too nice on paper (the "everything in java" paradigm), but it does not fulfill it's promises. It does not scale well: GWT is nice for small modules providing a small set of functionalities, not for large applications. Code/compile/debug cycle is rather long, and when module size grows too large it becomes a burden. Also it does not support well large teams working concurrently on the same module.

To summarize, I would suggest people having to choose:

  • Use GWT sparingly when it's really needed, keeping module size small, and never try to build a whole big application entirely with it;
  • Use wicket for the rest (Wicket really rocks!).
  • To mix both together, use the powerful component capabilities of Wicket to modularize GWT code in a "wicket way" (GWT modules becoming a special kind of Wicket components), and again, keep GWT small.