This post is the translation of the writing (Hungarian) from my other blog with the identical title.
In the recent months I had the pleasure to get acquainted with Wicket and JSF which are both servlet-based web technology frameworks with identical position and purpose. A Wicket presentation was also organized by Hungarian Javafórum guys at the summer, but unfortunately, I couldn't attend on it.
JSF is part of the J2EE standard, Wicket is a Sourceforge-project which has joined to the Apache Foundation some months ago. Wicket means the implementation itself, while JSF is just a specification with a reference implementation and some real implementations. I met Tomahawk among real implementations, which is also related to Apache.
Wicket uses HTML markup with wicket tags which are replaced to real HTML components in rendering time on the server-side. (Similar to Dojo with the difference, that Dojo replaces components on the client side.) JSF is taglib-based.
We used Facelets with JSF which helps modularization of pages. We also used standard tag library where we could. Instead of writing a long discourse, I've chosen some criterias and here I compare the two competitors:
HTML element set: What kinds of prefabricated elements are present.
Wicket: In the core API, there are just the most basical form components. There aren't sortable table or tree, however a bunch of cool components can be found here: Wicket extensions
JSF: Reference implementation is rather poor, however, there are some more opportunities in Tomahawk. Theoretically, it's possible to mix more implementations by getting the appropriate components even from commercial implementations. There's much room for improvement in Tomahawk JSF components. I've met tree2 which doesn't support default expanded nodes (when showing the tree for the first time, some nodes couldn't be expanded by default without attaching a workaround logic). Generally, a lot of workaround code was needed for creating really usable components, which was very time-consuming and rankling, considering we should spend that time for polishing the application's business logic.
DHTML support: Is it possible to inject javascript into the page or to components and is it possible to refer components?
Wicket: It's okay, but sometimes it's tricky to inject javascript into the pages.
JSF: Referencing components is problematic with the base implementation because it shares identifiers itself. With using "forceId" in Tomahawk, we can specify identifiers, which is basically enough for javascripting.
Logic extensibility: How much can we affect or modify the framework's workflow logic?
Wicket: It's quite possible even to change the code of the framework itself if needed, however, in most cases it's enough to inject logic by implementing and applying specified interfaces.
JSF: It's not easy to intercept, because the JSF engine is outside of the competency of the application. Additionally, JSF page life-cycle is very strict and not too much applicable for some cases. Validation, model update and page render stages have their own unchangeable places. We usually stuck to the problem for a long time when we use more complex validation logic, not to say about multiple forms on a page.
AJAX: They are coming from the pre-Ajaxian era, so Ajax-support is an added feature in each of them. However, supposedly JSF has Ajax-based implementations. (Maybe commercial ones.) Wicket fans say that embedded Ajax support is absolutely good. Practically, it's possible to make nice dynamic functions without writing any line of javascript. In the comment-conversation of the original post I described that I called an application really cool dynamic and "Ajaxified" if it had the same functionality as the Google Calendar. I don't think a JSF or Wicket application could convey this.
Data-model presentation bridge: Model must be pumped into the HTML elements.
Wicket: It happens in Java which is highly comfortable and makes easy to find errors. Hierarchy of the markup must be followed by the Java behind-code, e.g. if a text input is inside a frame stack, the model must contain these frame elements too. Generally, a lots of anonymous inner class must be used for describing the Wicket data-model. It's relatively easy to build in pieces of validation logic.
JSF: Bindigs between the page and the JavaBean-based model is described in XML. So-created model can be detached from the presentation somewhat easier but it needs more boilerplate XML code and JSF can cause further problems. If we manage to create XML without errors and there are no special demands, assembled parts may work in a surprisingly little while. When we want dynamic play, e.g. validation rules of a field depend on another field's value, we might expect problems.
Bugs:
Wicket: It logs quite detailed error messages and stack traces. It's straightforward to find the roots of the error messages in the java code. It's harder to make errors because a lot of potential error is filtered out by the used modern IDEs. Many errors come from mistyping hierarchy between the java behind-code and the HTML markup. It has to be mentioned again, that Wicket pages are simple HTMLs which can be displayed in a simple browser without any server.
JSF: Generally error messages are indirect or even there aren't error messages but anomalies can be seen on the page. Control is empty or it's falled apart. Searching for the missing comma or the mistyped name in the JSF and the XMLs is a 'great fun'. Using some static analyzer for developing JSF application is highly recommended.
Modularity, reusability: Reusability of HTML page fragments.
Wicket: The embedded "fragment" mechanisum can be used. I'd expect much more, however, Wicket fans are delighted with it.
JSF: Facelet support is an amazing hit, nevertheless, it's not direct part of the JSF spec.
Graphic design:
Wicket: As the markup is plain X(HTML), it can be designed by any HTML tool. Images and CSS can be used.
JSF: It isn't plain HTML, but there are more and more WYSWYG JSF editors to be used. Some of them are integrated into graphical IDE-s. (Netbeans, Eclipse, Idea) With these tools I managed to construct simple pages only. Images and CSS can be used too.
I18n: Certainly each of them supports internationalization.
Flow control on pages: Iterations, controlling components' visibility and other properties
Wicket: Doesn't support because it's a base principle that pages don't contain business logic. (But what's about presentation logic-related flow control?) 'Fragment' and 'iterator' mechanism can be used instead of writing direct flow control into the markup. Particular conditions of the iterations and if-else statements are located in the java code behind the page markup. You can switch some component properties also in the java code.
JSF: Supports flow control at more levels by certain tags of the standard taglibs, JSF tags and facelets. However, these mixed technologies don't always cooperate well, which can tremendously increase suck factor.
Server loading: I feel they are in the same level in this question. wicket needs more memory because it must store information about component hierarchy in user sessions. JSF rebuilds server-side representation of component structure upon every HTTP request, which needs increased amount of processing and theoretically settles for less memory. Be aware of serialization when using Wicket, because misconfigured members can easily pull up some megs into the session. Also take care of inactive clients and their sessions. Each of JSF and wicket can be clustered (as I know).
Documentation:
Wicket: it has good docs according to me. People who used more deeply say that it could be better.
JSF: every kind of writings can be found. Tomahawk has a Wiki wich contains mainly descriptions of problems among some useful posts. J2EE specification also has a JSF section.
Which of them would I use in the next web-project?
JSF, although it's somewhat more cumbersome, has more opportunities because it has more implementations. Before choosing JSF I'm sure I would look after a good one. However, if there would be less dynamic form-styled content I would use Wicket because it stands closer to the plain HTML, it's easier to design it, it's easier to code it. For those who are not familiar with JSP-s and taglibs I also would highly recommend Wicket. If there would be more logic, reused and nested model and form elements I would choose JSF. However, it would be too early to forget other web-frameworks. If I would have to make a really dynamic AJAX web-application I would presumably choose another framework beyond these two ones.
Here is another argumentation on the subject. It also contains a Wicket vs JSF opinion strongly on the Wicket-side.
In the recent months I had the pleasure to get acquainted with Wicket and JSF which are both servlet-based web technology frameworks with identical position and purpose. A Wicket presentation was also organized by Hungarian Javafórum guys at the summer, but unfortunately, I couldn't attend on it.
JSF is part of the J2EE standard, Wicket is a Sourceforge-project which has joined to the Apache Foundation some months ago. Wicket means the implementation itself, while JSF is just a specification with a reference implementation and some real implementations. I met Tomahawk among real implementations, which is also related to Apache.
Wicket uses HTML markup with wicket tags which are replaced to real HTML components in rendering time on the server-side. (Similar to Dojo with the difference, that Dojo replaces components on the client side.) JSF is taglib-based.
We used Facelets with JSF which helps modularization of pages. We also used standard tag library where we could. Instead of writing a long discourse, I've chosen some criterias and here I compare the two competitors:
HTML element set: What kinds of prefabricated elements are present.
Wicket: In the core API, there are just the most basical form components. There aren't sortable table or tree, however a bunch of cool components can be found here: Wicket extensions
JSF: Reference implementation is rather poor, however, there are some more opportunities in Tomahawk. Theoretically, it's possible to mix more implementations by getting the appropriate components even from commercial implementations. There's much room for improvement in Tomahawk JSF components. I've met tree2 which doesn't support default expanded nodes (when showing the tree for the first time, some nodes couldn't be expanded by default without attaching a workaround logic). Generally, a lot of workaround code was needed for creating really usable components, which was very time-consuming and rankling, considering we should spend that time for polishing the application's business logic.
DHTML support: Is it possible to inject javascript into the page or to components and is it possible to refer components?
Wicket: It's okay, but sometimes it's tricky to inject javascript into the pages.
JSF: Referencing components is problematic with the base implementation because it shares identifiers itself. With using "forceId" in Tomahawk, we can specify identifiers, which is basically enough for javascripting.
Logic extensibility: How much can we affect or modify the framework's workflow logic?
Wicket: It's quite possible even to change the code of the framework itself if needed, however, in most cases it's enough to inject logic by implementing and applying specified interfaces.
JSF: It's not easy to intercept, because the JSF engine is outside of the competency of the application. Additionally, JSF page life-cycle is very strict and not too much applicable for some cases. Validation, model update and page render stages have their own unchangeable places. We usually stuck to the problem for a long time when we use more complex validation logic, not to say about multiple forms on a page.
AJAX: They are coming from the pre-Ajaxian era, so Ajax-support is an added feature in each of them. However, supposedly JSF has Ajax-based implementations. (Maybe commercial ones.) Wicket fans say that embedded Ajax support is absolutely good. Practically, it's possible to make nice dynamic functions without writing any line of javascript. In the comment-conversation of the original post I described that I called an application really cool dynamic and "Ajaxified" if it had the same functionality as the Google Calendar. I don't think a JSF or Wicket application could convey this.
Data-model presentation bridge: Model must be pumped into the HTML elements.
Wicket: It happens in Java which is highly comfortable and makes easy to find errors. Hierarchy of the markup must be followed by the Java behind-code, e.g. if a text input is inside a frame stack, the model must contain these frame elements too. Generally, a lots of anonymous inner class must be used for describing the Wicket data-model. It's relatively easy to build in pieces of validation logic.
JSF: Bindigs between the page and the JavaBean-based model is described in XML. So-created model can be detached from the presentation somewhat easier but it needs more boilerplate XML code and JSF can cause further problems. If we manage to create XML without errors and there are no special demands, assembled parts may work in a surprisingly little while. When we want dynamic play, e.g. validation rules of a field depend on another field's value, we might expect problems.
Bugs:
Wicket: It logs quite detailed error messages and stack traces. It's straightforward to find the roots of the error messages in the java code. It's harder to make errors because a lot of potential error is filtered out by the used modern IDEs. Many errors come from mistyping hierarchy between the java behind-code and the HTML markup. It has to be mentioned again, that Wicket pages are simple HTMLs which can be displayed in a simple browser without any server.
JSF: Generally error messages are indirect or even there aren't error messages but anomalies can be seen on the page. Control is empty or it's falled apart. Searching for the missing comma or the mistyped name in the JSF and the XMLs is a 'great fun'. Using some static analyzer for developing JSF application is highly recommended.
Modularity, reusability: Reusability of HTML page fragments.
Wicket: The embedded "fragment" mechanisum can be used. I'd expect much more, however, Wicket fans are delighted with it.
JSF: Facelet support is an amazing hit, nevertheless, it's not direct part of the JSF spec.
Graphic design:
Wicket: As the markup is plain X(HTML), it can be designed by any HTML tool. Images and CSS can be used.
JSF: It isn't plain HTML, but there are more and more WYSWYG JSF editors to be used. Some of them are integrated into graphical IDE-s. (Netbeans, Eclipse, Idea) With these tools I managed to construct simple pages only. Images and CSS can be used too.
I18n: Certainly each of them supports internationalization.
Flow control on pages: Iterations, controlling components' visibility and other properties
Wicket: Doesn't support because it's a base principle that pages don't contain business logic. (But what's about presentation logic-related flow control?) 'Fragment' and 'iterator' mechanism can be used instead of writing direct flow control into the markup. Particular conditions of the iterations and if-else statements are located in the java code behind the page markup. You can switch some component properties also in the java code.
JSF: Supports flow control at more levels by certain tags of the standard taglibs, JSF tags and facelets. However, these mixed technologies don't always cooperate well, which can tremendously increase suck factor.
Server loading: I feel they are in the same level in this question. wicket needs more memory because it must store information about component hierarchy in user sessions. JSF rebuilds server-side representation of component structure upon every HTTP request, which needs increased amount of processing and theoretically settles for less memory. Be aware of serialization when using Wicket, because misconfigured members can easily pull up some megs into the session. Also take care of inactive clients and their sessions. Each of JSF and wicket can be clustered (as I know).
Documentation:
Wicket: it has good docs according to me. People who used more deeply say that it could be better.
JSF: every kind of writings can be found. Tomahawk has a Wiki wich contains mainly descriptions of problems among some useful posts. J2EE specification also has a JSF section.
Which of them would I use in the next web-project?
JSF, although it's somewhat more cumbersome, has more opportunities because it has more implementations. Before choosing JSF I'm sure I would look after a good one. However, if there would be less dynamic form-styled content I would use Wicket because it stands closer to the plain HTML, it's easier to design it, it's easier to code it. For those who are not familiar with JSP-s and taglibs I also would highly recommend Wicket. If there would be more logic, reused and nested model and form elements I would choose JSF. However, it would be too early to forget other web-frameworks. If I would have to make a really dynamic AJAX web-application I would presumably choose another framework beyond these two ones.
Here is another argumentation on the subject. It also contains a Wicket vs JSF opinion strongly on the Wicket-side.
Comments