Reasons to choose Wicket over JSF and Spring MVC

The casual reader should know that although Wicket is an unmanaged framework (you create components with the Java new operator) we on the Wicket project like Spring and provide integration for Spring bean injection. There's even a project called Qwicket if you want to get a quick start on a spring+hibernate+wicket application.

I think the most important "feature" of a component-based framework is how many components are available. JSF really excels in this area with a large ecosystem of commercial and open source vendors.

The shortcoimg of JSF is that, out of the box, it does not support "webisms" very well. But, that is why Seam is so compelling.

cheers
Michael
Book on JBoss Seam

Spring Web Flow integrates with Spring MVC to provide many of these "webisms" out-of-the-box including automatic redirect after post, flash scope support, full browser navigation button support (back, forward, refresh, new window). It ships a sample application demonstrating Ajax integration with prototype. SWF also provides a higher-level of abstraction for defining controller components in an externalized definition language--these components then become modules reusable across Servlet, Portlet, and other environments without change.

For more information about what Web Flow can do see:
www.springframework.org/webflow

Perhaps we should call Spring MVC and Web Flow combined "Spring Web". It is worth noting, though, our users do experience value in having flexible components upon which they (and we) can build upon and extend. For example, Spring MVC's dispatcher servlet is re-used by Spring's remoting and web-services support. That's just one example...

In summary a development team evaluating Spring's web app development stack should consider Spring MVC + Web Flow + DWR together, and not simply the Spring MVC base in isolation.

Cheers,

Keith
Lead, Spring Web Flow

It's interesting to me that he says that he has spent the past two years working with Tapestry, yet he doesn't say why he ruled Tapestry out of his list. He presumably has some experience of using Tapestry in the real world on real projects which leads him to think that Spring, JSF and Wicket would all be better choices going forward. I'd be interested to know what those reasons were, since he's coming at this with hands-on experience to back him up.

I like JSF but I hate the mark-up. Facelets is a must-have for me with JSF because then I can use proper tools to design the web page, and non-techies can look at the page source and understand what it is doing.

I've also looked at a lot of the options out there, but I'm leaning more towards stripes. Some of it's principles fly in the face of popular opinion, but its hard to deny how productive it can be. I'm not sure if it would be as maintainable in the longer term tho.

I liked its form handling and navigation support but I did not like all the javascript and extra markup that was inserted into every page without me asking for it.

The tool support for JSF shouldn't be discounted either. Once you're outside JSF there pretty much isn't any.

Likewise for documentation. JSF is well documented. Most other frameworks are not in my experience.

css attributes are done in java code. There is nothing wrong with simple if condition in a template for altering row colors.
Keep the css and view code out of my java.

After dealing with Tapestry on the last two projects I have come to the conclusion component frameworks are overrated.
Whole views/templates/and actions are components in my mind, and tapestry like frameworks have much less re-uses since there is a 1:1 relation between an action and a template.
Thats BS, a action should be return multiple views and template could be reused used with multiple actions as well.
If you want to look at what is wrong with tapestry just look at the roadmap for tapesty 5. They list everything that is broken and restarted about the framework. (terrible spring integration, wonky abstract classes, no interceptors, uses heavy inheritance model over light interfaces, frequent app sever restarts).

Webwork/Struts 2.0 is where it is at.
Stripes is nothing more than webwork lite, with much less flexiblity.

What I like about Wicket (and Echo2 and GWK) is that not only are the pages configured in Java, but so is every individual component and nesting of components. That means I can subclass anything -- pages, panels, widgets -- and I can provide any constructors, overridaeble methods, and defaults for the subclasses as I please. This greatly increases the possibilities for re-use. The advantage over other web frameworks is analogous to the advantages that languages such as C++, Java and Smalltalk have over C, Pascal, and Basic.

Of course, people won't appreciate this difference or benefit from it unless they understand how to design class hierarchies.

"There is nothing wrong with simple if condition in a template for altering row colors."

I think it's a slippery slope. If you add this if condition, you have to add variables for the if statements to work on. Which means model OGNL or something like it in the markup. If you add that, then why can't you do OGNL interpolations? If you add that, then why can't you do OGNL method calls? If you add that, then why can't you do other constructs in the markup? What about a loop construct? It just never ends. And when you're all done you have dynamic behavior embedded in the markup and you never know for sure which file has the if statement in it. In Wicket, you always know that. This has its benefits.

I do understand where you're coming from. I just disagree with your conclusion. By keeping ALL code out of your markup, Wicket is clean and compatible with even the simplest design tools. And that aspect of it will never need to change. The markup in Wicket concerns the look of the view. The Java part in Wicket concerns behavior. If you're dynamically changing a css attribute, that is dynamic behavior in Wicket which means it is predictable in location and form and susceptible to OO techniques and IDE assistance. Behavior is not and should not be markup. Or at least that's the dividing line I came up with when I started Wicket a couple years ago.

In practice I have not found dynamic attributes to be a problem with Wicket. Any CSS or attribute modification I do usually winds up encapsulated in OO code such as a custom component (which you can create by simply using the "extends" keyword... imagine that!) and I never need to look at it again. But if I do need to look at it, I know where it is a priori.

"Whole views/templates/and actions are components in my mind, and tapestry like frameworks have much less re-uses since there is a 1:1 relation between an action and a template."

It could be the OO coder in me talking, but I've read it several times and I still don't understand this statement at all.

"Whole views/templates/and actions are components in my mind, and tapestry like frameworks have much less re-uses since there is a 1:1 relation between an action and a template."

It could be the OO coder in me, but I don't understand this viewpoint.

Whee, so much for the AJAX cancel button on InfoQ. ;-)

Many of the issues that Wicket solves core JSF does not. However there are frameworks like Seam, Shale, etc. that solve these problems (common webisms).

JSF is the core specifications. There are plenty of add-ons that solve these issues. Some of the "add-ons" will get added to the core. Some will not.

Wicket and Tapestry sounds like more complete out-of-the-box solutions for component-oriented web development where with JSF you need to combine it with other frameworks to get a complete solution.

The core JSF is well documented. Shale and Seam are less so. (Shale docs have improved. Seam docs seems pretty good).

With JSF the solutions are there, but it is not one stop shopping.

Is that so? I've seen couple of demos of JSF frameworks that claim to bring Ajax support to JSF but I can't say I liked very much what I saw.

Take webgalileo for example. Looking at the demo (support.jscape.com/webgalileofaces/)
I've got mixed feelings. Well, not exactly mixed. More like negative.

The site took quite long to load. Why? Well, for beginning, there is 200kb of javascript being loaded. Some of the files seem to be compressed, so in the end, browser needs to process 700kb of javascript.

And that's not all. The left tree - it's a completely different file in an iframe - it's 145kb of generated javascript. For a simple tree. In an IFRAME! What's the reason for iframes in component oriented frameworks anaway?

Now the question is, why am I bashing Webgalileo. I took that one just as an example. I have this feeling with other frameworks built on JSF too. A know a huge hack one I see one. A hack to get somehow things working together.

Would you build your application on something like that? I mean, in the end, can the application be any better than the framework it's built on?

I've never uses WebGalileo, but don't think it is indicative of the JSF framework per se.

My point was that there are several solutions to these common webism and it is a shame they are not handled by the core JSF spec. Hopefully, they will be added to the core of JSF.

Wicket has been out for a while. How popular is it? As popular as Tapestry? Spring MVC? JSF?

If not, what are the chances that it will become mainstream.

I took a look at it and did not like the programming model, but then again my mind has been tainted by Tapestry, JSF, Facelets, etc. Perhaps, I'll give it another look one day....

I took a look at it and did not like the programming model, but then again my mind has been tainted by Tapestry, JSF, Facelets, etc. Perhaps, I'll give it another look one day....

It's amazing how many key people just popped up in it.
As a user, I want you all to know I'm investigating all your technologies and should be productive in no time flat in early 2008 ;)

The battle has been fought and won. These guys are just trapped on an island somehwere and didn't get the news....

Battle news: JSF wins so far

I'll keep my eye on Wicket, but it is not too exciting at this point (for me).

Don't you mean Struts won? www.indeed.com/jobtrends?q=jsf+java%2C+struts+java

Classic Struts won a long time ago. This is old news. It is officially dead now.

The next question is... who will succeed classic Struts.

Struts was replaced with WebWork so classic Struts is EOL (end of life). Struts2 is based on WebWork not classic Struts.

Out of the possible replacements for classic Struts, JSF is the leader.

The possible replacements are Struts2 (WebWork), WebWork (or is this EOL now that Struts 2 is out), Spring MVC, Tapestry, Wicket, JSF, Rife, etc.

Out of those, JSF is clearly in the lead.

On a side note: I feel pretty comfortable with Tapestry, Spring MVC, classic Struts and JSF (I've used them in anger).

After using Tapestry, Spring MVC and JSF, I can't go back to classic Struts. Struts 2 looks pretty good. I saw Matt Raible's talk on AppFuse. He said some pretty intriguing things about Struts 2. It piqued my interest.

When I looked at Wicket, nothing piqued my interests. I have not seen a convincing argument for it (yet).

Can you please clarify... Please replace "it" with the framework you are talking about. You bounce back and forth, it is hard to follow your logic.

Just a note....

After reading the posting on InfoQ and this article, I've put Wicket back on my radar as things I want to look into "when I get enough time".

There are so many frameworks and so many good ideas out there it is hard to keep track of them all.

I wrote a series on JSF and Facelets on IBM developerWorks. I've ported thes examples to Tapestry. Perhaps for my own edification I will port them to Wicket (one day).

Now that Rick mentioned RIFE, I can officially jump in without sounding like a zealot ;-)

I've always found these 'job statistic graphs' totally useless. Of course the established standard and enterprise-targeted solution will come out as the one that the most developers are being hired for. Small to medium companies rarely have the budged to start hiring consultants in a such a fashion.

Alternative frameworks often target another (alternative) audience. A lot of RIFE users are part of 'the long tail' of small companies that simply want to get faster results, less setup, more reuse and reduced maintenance efforts. Choosing a suitable alternative framework is one the easiest initial approaches to be able to compete against bigger firms.

It is thus useless to try to 'deduct who won the battle' from any kind of statistic like this. However, I think it's even more useless to see alternative solutions as being in a battle to grasp the most developers. All the choices that have been mentioned here have clear advantages and their goals and purpose are clearly defined. It all just depends on the task at hand, the preferences of the developers, the paradigm they feel comfortable with, etc etc

I think however that it's healthy to post constructive criticisms about why you prefer one solution over the other, like Ryan did in his original mailing list post. This helps other developers to discover differences and problem areas that they are now already aware of before selecting one technology or the other.

People choose one solution over the other because it's practical - a Struts programmer is going to have the most choice, when it comes to new gigs, for example. Even today.

I checked out Rife and thought it was excellent, and found the community very helpful and pleasant, but ultimately ended up settling on more boring tech because it's easier to find devs, most of the questions have already been answered, and it is well integrated in usual environments.

Granted there are sometimes fundamental problems with 'standard' techs where they need to be revamped or usurped, but I don't know how anyone can ignore stats like this (well, maybe for you superstars its easier). There will always be "cooler tech," but in trying to fulfill my client goals and not make myself crazy, I'm most interested in the cool end product. The cool project I'm working with now is still using Struts 1.3.

The abundance of choice is really maddening in the Java world, which does call out for JSF dominating eventually, as a 'standard,' endorsed solution. Just like J2EE. :) j/k. Java seems to have as many stacks as all other languages combined (OK, not including PHP, with ten more arriving each cola fueled evening). What would be nice, to make this work, is finding a cohesive way to combine arbitrary stack components at different points (persistence, component management, view), as required.

Can you please clarify... Please replace "it" with the framework you are talking about. You bounce back and forth, it is hard to follow your logic.

Well, i think this is a bit unfair. None of the "small" frameworks has a big company behind it, unlike JSF. With the marketing power Sun has this is hardly a surprise.

The goal of Wicket never was to rule the world. Believe me, there are people using Wicket (after all, so far we have had almost 100000 downloads from SF). I know a lot of people frustrated from either JSF or Tapestry that are happy Wicket users.

You like JSF. You are happy with it. Good for you. Lot of people are not. I think it is the programming model that makes the difference. And that is hard to explain. You simple have to try using it, and then you'll find out whether you like it and gets more productive with it, or not. This is not something a feature matrix or eye-candy demo will do.

I know people who were using JSF or Tapestry and switched to Wicket. On the other side, I don't know anyone who was using Wicket and switch to JSF or Tapestry (Which of course doesn't mean that such people don't exist :)

Anyway, you might want to look at jroller.com/page/JonathanLocke?entry=wicket_pla... and read the comment from Closet Wicket Lover :)

Now I am more confused....

So it refers to Wicket....

So you say:

"Well, *it*'s full of ugly inner classes, components, the framework clases are full of things that you cannot override (read final) etc. I didn't like that either and still don't in some cases. Still ... something tells me that's all about OOP and not Wicket, isn't it ? :-)*

And then you say:

I love Wicket.

Please clarify.

Geert,

I agree with everything you say to a degree. Rife is cool, inovative and has a good niche. I hope I get to work with it some day. (Most likely I'll continue to work with JSF, Spring and Hibernate.)

The graphs matter to some. I am one of them. It is not the only thing that matters.

Rick Hightower

I agree 100%. It is hard to get non-de facto standards (or standards) at big companies.

And, I think JSF is the next "Struts" for better or worse.

This does not negate the value of Wicket, Tapestry, Rife, etc. This does not mean that Wicket won't have a large following. Certainly, 100,000 is a large number (I am one of the 100,000 who downloaded it).

I believe the first paragraph is half-ironic. Is what most of the people see when they look at Wicket for the first time. Lot of inner classes, final keywords... Some developers, especially developers not very familiar with OOP, can find it weird and foreign, because it's completely different then for example the procedural nature of struts.

But in the end, it's just the plain old object oriented programming :)

The graphs matter to some. I am one of them. It is not the only thing that matters.

Geert,

You have touched on a few issues here. I mostly agree with you, but let me play devil's advocate a bit and highlight where I differ.

RE: If you're talking about job security as a consultant, I can see that.

RE: However, I can also see that being specialized in niche technology gives you much less competition for the same positions.

RE: However, the graphs were shown above to 'prove' that one framework supposedly already has won 'the battle'. I stand by my previous comment that this is a useless metric for that matter as there simply is no 'one battle'.

Before I get too much grief...

When I said this... "The golden thing about JSF is that there are so many niches built on top of JSF (Seam, Shale, Tomahawk, ADF, it is really endless)."

I was mostly kidding... an emoticon would have been nice....

I get a lot of calls to work on/with frameworks people don't use anymore or are trying to get off of. It is good to have a few niche skills if you are a consultant.

What is even better is if you can create your own framework! That is consultant gold. Ain't that right Geert? :o)

Getting a framework out as open-source and making it accessible for other developers is a lot</v> of work and I'm pretty certain that the time invested in that hasn't paid itself back at all yet.