Apache Wicket vs Apache Click

Question

What is the difference between Apache Wicket and Apache Click? Is Apache Click maintained? The latest release seems to be from Nov 2008 Thanks Achilleas

Madelon

Answer 1

Click is actively developed and has recently graduated as an Apache Top Level Project. It is currently moving to its new domain at: http://click.apache.org. Once the migration is complete the next version, 2.1.0, will be released.

Before comparing Click and Wicket do note that I am a committer at Apache Click but have evaluated Wicket a couple of years ago so have a fairly good idea of how it works.

Click is a stateless framework while Wicket is stateful. In Click, pages and components are recreated each request, in Wicket the pages and components are stored in the session and reused in subsequent requests.

Wicket is meant for building complex applications (think desktop), where all the GUI state is stored and managed for you. Click is meant for the more traditional web applications where little to no state is necessary to render a page. If you need to store state you have to manage it yourself by adding/removing it from the session. Its worth mentioning that Wicket provides support for stateless pages and Click supports stateful pages, however this isn't the norm for these frameworks.

Another difference is that in Click controls knows how to render themselves, so you don't have to repeat the markup in your page templates. You can still manually layout your templates if you want, but it is not strictly necessary. In Wicket the markup needs to reflect the components created in the page. The idea in Wicket is that the Java developer doesn't actually create or maintain the templates, instead this is handled by a designer.

kind regards

Bob

Pasho

+1: Nice balanced answer. They both have strengths, and you nicely captured that. – Trygve

Wicket is not necessarily stateful. By default your wicket web applications is stateless and wicket only switches into stateful mode when it needs to. As long as you carefully use only stateless components on your web pages (for example org.apache.wicket.markup.html.form.StatelessForm), your application will remain stateless. You can also add a StatelessChecker to your application to enforce statelessnes. The checker will throw an exception about the offending stateful component, see my other post how to set it up if you have to. – Gelderland

Answer 2

With wicket you use pure html and no template language as velocity or jsp like click does. This is not only handy for the programmer itself which only has to learn html and java, but also for the tooling (debugging etc)

It enforces a better separation of user interface and logic. There is also no xml required in wicket which is IMHO different to click.

Some more differences: wicket's mailing list traffic is higher; there are more publications (e.g. books) on wicket then on click; there are more developers coding wicket (look this and this)

Idio

Yeah, and Wicket built with ~850.000 lines of code, while Click contains only ~50.000 lines of codes. That should say something about the complexity also. Regarding this information Click is MUCH MUCH more simple. – Trovillion

Answer 3

Wicket offers more flexibility on how you compose your pages. You can create a single page composed of components for the entire application , or you can create multiple pages as you wish. Click is page based. Wicket has support for ajax out of the box. Most of the the ajax components in wicket fall back to normal page refresh in case the browser doesnt support ajax. Wicket has dozens of components out of the box and dozens of others from related projects. One great feature I find in wicket is its verbosity.. That means the everything my application does is what I created. I write the entire presentation with html and css with nothing being generated. Lack of magic is a big plus for me from experience. Last and least, many large corporations are using wicket. Walmat mobile and wellsfargo mobile are done with wicket.

Cupola

"That means the everything my application does is what I created." No, it means everything you do in the html you must do in a wicket page. Nothing is more frustrating then having trouble finding the html element that is associated with a given component or vice versa. keep code and markup in sync is a maintenance nightmares. – Frilling

Answer 4

the biggest drawback to wicket is its statefull nature. It can be difficult to unit test and debug state issues. its statefull nature means it uses more memory, and could effect your hardware budget. a side effect of the stateful nature of wicket means that it needs to be able to save that state from time to time. to do that, all your objects need to be serializable.

i've just started looking at click. i love its stateless nature. the web is request/reply, which should be stateless ( at least as much as possible).

i also like how nicely click integrates with apache cayanne.

Disrupt

A stateful nature is no longer a drawback if you need state. – Trygve

i don't think that's always true. a good developer on a small webapp probably wont have many issues trying to maintain a complex state in a small webapp. If I had a large project (10+ developers) to build, I would definitely gravitate toward a stateless solution. It's just so much easier to build, test, debug, and maintain. – Disrupt

With care you can use wicket to build stateless web applications. I've written a stateless webshop with wicket. See my other posts how to enforce statelessness. – Gelderland

Wicket simply sucks when you want to use it in a stateless fashion. It is really hard to debug, and really hard to maintain wicket applications. In some cases the development time could be much less with Wicket, but if you got a bug... there is the end. I would go for Click instead. If you want to handle states, than you can use a simple session scoped spring bean for that. That's it. – Trovillion