Initially I just can say: Wicket is the best web framework I have ever used. Meanwhile I have successfully finalized my third project with it. In the following few lines I will try to list the arguments for using wicket from both business and technical point of view, but the most important one is actually that each of those projects has been a success story at the end.
Open-Source and free
Apache Wicket is free. There are no license costs and you are not bound to a ‘one and only’ company for support. If you are having trouble with a consulting company you work with, simply go and find a better supporter. Before Wicket we used a commercial Struts-like framework and we were not allowed to get the source code of the framework in question so we had to debug and search for bugs without it. It took weeks before we got our support requests answered and even months before we got the bugfixes delivered for that framework.
Fast development turnaround safes time and money
The development turnaround is very fast. One of our customers told us, since we switched to Apache Wicket the velocity is three times faster than before (measured with scrum tools).
Wicket provides a big community which reacts on bugs and questions quickly. Knowledge about that framework is wide-spread and not just centralized in one company. What if the company which provides a closed-source web-framework go bust? You are dependent on that company. Furthermore the documentation and examples of Wicket usage are increasing. In contrast the commercial framework we used: the documentation was bad and had not evolved so that you have had to contact the support and pay for it.
Higher quality and stability
Since we use Wicket we have less bugs, a higher stability and qualtity in our software. But what Wicket cannot do is automatically write good code and correct architecture flaws. So you will need good developer with strong object orientation skills. Meanwhile you can find a lot of companies and developer which provide Wicket know-how and support, so the argument of missing development resources is not valid anymore.
Avoiding software erosion and react on requirement changes fastly
Wicket provides very good refactoring capabilities that enables you to react on requirement changes quickly. Additionally the refactoring capabilities keep the software erosion low. Often a software is already outdated on its first launch, because the requirements have often changed. Most web frameworks does not provide good refactoring capabilities, so that developer avoid bigger changes. After a while you often cannot understand the business logic from the source code anymore, but you should. So the software is already outdated and software erosion has taken control over.
In my experience Wicket has high acceptance by developer and motivated developer are more productive. Thanks to testabilty you can detect bugs early. There is a high reuse of existing frontend parts and aspects through components. Ideally you can create a component catalog, where the business department picks the components from and build there websites with it.
There are just two technologies: Java and XHTML. This makes it easy to learn Wicket, you do not have to learn new templating engines. You just bind your components to the XHTML through an own Wicket namespace. Everything can be bundled in a jar file and these can be bundled within war files. Less technologies causes less failure points. The only failure points are the binding between the java component and its matching HTML and the property paths of the PropertyModel. These possible failures can be completely reduced with unit tests though.
This is an advantage and disadvantage. A lot of developer are not able to develop object-oriented. Most people learn to use the power of object-orientation with Wicket. They have been developing Java for years, but they developed procedural mostly. What are services? Procedural. What are controllers in Struts? Procedural. What are beans? Just value holders. There is no real object-orientation. Wicket changes that, so the challenge is not to learn Wicket, but rather learn object-orientation. Object-orientation makes it easy to develop and cut clear business aspects.
Separation between layout and logic / JSP-free
Wicket uses pure XHTML which is XML. You have a clean HTML template with Wicket’s own namespace, so that you can bind the Wicket components to it. JSPs are bad. They are not compile-save, often confusing, usually containing a lot of business logic and they are not testable. At least you cannot bundle them into jar-files. In Wicket all the logic is in Java-code which makes it compile-save, unit testable and debugable. The raw HTML-Template makes it easy for a web designer to customize layout. So you can easier split the work between web designer and developer. Normally developer are more expensive than web designer and the developer should not waste his/her time with doing layout. Nevertheless both need to communicate with each other to integrate a layout appropriately.
Refactoring capabilities / Keep the business logic up-to-date
Refactoring is a major issue in development. It is always needed when requirements are changed and this happens very often. Frameworks like Struts use JSPs and other technologies which are not compile save. This makes a refactoring very hard, risky and sometimes impossible. So the developer hacks the changes into the existing skeleton. That causes an unclear and unmaintable code. Often the code is already outdated and fragmented before the first launch. As I explained above, Wicket just uses Java and XHTML. Due to its focus on Java it is possible to refactor code easily with existing tools like Eclipse. You keep your application logic in sync with the business logic. The few failure points can be covered with unit tests.
No session wasting and safe flows
In classic MVC applications everything was stored in the session. After a while the session was just a global garbage – sometimes a garbage dump. The developer forget to cleanup the session and it got bigger and bigger. Nobody knows whats in it. This can cause performance and security leaks. Furthermore every value gets unsafe casted, which can cause an unstable application and more bugs.
In contrast the Wicket session is type-safe. It can be a POJO. The Wicket session is just for global information like user authentification. Wicket pages are stateful. This allows to pass information from one page to another directly. Passing information from one page to another brings a lot of advantages. The user cannot start a flow without accessing the first page. This makes a flow safe. If a user aborts the flow, the passed data gets automatically cleaned up, because information is directly bound to that concret page instance. So you can concentrate on developing flows and not on data clean up.
Components are reusable. Thus saves development time and avoids duplicated code. The logic for a busniess aspect is encapsulated in a component or in some components which can interact with each other. The encapsulation causes an easier understanding of business aspects from code. Furthermore these encapsulated components are easier to test. So the business logic is not wide spread over the code like in classic MVC web applications. There is a technical separation between model, view (which often uses expression languages) and controller. These layers cause that you have to spread one business aspect over these three layers. Normally you do not have only one business aspect. Then you are mixing all business aspects within the technical separations and later you cannot detect any coherent business aspect anymore. In contrast a component does exactly represent one business aspect and this one is reusable. Components can be bundled in jar files, so it is possible to share components between different departments. In some applications I have seen the “WAR-overlay” pattern, which extracts a bundled war file to copy it in another war file. I mean a bundled war file must not be extracted, it is already bundled and should work as it is. There are new risks like wrong configuration, destroying the encoding, etc. The developer have to do that, because JSPs are not packagable in jar files. In my opinion an anti-pattern, which is provided by default in Maven. As I explained in Wicket you can bundle all your components with markup in jar files and these jar-file can be bundled in a war file without extracting. Clean packaged.
Nowadays a lot of web applications must provide AJAX-features. Wicket has a built-in and easy-to-use AJAX support. It is easy extensible and usable with AJAX frameworks like JQuery.
Wicket is one of very few web frameworks which provides a testing API. So you can validate that your components and pages do render and behave correctly. For example a registration form: a user provides values for all the fields and presses the register button. You can validate that the register-service call only happens when the form was successfully filled. For validating these calls you can use a mock framework like Mockito. Even AJAX testing is possible, but this is not sophisticated enough yet. Nevertheless the WicketTester provides the best testing API I have seen yet.
Wicket development is fun! I realized three projects with it. It just works and has caused very few problems. I think nobody of my collegues would switch to another framework. Wicket is the most productive web framework I have ever seen.
Thanks to Daniel Bartl and Samer Al-Huanaty for correction.