Here is an excellent comparison between Tapestry and Wicket. One of the best parts: “Despite the fact that there is a similarity between frameworks’ architectures (both are component-oriented with clear separation of concerns), their implementation is quite different”. And what a breath of fresh air to not have to read about number of job listings, books and other quasi-managerial comparison pollution.
No more explanations needed on the Wicket user list and forums like The Server Side; we can just point to this article from now on :-)
One big difference between the two frameworks that isn’t mentioned in the article is the fact that Tapestry’s component tree is static, whereas Wicket’s is dynamic. The advantage of a static tree is that it is easier to handle and optimize. I guess this is true for having a declarative programming in model. The advantage of a dynamic tree is – obviously – flexibility. For examples of what you can do with a dynamic tree, check out this post and this rant. Also, components like wizards and tab panels make heavy use of this in Wicket, and while I’m sure there are workarounds available in Tapestry, the ability to arbitrarily replace components makes it very easy to implement things like detail screens and such.
Thanks Artem, Jim and Ilya for taking the time of publishing a thorough comparison.
I’ve been happily using Wicket on my past two projects so I certainly wouldn’t consider myself a Tapestry fanboy, however I don’t think this article does Tapestry justice, especially considering the fact that’s it’s based on Tapestry 4.1. Tapestry 5 may not be “final” but it’s been production usable for quite some time. This article goes into the actual steps needed to create pages and components, however those steps are hugely different (and much, much easier) with Tapestry 5.
It’s quite valid to point out that someone moving from Tap4 to Tap5 will need relearn a large number of things, however I do not this that this article is very useful for a developer who is not familiar with either framework and is considering which to choose for his next project. I can’t imagine anyone starting a new project from scratch and using Tapestry 4.1.
Well, Tapestry 5 still calls it’s releases ‘beta’. We had the same thing with Wicket when people used version 1.2 instead of the much improved 1.3 in their comparisons. I think the Matt Raible’s famous comparison still uses 1.2.
Also, if the rewrite of Tapestry 5 is that different as people say, I wonder whether it still should be called Tapestry to begin with :-)
But I agree with you that things probably would look better for Tapestry had version 5 been used.
“Tapestry 5 may not be “final” but” …
Let’s compare final version to final versions. Wicket too is evolving and 1.4 is in the works. If there’s a comparison of Tapestry 5 to Wicket 1.4 in existence then fair enough, lead on …
From the article: “V5.0 is under active development, and at the time of this writing, some 18 months had passed since the team had started rewriting Tapestry from scratch.”
Looking quickly at the tapestry 5 tutorial, it appears it may be similar in concept to wicket, but there again wicket has a number of final releases under its belt, and so seems quite far ahead. It seems Tapestry 5 relies a lot on annotations – just an observation – I know some people don’t like them; I haven’t formed an opinion yet.
I think those annotations make sense for Tapestry. Tapestry’s programming model is declarative and relies heavily on meta data. It’s not the kind of meta data (like for component definitions) you’ll want to swap often, so I think the fact that you can now declare that where it matters (in the pages) is an improvement over declaring it in separate XML files like you had to do with previous versions.
At least, that’s my hunch… I’m not a Tapestry user, and my knowledge is limited to a quick read. :-)
Tapestry 5 may not be “final” but it’s been production usable for quite some time.
And so were those beta versions of Wicket 1.3. But the authors of the comparison decided to go only for final versions.
I’ve found this article very good and very useful; it is well written and therefore readable. It provides readers with both a comparison as well as a tutorial for these two frameworks.
As shown and said, Tapestry seems to be more heavily and more explicitly relying on separated component definitions whereas Wicket does not.
I believe both approaches are very valid; I suppose, using one or the other will depend on your needs and your affinity or aversion with declarative approaches & XML.
In a context where a meta-tool would offer the ability to automatically produce web components, therefore a context requiring more control, maybe Tapestry is better choice.
On the other hand, Wicket seems really well suited in a context requiring more agility (prototyping would be one example).
I believe Wicket is also the better choice where you need to build up your UI dynamically. The project I work on for instance, has functional components that contribute panels for inclusion in the pages. That’s easy to achieve with Wicket, whereas – as far as I can judge without having extensively worked with Tapestry – that would require you to implement workarounds with Tapestry. It was actually the big reason why Igor, once a Tapestry user and now one of Wicket’s most active committers, made the switch.
In a context where a meta-tool would offer the ability to automatically produce web components, therefore a context requiring more control, maybe Tapestry is better choice.
On the other hand, Wicket seems really well suited in a context requiring more agility (prototyping would be one example).
Thanks for the blog!
We use wicket for a massive enterprise level application. It would simply not work in a Tapesty environment with Tapestry’s static component trees and would be most awkward if it had to deal with meta data driven composition.