Wicket and Tapestry compared

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.

20 thoughts on “Wicket and Tapestry compared

  1. Matt Welch says:

    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.

  2. 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.

  3. Sam Stainsby says:

    “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.

  4. 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. :-)

  5. racer of SEO says:

    Tapestry 5 may not be “final” but it’s been production usable for quite some time.

  6. And so were those beta versions of Wicket 1.3. But the authors of the comparison decided to go only for final versions.

  7. Leon Khamai says:

    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).

  8. 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.

  9. 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!

  10. Chris Colman says:

    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.

  11. Alfonso says:

    Hi! I’ve used Tapestry 5 for a small app (content managment) and it worked quite well for me. I wanted to test wicket, and I first saw ugly urls, my God!! and when you want a page to be bookmarkeable, it gets worst. I know you can create url-rules-rewrite, but why?? T5 creates friendly urls by default.. no need to create special rules. Another question, what IoC container wicket uses? T5 has t5-ioc, increadibly easy, which is able to wrap spring if neccesary. Thanks!

    • “Ugly URLs” because stateful pages are session relative. And yes, there are easy ways to customize this, including from Wicket. T5 creates friendly URLs by default, but at the cost of things that Wicket provides and T5 doesn’t (like a dynamic component model, stateful pojo programming model, security by default, etc).

      Wicket doesn’t use an IoC container, but rather uses plain OO. Users can easily use Spring or Guice or whatever, typically with just a single line of configuration.

      • Alfonso says:

        Eelco, thanks for the fast reply. As you mention, in wicket there are ways to CHANGE the DEFAULT urls. I saw demos and in a very BASIC application, the url was:

        Not serious for me.
        I’m sorry but nowaday (2010) I can’t choose a web-framework that made no effort in this important point. The t5 static component model works perfect for me and for a lot of people, and if you need dynamic component model, there are ways. What is the wicket security by default? In T5, at least for me, it was really easy to implement security in web-tier. If you need HTTPS in some page, is as easy as writing @Secure to that page. What is the “etc” you mention?

      • The effort is there; you just need to map Page2 to a url you like. One line of code. But without it it always works, no extra configuration needed. There’s a lot that can be improved as the world keeps changing (Wicket is 5 years old by now after all), but I think most people like the fact that Wicket easily runs out of the box.

        > The t5 static component model works perfect for me and for a lot of people, and if you need dynamic component model, there are ways.

        If it works for you, it works for you. You may have no compelling reason to pick Wicket over Tapestry then. You can however do very nice things with a dynamic component model that ultimately you might be able to pull of with Tapestry, but with a lot of effort. For instance I have worked on several projects where we could ship functional components including their user interface. I’ve worked with plenty of other frameworks, including with GWT recently, but none of the frameworks I know make stuff like that as easy.

      • Alfonso says:

        A wicket page must extend WebApp class or similar, is that a POJO for you? T5 pages & components don’t need to extend anything.

        Tapestry & wicket use similar approach (components) that I like a lot (much better than struts way) but it’s good to write reals pro/cons of each one. Thanks and sorry for my english!

      • Yes, POJO == Plain Old Java Object, inheritance is part of that. There are actually good cases to make for inheritance, and this is a decent one. The base classes guarantee behavior and expose limited functionality only available for overriding components, and it does this without any magic (such as byte code engineering), which makes it a lot easier to debug than say Tapestry.

        Anyway, as for pros/ cons, well the best thing you can do is give both frameworks a spin (check out GWT for good measure as well), and decide what you like better/ works best for you. If it turns out to be Tapestry, all the power to you and the abundant choice available in the form of OSS Java frameworks. :-)

      • Alfonso says:

        Mmh, wordpress working wrong? I answered you today (11/02) and my post appears before yours (10/02) , no sense :S

      • Chris Colman says:

        No, a POJO is not a user interface class. They are typically ‘model’ classes in the MVC view of the world. The real world objects that are modeled in your app (eg., Person, Account, Company, Address etc.,) are the POJOs.

  12. Alfonso says:

    Thanks again. The POJO definition I think depends the source where you read it. Wikipedia tell us: “…object which does not follow any of the major Java object models, conventions, or frameworks..”, in this case, “extends WebApp” is a wicket class, a framework class. Anyway, no matter de definition, I prefer my objects (I mean, no ‘extends’).
    I think, while T5 & wicket share the component-base-paradigm, it would be GREAT to create a blog of experts of both sides, (last version of T5 and last of Wicket) comparing everything, to give all of us conlusions like “if you need dynamic component model, go wicket” etc. Other thing I love from T5 is zero-class reloading, in components & pages you work as php, live results.


    • You can use JavaRebel to achieve the full class reloading (partial reloading is already supported by the JVM), and changes templates are already picked up in development mode.

Comments are closed.


Get every new post delivered to your Inbox.

%d bloggers like this: