Thursday, September 28, 2006

Wicket for BSCs

Since I am finally getting to do a Wicket project (more then a year after I first learned about it), I subscribed again to the Wicket user mailing list. Initiated by an e-mail from Erik Brakkee, I started a thread to find out how to convince Big Slow Companies (BSC) to use Wicket and finally leave Struts in peaceful history.

There was only one criterion for the items in the list: they must be one-liners that are irrefutable so that there is no place for any FUD.

Together we came to the following points:

- Wicket enables scalable development. It is easy to split the work over many developers, it is even easy to split the work for HTML people and Java people.

- Wicket provides a natural programming paradigm familiar to Java and other OO developers. There is no need to learn new languages, Java and HTML are sufficient.

- The Wicket user e-mail list provides excellent support.

- Wicket has excellent feedback messages in case something goes wrong. Furthermore, Wicket is robust and shows no weird or unexpected behavior.

- Wicket provides excellent clustering support. When required, it is possible to optimize session usage.

Although there was some strong support for including reusability and maintainability I did not do so. I have yet to find BSCs that deeply care about these issues.

Thanks go to Eelco Hillenius for his infinite ability to promote Wicket. Thanks to Che Schneider for coming up with the TLA BSC.


  1. Thanks for the post. I only wish my support was more infinite, as I think Wicket could definitively use more promotion. We had to cancel several talk opportunities at conferences recently, and doing two jobs at the same time and supporting Wicket doesn't leave one with much time :0

  2. Thanks Eric - nice one.
    And kudos to Eelco and all the other guys from and for Wicket: they are doing an excellent job with this beautiful framework.
    That they are also able to keep the mailing list so alive and informative is nothing short of amazing.

    Thanks to all you guys,

  3. Many BSCs (nice touch!) seem to care about userbase. They want to know how easy it is for them to find another company to continue the work in case of problems. Yes, i know, chicken, egg....

    But you could probably add a line about how easy it would be for a struts developer to switch...?

  4. About the ease of switching from struts: we talked about this on the list. The problem is, that Wicket uses a proper OO design. Because of that, many JSP programmers have to unlearn their way of thing. The Tapestry author calls it the 'unlearning effect'.

  5. I was just thinking about it and perhaps there are other ways to convince BSCs to use wicket:
    1. standardize wicket
    2. make wicket compatible with existing standards (e.g. JSF)
    3. take part in standardization efforts for web frameworks and push them in the right direction.

    Perhaps the first point is too ambitious but how about the last two? What are the current developemnts there?

  6. @Erik (that is, the last commenter): thanks for thinking along. However, I do not like these ideas at all.

    1) If you standardize, that means that other teams should be able to implement Wicket as well. But why would you do so when there is already (an open source) Wicket? Another disadvantage is that a standardization committee would change small things, making existing applications incompatible with the 'newer, standardized' Wicket.

    2) I think this is not at all possible. Or, if it is, you will end up the worst of both, without the benefits of either. (But I do not know JSF enough.)

    3) With some exceptions, I do not care about software standards at all. They take time (remember, Wicket is written by volunteers), and just make no sense for most open software.

    Luckily, Wicket has an Apache License. That means you can pick up a copy of the source and just do what you proposed :)

  7. Personally, I would like wicket to proceed independently of the standards and just be the best web framework.

    Nevertheless, BSCs usually care about standards up to a ridiculous extent. The main reason for this is that there is common belief that standards protect investments made in software. For instance, your current JSP/struts application will most likely continu to work in future versions of Java/J2EE.

    Of course, standards are usually a form of design by comittee and for most standards you still need a big fat 3rd party library to get some productivity out of it, facts that are mostly ignored.

    If I were to introduce wicket in a BSC, I would really be much more comfortable doing this if I can do the following easily:
    1. integrate wicket components in JSF/JSP applications
    2. integrate JSP and JSF in wicket pages (this would allow the use of 3rd party components).

  8. @Erik,

    I am glad your personal ideas do not align with BSCs :)

    Struts is a bit weird in this story as it is not a standard, but a (at the time) innovative, single person project. But otherwise I agree with your observations. So there is hope Wicket will someday be at the same level of acceptance as Struts is now.

    Anyway, you can currently include JSPs from Wicket. Some people do this to ease a migration.
    I am not sure there is any symbiosis possible with JSF, either way. But again, I am not knowledgeable on JSF.
    Of course, with an iframe you can make any combination.