What are the disadvantages of Apache Wicket?

Several answer declare wicket to be unable to dynamically create a component tree. Seriously, I thing you guys are working with a different wicket there ;)

First of all: Wicket is component based, not a random HTML generator.

It's actually pretty darn easy to get a dynamic component tree:

Want to replace a component with another one? Use Component.replaceWith(Component) (Pretty useful in conjunction with an empty MarkupContainer)

Need a dynamically changing list of panels? Put them in a repeater.

Make a component disapear? Use Componente.setVisible()

And a ton more of ways of doing this.

So, those who think you can't do dynamic component trees, please provide some examples and I am happy to discuss on those.

(If you really need to be even more flexible you can make Wicket load markup from different sources. Something I NEVER did for sake of building dynamic trees but to be able to retrieve Markup from a database or via network)

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.

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.