GWT vs Apache Wicket

Question

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

Answer 1

It is pretty much apples to oranges.

This wiki entry summarizes some of the similarities and differences, and the start of a strategy for using them together, which I think is an interesting idea.

Wicket is primarily a server-side technology with some built-in Ajax support and hooks for wiring in more Ajax. It does not translate Java to JavaScript like GWT. It maintains state server-side where GWT maintains state on the client.

Both are component-based and to me have something of the feeling of Swing development (though Wicket doesn't seem to feel like Swing to at least one other respondent).

Answer 2

Wicket is server framework. It allow to create html which you needed. It is possible separation of roles in project. (Web design->html/css->java).

If you consider to use GWT for you project, web designer probably not needed.
GWT generate javascript. Most logic can be executed on browser side. GWT better for scalable application.

Answer 3

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.

Answer 4

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

Answer 5

It's been 6 years since this thread was active and GWT has mostly stagnated. Wicket seems to be much more actively developed and supported. Anyone have newer opinions about Wicket or other options?

Answer 6

Wicket is server based framework.. It is much more similar to JSf than GWT. GWT is conceptually similar to Swing, I am ex-swing developer, it is very easy to migrate from swing to gwt. But I cant say same things for Wicket or JSF..