Having developed several web applications with JSF, and recently with Apache Wicket, I want to share my experience. On the web, Wicket has mostly positive buzz, but JSF seems to be hated by many (See http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/). I beg to differ.
Before I start, it should be noted that many of the frustrations and limitations of JSF discussed around the web have been have been addressed in version 2.0. And one more thing, the comparison aspects below are in no particular order.
Templating
Wicket claims to separate HTML markup and Java code without introducing special markup tags. This is, however, only partially true, as we can see in the code listing below:
JSF 2.0 uses facelets as the standard view declaration language, and an equivalent template is illustrated below:
As far as templating goes, they are very similar.
Ajax
JSF 2.0 introduced native support for ajax through f:ajax tag. In earlier versions, ajax was enabled through additional libraries such as Richfaces a4j:ajax. Use of ajax in JSF is straightforward:
In wicket, this is achieved using the AjaxFormComponentUpdatingBehaviour class. The result is cleaner HTML, but messier Java code with an inner class. Personally, I don't like having many inner classes because I find it difficult to read. A page with plenty of Ajax functionality will have many inner classes, and consequently difficult to maintain.
In my opinion, declarative approach of JSF is less verbose.
Components
Out of the box, both Wicket and JSF offer a similar set of standard components. However, JSF has a larger choice of additional high quality component libraries such as Primefaces, Richfaces and Apache MyFaces.
As with Ajax, the biggest difference in use of components is JSF's declarative approach against Wicket's programmatic. Let's take a look at an example of creating a simple table of a book collection:
Given that Book is a Java Bean with getters and setters, we can see that the table and its columns are declared declaratively in similar tags as ordinary HTML. The separation is very clear. Contrast this with Wicket, where this is done programmatically:
In addition to our Book bean, we also have to create a provider in Wicket. I find the whole model concept of Wicket confusing and unnecessary despite its claims that it has a simpler POJO model than JSF. If a table cell requires special formatting or displays more elements than a simple text, panels have to be created and therefore that number of files grows very quickly.
Documentation
JSF is a clear winner here as the amount documentation and tutorials available on Wicket is very limited; even the tutorials on its official site are outdated.
Furthermore, take into consideration that Stackoverflow has around 20000 questions on JSF, compared to 2000 questions on Wicket. What does this indicate? Either that JSF is far more prevalent or that things just work with Wicket, which I highly doubt.
Configuration
There seems to be a a war on XML among developers and a tendency to try to push configuration into Java code. The rise of fluid APIs is a good example. Although XML can be verbose, I believe there are areas where it shines and keeps the Java code clean.
Java annotations have done a lot to reduce XML configuration, and consequently, configuration files have become more compact. I prefer mixing annotations and configuring through declarative XML where it makes sense.
JSF only requires a single configuration file, that is web.xml. Additionally, faces-config.xml file can be used for global configuration and declaring navigations, etc. With version 2.0, managed beans can be annotated with annotations and navigation can be implicit, avoiding any XML configuration. However, there is a choice. Wicket, on the other hand, pushes all its configuration into Java, whether it makes sense or not.