Wicket review

A couple of weeks ago i spent a couple of hours reading up on wicket. I have to say i was quite intrigued by some posts that one of my favorite bloggers had posted ( geertjan ). He was quite ecstatic about how easy it is quite easy to develop in wiçket. Alright, i thought, let me see what it is all about.

So, i sat down and went through what i thought was almost all documentation that i could get my hands on during those few hours. I do agree that it manages to take away a lot of the complexity that is inherent to web app development - e.g. No need to deal with http requests and responses, no sessions, nothing of the sort. The development model is very similar to a swing ui development model - you just work with objects, add listeners, process events...pretty sweet feeling. All in all for a fairly small learning curve ( especially if one is already familiar with swing development), you get a fairly straightforward way to develop a web app. It turned out that the way that is possible by keeping everything in the session. Now, my first reaction ( well indoctrinated in good j2ee dev practices :-) ) was to pull back and think that something is not quite right... However, after´some further consideration... Hey, why not??? After all it is a stateful web dev framework, the state has to be preserved somwhere... Sure it's new and might have not been tested for scalability over thousands of users.. but then, for 90-some percent of the apps out there, there are a few users here and there, and really it doesn't require scalability up to thousands of users...

The templating capabilities seemed to be pretty cool as well, as you could nest and compose templates from other components up to an arbitrary depth. The templating sysstem seemed to be pretty straightforward as well, kinda similar to the facelets or the tapestry templating. So, that was nice too...

So, all in all I liked what I saw. On the other hand, I do have a strong preference for using whatever is "standard" in the particular space (or at least 2nd most popular). In light of that, although Wicket seemed to be offering a couple of interesting design options, it's far from being popular or have a large user community. Now, one of the reasons that I was actually looking at Wicket was because of the problems that I had previously with using JSF (e.g. had some problems with event handling on request-scoped components or with components inside a dataTable - both of which turned out to be well known problems with the reference implementation). In light of that, if one put everything in session scope in a JSF project,then that would solve all of the difficulties that I was having with JSF as well. Additionally, there is pretty decent support for developing with JSF (e.g. IDEs, books, etc), which wasn't really there for Wicket. Finally, it seems to me that although when you work with Wicket, often times you might not have to even touch any html, it seems to me that when I do web development, sooner or later I would have to deal with html.

Luckily, at my job, I pretty much have choice of what framework or approach to use in developing the next application. Thus, I really don't have to learn any framework or approach that I don't think would be useful in the future or wouldn't be a good investment of time from all points of view. So, from the easiness point of view, Wicket does have a lot to offer. However, at this point, at least for me, from a "future investment" point of view, I think that investing more time into JSF would be more valuable.