David R. Heffelfinger

  Ensode Technology, LLC

 
Bookmark and Share

A Slightly Biased Comparison Between Wicket and JSF


Recently I will start working on a project using Wicket. I used Wicket briefly in the past, I wrote an article about it and even worked as a technical reviewer for a book on Wicket, but I have never used it in production systems.

On the other hand, I have written two books that cover JSF, I also teach a class that covers JSF development, and I have worked on some projects that use JSF in production. As the author of two books that cover JSF, I have a vested interest in having JSF remain popular, therefore I am obviously somewhat biased, however I'll try to be as objective as possible when making this comparison.

All of my Wicket experience happened a few years ago, I haven't used it much in about three years, so for the past few days I've been refamiliarizing myself with this framework.

When comparing Wicket with plain vanilla JSF wicket is the clear winner. The fact that the markup in Wicket is plain HTML (with special wicket specific attributes) makes Wicket much more accessible, since no special knowledge of Wicket components is needed to come up with the markup. This allows web designers to do what they do best, design their user interfaces with their preferred tools such as Dreamweaver or other web design tools. The changes to the markup to make it work with Wicket are minimal, the wicket specific attributes need to be added to HTML tags that will be replaced at runtime with Wicket components. However, very few people use "vanilla" JSF. Most JSF developers use a component library such as ICEFaces or RichFaces. Furthermore, Facelets is a very popular view technology that can also use standard XHTML to develop JSF views. When component libraries and Facelets enter the picture, picking a winner is not so easy.

The fact that Wicket uses standard HTML for its markup may be an advantage or a disadvantage depending on your situation. If you are working with a professional web designer, then having straight HTML as markup is a real advantage. However, if your team consists primary of Java developers with little or no web design skills, then using a JSF component library that renders its pages using predefined CSS and Javascript, then in this case JSF may have the advantage.

Wicket reminds me a lot of working with Facelets, when using Facelets, we can develop pages that are plain XHTML, however we are not prohibited from using JSF specific tags. When previewing a Facelets page in the browser, the JSF specific tags are simply ignored.

Wicket also has some Wicket specific tags, however they are used to ignore parts of the HTML when it is rendered in the browser and other functionality, they are not really meant to be rendered. On the other hand, HTML tags in Wicket can have an wicket id corresponding to a component that renders HTML on the page, for example, a <span> tag could map to a custom Wicket component, therefore, a Wicket page may not preview exactly like it will be rendered when the application is deployed, which is the case with Facelets as well.

My impression on which one is better is, like in most cases, it depends. If a professional web designer is available, then Wicket may be the better choice, however if most of the development team are backend Java developers, then using JSF with Facelets plus a component library such as IceFaces or RichFaces may be a better choice.

 
 
 
 
Comments:

any developement team should have real designers. One thing a real java developer shouldnt do is design the ui. Because that really wont sell the product.

i think i can count on 1 hand a few fingers the persons that can do both well. Develop java code and design ui's. Its just a different kind of people.

So saying that most development is backed by java developers is or should be just really flawed. Any company that doesnt hire a designers is in my eyes doomed.

Posted by Johan Compagner on June 07, 2009 at 02:47 PM EDT #

I think that Wicket is way better than JSF, in general, if we add JSF libraries and Wicket contributed libraries.

Advantages of Wicket.
- Templating with Wicket is fairly easy compared to JSF.
- The name of the components feels more natural in Wicket especially if you have a Java Swing background
- Upgrading usually from Wicket versions is less painful. Classes incompatibilities and changes.
- Wicket is more accessible to the junior Java Developer and require less configuration than JSF.

I also believe that most web applications needs a designer.

The strong points about JSF :
- JSF has a better IDE support than Wicket.
- JSF is a standard
- JSF has more documentation and books
- There's more demand for JSF than Wicket on the job market.

Posted by John Doe on June 08, 2009 at 07:22 AM EDT #

Although you don't really dig very deep into actual development issues, most people with experience with both stacks tends to favor Wicket for its ability to remain type-safe without a ton of custom XML and EL-expressions.

Posted by Casper on June 08, 2009 at 07:50 AM EDT #

Nice review. Brief and to the point. Your point of the "Web designer" vs. "backend Java developers" is valid for typical development efforts. Keep it real and Keep it simple. : )

Posted by anon on June 08, 2009 at 09:13 AM EDT #

Post a Comment:
Comments are closed for this entry.
 

« April 2018
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
     
       
Today

 
© David R. Heffelfinger