Write a review to share your experiences with open source!
On DevRates we focus on reviews by developers using libraries on their daily work.
Interested in the latest trends and top-rated open source projects for all layers of your application?
DevRates contains projects reviews of most popular tagged categories and programming languages.
Follow projects and don't miss any news from blogs and twitter on your wall.
Your company is looking for talented developers? Register on DevRates and show your technology stack on your company profile.
Designing and implementing any framework for use in the real world inevitably involves compromises and some degree of complexity, and Wicket is no exception. However, I believe you will find that Wicket is quite compact, focused and powerful as a framework. If Wicket has these characteristics, it is because it was designed to solve one very specific problem well:
enabling component-oriented, programmatic manipulation of markup
Wicket does this and very little else, and that is a good thing.
I once heard Josh Bloch talk about the power to weight ratio of an API. The highest compliment anyone could make of Wicket would be to suggest that Wicket has a lot of power and not much conceptual surface area.
In art, negative space is the part that’s not the subject. In music, negative space is the rest. In software, negative space is all the code that you managed to avoid writing. In all three disciplines, it’s what separates what is truly excellent from what is merely good.
Following this metaphor, if Wicket is our foreground object, it is defined in a negative sense by all the things that it is not (by the background).
In other words, ideally, Wicket is a web UI framework that delegates as many areas of responsibility as possible to other, more focused tools and techniques. It recognizes that Hibernate is good at persistence; that Spring is good at DI; that Java properties files are good for localization; that sub-classing is good for creating component types; that Dreamweaver is good at doing HTML layout; that Beans are good for structuring properties; and so on.
full review »
I always had a difficult relationship with Wicket. It does have its strong points for sure, but building the component tree twice (once in HTML, once in Java, and keep those in sync) just doesn't fly with me. The URLs can become quite ugly as well, with lots of colons and WicketIds in them. Performance is okay and basically on par with JSF 2 (JSF 2 is a bit faster and uses less memory, but the differences are not that big)
One of the major shortcommings of Wicket is its community, n the sense that its simply not really there. Sure, the core developers are present and such, but relatively few people use Wicket making it hard to find anyone to answer your questions, writing a blog post or posting some example code.