If you’ve read my previous posts, you’ll know that I’m on an unending quest for the right Java web framework. While Faces shows some promise, I’ve got this conviction that the future of the web-layer isn’t going to come from Sun. Call me pessimistic, I don’t care, i’m just not excited by the technology. …..so I thought I start another food fight by communicating some positive and negative first impressions about another Java framework - Wicket. Read more…
To Tapestry lovers, before you decide to write a rant about how Tapestry is the one true way, please understand that I already know that. I chose to evaluate Wicket because I don’t know Wicket, please calm down a little bit about Tapestry and read a bit about Wicket, maybe there’s something to learn, maybe not. Thanks.
Wicket First Impressions: A Summary
It’s different, in some ways refreshing, but like all web frameworks, it comes with a special set of problems. It’s a little code heavy to be considered cool by the Web 2.0 crowd. But, at the risk of sounding like a Java developer, there’s nothing wrong with writing compiled code now and then, and Wicket seems to make it easy to approach web application design from an OO “mindset”. In terms of web development, Wicket avoids the Markup <-> Code impedance mismatch by making a clear choice to favor Java over markup. You won’t be writing JSP code, you won’t be fumbling around with some tag library and then figuring out how to convert a set of form fields to an object. Instead, you’ll be writing Java code (with a fair number of inner classes and anonymous types). It is certainly a different approach than most J2EE developers are used to, and if you are new to Java, it’s entirely different from the (A|J)SP approach.
Another Framework? do we need another Framework?
Like many Java programmers out there: I’m am of two minds. On one hand, I’m doing some pretty intense “enterprise” development in Java using JMS, clustered JNDI, writing lots of multi-leveled applications with some pretty complex logic. On the other hand, there’s this constant pressure to simplify (especially at the web layer). So while the Java programmer in me really appreciates Wicket as an elegant OO approach to web development, the Rubyist in me is horrified. This is an internal conflict at least a few of us are experiencing: when it comes to Wicket, here are my two opinions, the bad one first, because it was my intiial reaction:
The Bad: Wicket == More Code, More Tedium, Too “Frameworky”
WTF? Wait a minute, so we go from something like Ruby on Rails where I’m templating in Ruby and can do anything in the world, straight to having a Java class for every page and having to have HTML files sit next to my Java classes. Are you insane? Please help me out here, just creating a link between two pages requires:
- The Creation of an Anonymous-type in a Page class: add( new Link(”viewLink”, new ViewProductPage(this, product.getId() ))
- Referencing of this link with some wicket:id: <a href=”#” wicket:id=”viewLink”>view</a>
Wicket is an awful code explosion, written by Java-intoxicated programmers. If you are looking for lightweight, nimble framework, a framework that could conceivably be used by semi-programmers or the usual half-wits who occupy your average corporate IT stable, this is not the framework for you. In fact, compared to something like Ruby on Rails, this framework has a steep and somewhat endless learning curve that can be summed up by the phrase: “just copy the example code, and customize it”. But, if you’ve tried doing anything even remotely involved, you’ll no doubt run into increasingly cryptic error messages like “_” component not found, for which there is no good answer on google or nabble because CONGRATULATIONS! you are one of the first dim wits to start using this framework. Good job early adopter, on a river with no oars.
In this age of lightness, Wicket is a heavy hammer. If you are looking for Hello World in 1 minute, run toward something else as quickly as you can.
The Good: Why Wicket is Great Framework
See here’s the problem, AJAX development with something like RJS and Rails only scales so far, once you start getting into the business of creating extremely granular AJAX interactions which change multiple DIVs you’ll find that you’ll be managing IDs of practically everything on your page. You’ll end up having to code some fairly ridiculous complexity into your code just to manage the coordinate system of your HTML document. Check out this TreeTable example. Doing this in Rails and RJS or Struts and DWR or any other framework (except maybe Faces and Tapestry) would take a great deal of complexity. Wicket creates that table in no time at all.
Sure the learning curve is a little steep, but once you catch on, it makes perfect sense, and contrary to my negative opinion, the fact that there is a rich set of examples makes it easy to figure out how to: implement AJAX trees and tables, data grids, without spending days and days reading umpteen blogs and “participating” in hostile, low-traffic development mailing lists. You might have some trouble getting the Spring integration to work properly, but if you’ve alredy got a bunch of DAOs in Spring, hooking them up to your Wicket models, applications, and pages is as simple as putting some annotations on your Page’s member variables.
if you are looking for the Hello World in One Minute framework, there’s a good chance that you are not developing a real application. Wicket brings complexity in the form of a rich component framework, but this complexity brings with it the ability to code a web site without having to code yet another table, or yet another paging mechanism. Believe it or not, the code you end up creating with Wicket is clean, and from what I’ve seen you don’t end up making any compromises wrt to separation of presentation and logic.
What the hell is a ‘wicket’ anyway?
The definition of a Wicket will make absolutely no sense to you. Here’s the first definition: “Either of the two sets of three stumps, topped by bails, that forms the target of the bowler and is defended by the batsman.” then there is the second definition, “A batsman’s innings, which may be terminated by the ball knocking the bails off the stumps.”
So wait, what? I don’t know, cricket is a mystery to me.
Wicket Extensions, Wicket Stuff (Spring, Groovy integration)
Depite all my complaining about Groovy not being a real language (compared to Ruby), it is a refreshing break from the verbosity of Java. Wicket provides interoperability with Groovy in the form of a seperate integration project. Wicket 2.0 (which you’ll have to build from Subversion) has some good contrib add-ons for scriptaculous, prototype, Dojo, hibernate, Spring, all the usual suspects. I just wrote an extension library for Wicket myself for a Flash video player and it was a pretty straightforward task once I copied an existing widget.
If you are looking for something lightweight that will take a few minutes to learn, Wicket is not for you. If you are looking for a component-oriented approach, Wicket is a contender. It requires some up front investment of time, and the documentation isn’t 100%, but the applications I wrote in Wicket are cleanly designed and easy to modify. It is a refreshing change of pace for anyone grown accustomed to the disaster that is Struts 1.x, and along with Tapestry it is one of the logical choices if you are looking for a component-oriented alternative to Java Server Faces. But, be aware that Wicket isn’t any sort of Rapid Application Development tool, and it doesn’t aim to be one. I use Wicket when I need to create an extremely AJAXified interface, something much more than simple DIV replacement.
The only solid conclusion I can come to about web frameworks after the endless years of searching is that there is no holy grail (despite what people are going to write on the comment thread ;-) ). There is only, “the right tool for the right job”. Me? I like Wicket for some projects, for others I wouldn’t use a component-oriented approach. You?……form your own opinion, but, do me a favor, give it more than a cursory glance before you tear it to shreds, the internet is full of enough hot air.