What are the disadvantages of Apache Wicket? [closed]

Question

I've read a lot about the good things about Apache Wicket, but it's hard to find the bad things. Since no framework is always the right solution for every problem, what are the disadvantages of Wicket and in what type of projects you wouldn't use it?

Maybe not a popular question, but an important one I think.

Answer 1

Wicket demands some pretty solid coding practices. For example, if you store an IModel in your Component, but do not use it as the model of the component, it won't get detached automatically and can blow up your session size. This sort of management is not something most Java users are used to.

Wicket is active and frequently updated. This is good, but each time I update to a new version, I realize that I need to do a lot of refactoring to move to better coding practices (1.4 introduced generics, 1.4.x introduced onConfigure(), 1.5 has some different resource strategies). Again, all are good updates and pushing you toward better code, but I envy people coming to Wicket NOW instead of two years ago :)

Combining both above, I feel Wicket assumes some real programming skill once you get past the basic feature set. If you're a good developer, you will love what Wicket can do for you (and the code is pretty well documented in JavaDoc). If you're a beginner, you might get frustrated as you get deeper.

Also, while it "works" on Google App Engine, I found several issues that prevented it from working comfortably in that environment. That's for a different discussion.

My disclaimer is that I haven't used anything else, so perhaps other frameworks are worse.

Answer 2

In the real world, development speed is very slow with Wicket. If you do not have a pre-canned component to use like a factory worker on an assembly line than productivity grinds to a halt until you can make a new Panel. Code complexity increases and it is hard to read the code because you are effectively doubling the lines of code you have to write. You are constantly looking up how to do trivial things on the internet and in books. For example a simple reset button is one line of HTML but in Wicket it is requires Googling how to do this. It makes simple things hard and hard things impossible.

I have yet to see a really complicated UI built with Wicket. Only simple UIs composed of pre-canned components are possible with Wicket. Every UI I have seen built with Wicket could have had a cleaner code base if it was not done in Wicket and it would scale better by dropping Wicket. Wicket buys you nothing as nice UI widgets as well. Even the jQuery UI implementations of Wicket are inferior to just using jQuery UI directly.

After reading tens of thousands of lines of Wicket code at my work I can say that Wicket code is basically spaghetti code. If you like ulgy, inelegant, verbose, code with generics and anonymous inner classes all over the place than Wicket is your thing. The amount of line noise is very high. The code base becomes less maintainable because of this. This is especially true if you use the flawed Wicket AJAX implementation.