Losing Face(s)?

I’m a bit torn at work.  I’ve long described our shop as a JSF, Spring, and Hibernate shop, a designation with which I am perfectly happy.  Last week, however, after pointing my boss to a blog entry by a someone I “know”  (I quote that, because he’s someone I talk to on IRC ;), I have been asked to investigate a framework called Wicket that could supplant JSF in our stack.  While I’m not opposed to learning Wicket (so far, it’s been pretty cool), I’m just a little leary/weary of the technology treadmill, where we constantly reevaluate our technology choices.  While a certain amount of that is healthy, too much of it paralyzes your organization, and, personally, I’m a little burned out on research and ready to get some actual work done.

Having said all of that, as cool as Wicket is, my inclination is to stay with JSF.  For all the wailing and gnashing of teeth I’ve seen about how “hard” JSF is, and that you can’t do it without good tool support, I’ve not had much problem with it.  It’s certainly not easy, but it’s a far cry from the impossible mountain to scale that some make it out to be.  It does have its warts, to be sure, but I like it, and it works well for us.  Add to that the momentum JSF seems to be building (especially when compared to other frameworks) makes me more hesitant to drop.  It is a truism that popularity doesn’t make something better, but, in this case, JSF works for us, and I don’t want to adopt something that 1% of the rest of the world is using.  Technical superiority (assuming Wicket has it) is meaningless if no one knows how to use the tool.

Now, to be fair to Wicket, I’ve been playing with it for just a few days.  I like it well enough (despite the problems I’m having with Spring and Hibernate with it, which are my problems and not Wicket’s), but I’m not sure I have the energy or desire to dig much deeper into it.  I’d really like to get some real work done, so Wicket may lose out to practicality.  Time will tell.