I still haven't had much time to look at Wicket, which just announced a 1.0 release. I did see that their examples include a Hangman application (the new industry standard, I guess).
I think many of their goals are quite laudable; less XML is a good thing (you may notice I'm on an annotation streak right now).
I do have some questions about lifecycle; I need to dig into the docs or code to see how they maintain page state across requests; I'm concerned that each session will get a giant serialized tree of components, something that Tapestry's structure works exceptionally hard to avoid ... even though seperating a page's persistent state from the tree is what lead down the abstract accessor method path in the first place.
I was amused by the live examples; the URLs that were generated look like Tapestry 0.0.1 URLs (I could even see the loop index terms in the middle of the URLs). Tapestry has taken some flack for ugly URLs, which are much improved in Tapestry 4.0 (in fact, limited by the Servlet API more than anything else).
Wicket seems to have a page-state version number encoded into the URL to detect browser back button issues (Tapestry, of late, has been moving towards storing more data in the client to circumvent problems caused by mismatched client- and server-side state).
Mostly, I'm envious of the chance to start with a clean slate. The demand for backwards compatibility is surely holding me back from fixing a good number of things. And if I was starting again today, I would not require subclassing from base classes (as Tapestry and Wicket both require). It really would be POJOs, plug optional interfaces and naming conventions (and maybe annotations) ... and no XML at all.
At the end of the day, it's great to see folks "gunning" for Tapestry, it's a kind of validation. I'm looking forward to meeting the Wicket crew at JavaOne.
Further discussion on The ServerSide.