Discussions about web frameworks online often lead to extended flamewars, with fanboys of various frameworks trading arguments and inevitably, insults. It’s not secret that I’m a bit of an Apache Wicket fanboy. Though I don’t believe it is the perfect framework for all situations and problems. I find it to be more of a swiss-army knife: it’s one of the most versatile and well-rounded frameworks I’ve come across, pretty good at most things, but certainly not without a few rough edges or weaknesses, just a lot fewer rough edges and weaknesses than any others I’ve come across.
Different Problems, Different Solutions
The thing is, different frameworks emphasize different problems, and approach those problems in different ways. They also emphasize different mixes of developer skills, allowing developers to spend the bulk of their time with technologies they are comfortable with. For instance, I would say that Wicket is ideal for webapps that have a mix of user interactivity and content presentation, written by developers who are good at Java (or Scala) and understand object orientation.
However, if I was looking to build something that was 95% read-only, I’d probably not use Wicket. In fact, I’d probably save myself a lot of effort and simply look at a decent publishing/cms platform, like oh, say, Wordpress? Customized templates, job done, time to go home.
If I was looking to write a Rich Internet Application type webapp, heavy on interactivity with no/few requirements to be search indexable and discoverable, I might look at frameworks that solve that problem, like GWT or it’s cousin Vaadin. But most likely, I’d probably be somewhat tempted to go for a html/css/js only front-end talking to a RESTful backend built on top of Scalatra, along the lines I discussed in an earlier post, and at the same time get a hopefully nice API to go with my webapp so others could build clients on top of my platform as well.
All the Wrong Reasons to Chose a Web Framework
Organisations often chose the wrong tools for the job because of a number of reasons, either because of irrational fanboyism, Resume Driven Development or because “it’s the corporate standard”. The last one in particular annoys me, as the practical implication is that you should use the hammer if that is the “standard tool”, even if the problem you are faced with requires a drill or screwdriver.
The right reasons are problem fit and skills available. It’s really that simple.
There really is no “perfect” web framework, a search for one is futile and the results will largely be dependent on what you are trying to solve and how well it fits with your skills and way of thinking (though sometimes a learning curve is more than worth the effort). Use what works for you and your project, and evaluate your choice based on those criteria.
Oh, just don’t use Struts or JSF. They’re useless piles of donkey poo, unfit for any purpose given the multitude of alternatives. Extended use of Struts or JSF will make any reasonable man want to stab themselves repeatedly in the Cerebral cortex with a rusty spoon just to end the misery.