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.
I did not find either JSF or Wicket to cleanly separate HTML markup and Java code. I wrote a little toolkit, called HTMLSplicer, to help create dynamic HTML content from servlets. http://sourceforge.net/projects/htmlsplicer/
ReplyDeleteIf you have time, I'd be interested in your thoughts.
That's an interesting approach. It will be interesting to see how Ajax interaction works with your approach. The examples remind me of javascript MVC frameworks that offer similar binding capabilities, which I think will be the common approach in the future where server side will provide raw data and presentation artifacts separately.
ReplyDeleteThanks. HTMLSplicer is only useful for the initial HTML loaded by the page.
ReplyDeleteFor AJAX interactions, the HTML template would include Javascript code to make the calls, like jquery.ajax(url, settings). The server would process the request with a servlet that returns a JSON response. The contract between the client and server is the URL, request params and JSON response. There is an example at http://www.doublecloud.org/2012/12/developing-web-application-with-jquery-and-java-servlet/
I was looking for others opinion about JSF and wicket when I came across your post. While I agree with your "beg to differ", according to my experience, your comparison has some flaws.
ReplyDeleteFirst of all, open the templates you provided in a browser and look at the result. Starting with "Wicket claims to separate HTML markup and Java code without introducing special markup tags" and concluding with "as far as templating goes, they are very similar" is either biased or simplified way to much.
On a project with low budget and a very very tight schedule, we really enjoyed having a fully designed html prototype developed by a designer, while we were working on the backend. After the customer approved the design, we just had to add a couple of wicket:id attributes and only a few wicket tags. This was a huge difference from what I was used to from JSF.
Next, counting the entries of one support page (i.e. stack overflow) isn't a quality measure for a framework. The wicket community is very active. You would have to consider more pages and compare the search results only of the last year or so, if you want to get a useful quality measure. Even then you would only have a quantity measure. A quality measurement would be a "average time to solution" analysis or so.
Finally, "but messier Java code with an inner class" is the programmers choice. It's really easy to write messy code using wicket, but it is just as easy to not! Inner classes can be externalized or you could use scala closures.
In conclusion, I would like to reaffirm your beg to differ. Both are great frameworks with different strengths and weaknesses.
Wicket does make the "action/bean" code more verbose. Nevertheless, I find it it easier to maintain because all the code is just in one place, the java class.
ReplyDeleteIn JSF, logic will usually be on both the Managed Bean and the xHTML page, which is in my opinion a lot messier than wicket's verbose code. Like said above, inner classes can be prevented in a lot of different ways, whereas the messy JSF logic scattered all over the place can not.
The fact that to me Wicket is a clear winner, is the complete separation of roles. A team of designers can work on the pages without even realizing it will be used in a java project. With JSF the HTML prototype is useless, and the developer team has to transform that prototype in working JSF pages with unforseen consequences.
If in your project, you've achieved complete separation as you describe, I applaud you. This was not my experience even though we had a team of designers as well. In my experience, as soon as you start introducing templating (panel hierarchy) then designers can no longer work on a separate piece without knowing about Wicket, and how it's templating works.
DeleteNazar, you have to be fair. If you want to discuss component based frameworks you have to have at least a conceptual understanding of how a markup designer would possibly want to visualise / edit components. The answer is either in the context of the embedding page or in isolation. Wicket provides both views.
ReplyDeleteTake a Wicket Panel component as you suggest as the non-working scenario.
Quite the opposite of what you say is true. In the markup file for the panel class, you may enclose the panel with code from the surrounding page. This surrounding code is then visible to the designer and provides the full page layout that supports the panel in the same way as at runtime. So the markup designer edits the component in its page setting! At runtime however, the surrounding code is ignored because it is outside the wicket:panel tag.
The result as I said is that you can let the markup designer edit the markup of the component within the page in a static setting without even running the server.
With a little configuration, a Wicket designer can provide the HTML designer with full IDE navigation control / autocomplete to JavaScript libraries, JavaScript refactoring, CSS refactoring etc. (NetBeans).
Could you please tell us how much more separation of concerns you would want to achieve?
I have achieved full separation of concerns in ALL my Wicket projects.
The disadvantages that you mention, e.g. use of inner classes, I am more than happy to trade them as more java code as a welcome replacement of JSF custom template and expression language.
Wicket tags are only markers where the java code places components. Your criticism of these markers is questionable. Without them, how would any back-end / controller be able to connect to the view?
So in a nutshell, Wicket not only provides full separation of concerns, but it also replaceses additional technologies such as custom template language.
I do not share your criticism of DataProvider. It is a welcome abstraction for anything more complex than a static list. It provides a framework for sorting, pagination and the interaction with services / cache. It typically plugs into the LoadableDetachableModel concept, which is typically a system wide re-usable component. One has to reach this level of understanding to appreciate the power of Wicket. At this level, choosing Wicket and writing apps with it becoms a no-brainer.