Originally posted by Anselm Paulinus: What advantage has wicket got over tapestry or why should one choose wicket over tapestry, judging from the fact that wicket borrowed a lot from tapestry?
Wicket didn't borrow much from Tapestry other than that Jonathan just had read the book before creating Wicket and used some of the same concepts (Page, RequestCycle, Application, etc).
Basically, the big differences between Tapestry and Wicket are that Tapestry provides a declarative programming model, and Wicket's is imperative, and that Wicket's state management is fully automatic while I would call Tapestry's semi-automatic. Wicket has the main focus on ease of use (particularly when it comes to creating custom components) and flexibility, whereas Tapestry seems to focus more on scalability.
What Jonathan wanted to achieve with Wicket that he found was not sufficiently addressed (to his taste) in other frameworks is a programming model that is about just plain simple stateful OO programming. He has an extensive background in UI frameworks (amongst other things, he was part of the Swing team), and he couldn't understand why web frameworks in Java were all about XML, 'actions', avoiding state (state after all is a key component of OO programming), declarative programming etc, instead of the usual concepts (widgets etc) and practices used in UI frameworks.
The best thing you can do if you consider both frameworks is - besides reading the books on them - to try them out for yourself. Creating a simple application (though take care to make your example reflect a somewhat complex/ real life case) with both will show you the difference between the two frameworks. Both are good choices imho, but they definitively have their own sweet spots, and much may depend on the style you prefer.