Most existing web frameworks provide weak to non-existent support in managing server-side state
This normally means lots of ad-hoc code in web applications dealing with the gory mechanics of state management. While Wicket will not allow you to stop thinking about server state, it goes a long ways towards making it easy and often transparent to manage that state.
In Wicket, all server side state is automatically managed. You will never directly use an HttpSession object or similar wrapper to store state. Instead, state is associated with components. Each server-side page component holds a nested hierarchy of stateful components, where each component’s model is, in the end, a POJO (Plain Old Java Object). Wicket maintains a map of these pages in each user’s session. One purpose of this page map (and the component hierarchy on each page) is to allow the framework to hide all details of how your components and models are accessed. You deal with simple, familiar Java objects and Wicket deals with things like URLs, session ids and GET/POST requests.
You will also find that this well-structured server state makes it very easy to deal with the dreaded “back button problem”. In fact, Wicket has a generic and robust solution which can identify and expire browser-cached pages that have become stale due to structural changes to the model of a component on the page.
Finally, Wicket has been designed to work with POJO persistence frameworks such as JDO or Hibernate. This can make database driven web applications quite easy to write.
For many applications, it will be worth trading off the increased server load of extra server-side state for decreased development costs, lower maintenance costs, quicker time-to-market and generally higher quality software. The basic observation here is that software is expensive and complex while servers from companies like E-machines and Dell are relatively dirt cheap.
In terms of efficiency versus productivity, perhaps Wicket is to JSP as Java is to C. You can accomplish anything in Wicket in JSP. You may even do it more efficiently in terms of memory or processor consumption. But it may take you weeks or months longer to develop your application. And in the end, since state management in JSP is ad-hoc, you are likely find security problems and bugs popping up everywhere. Most of the other frameworks above will do only a little more to help you.
Most existing frameworks require special HTML code
JSP is by far the worst offender, allowing the embedding of Java code directly in web pages, but to some degree almost all of the frameworks from the list (except Tapestry) above introduce some kind of special syntax to your HTML code.
Special syntax is highly undesirable because it changes the nature of HTML from the kind of pure-and-simple HTML markup that web designers are familiar with, to some kind of special HTML. This special HTML can be more difficult to preview, edit and understand.
Wicket does not introduce any special syntax to HTML. Instead, it extends HTML in a standards-compliant way via a Wicket namespace that is fully compliant with the XHTML standard. This means that you can use Macromedia Dreamweaver, Microsoft Front Page, Word, Adobe Go Live, or any other existing HTML editor to work on your web pages and Wicket components. To accomplish this, Wicket consistently uses a single id attribute in the Wicket namespace (“wicket:id”) to mark HTML tags that should receive special treatment by the toolkit. If you prefer not to render Wicket namespaced tags and attributes to your end-users, Wicket has a simple setting to strip them all out, resulting in ordinary, standards-compliant HTML.
No “special sauce” in your HTML means designers can mock up pages that you can use directly in development. Adding Java components to the HTML is as simple as setting the component name attribute. And you can then give the HTML back to your web designers knowing that they can change it with confidence.
Wicket, more than any other framework gives you a separation of concerns. Web designers can work on the HTML with very little knowledge of the application code (they cannot remove the component name tags and they cannot arbitrarily change the nesting of components, but anything else goes). Likewise, coders can work on the Java components that attach to the HTML without concerning themselves with what a given page looks like. By not stepping on each other’s toes, everyone can get more work done.
Existing frameworks are not easy
Most of the existing toolkits have poorly defined or non-existent object models. In some cases, the model is defined using special XML syntaxes. The syntaxes may be so cumbersome that special tools are required to manipulate all the configuration information. Since these toolkits are not simple Java libraries you may or may not be able to use your favorite IDE tools such as editors, debuggers and compilers.
Wicket is all about simplicity. There are no configuration files to learn in Wicket. Wicket is a simple class library with a consistent approach to component structure. In Wicket, your web applications will more closely resemble a Swing application than a JSP application. If you know Java (and especially if you know Swing), you already know a lot about Wicket.
Existing frameworks inhibit reusability
Tapestry and JSF at least have component models that allow reuse, but you are likely to find that it is not particularly trivial to do, at least when compared with Wicket. Wicket has been explicitly designed to make it very, very easy to create reusable components. It’s surprisingly simple to extend existing components and to make compound components such as a SignInPanel or AddressForm. It is also relatively easy to create components that exploit new features of browsers. Components in Wicket can be packaged up in JAR files and reused by simply dropping them in your lib folder - no configuration necessary!
Web programming should be fun!
This is my most personal goal for writing Wicket . None of the existing frameworks are appealing to me in terms of intuitiveness, quickness, ease of development, etc. It is my hope that Wicket represents a significant step in the direction of making web applications easy and fun to write.
