My primary interest in my current employment (who are the fine folks who sent me to JAVAOne) is the web tier technology. So I was looking forward to the Web Application Framework Smackdown. And it really was constructed like a royal rumble. Each representative (coming from Java Server Faces, Tapestry, WebWork, Wicket, and Shale) had 3 minutes to state the case of why they were great, why the others weren’t, and if they jabbed too low, a “foul” bell would ring. Good fun.

The biggest point, and the one that drew the most reaction from the crowd, was the statement that STRUTS is dead, as nearly all the frameworks presented are based on componentized designs. Only WebWork was retaining the command pattern, which had David Greary, key Struts developer and now Shale evangelist, quipping “what does that tell you [about WebWork]!” So a lot of questions were asked regarding which frameworks should Struts users migrate to.

Just a note: I feel that many people didn’t understand the nature of the move, as it completely changes interaction model of the web application; from commands that render certain output, to a GUI.

This obituary on Struts affects my workplace, so I am adding this to list of decisions we need to make. Plus, personally, I need to bone up on JSF.

Out of those presented, the only ones I can see us migrating to are JSF, Tapestry, and Shale. Why not Wicket and WebWork? Well, while Wicket sounds delightful, it sounds really different, and as for WebWork, I have to agree with Craig.

Java Server Faces is a standard, so we should learn it anyway. It seems easy to configure, and I like the use of POJOs backing each component. In our current code up we are making a conscious effort to have our business logic encapsulated in POJOs. My idea, and looks like it will pay-off to moving to any of these future platforms. Using JSF will be easy. The biggest con is that the tags it presents are VERY GUI oriented, designed to replace HTML in the JSPs. That’s great for developers, but not so great for the web integrators at my workplace who like to code their own HTML and JavaScript, thank you very much. Still, my boss spoke of visual beans two years back, and that’s what JSF is.

Shale actually builds on top of JSF and its creators gleefully drop the moniker Struts 2.0, though the community is resisting it. It compliments JSF, adding functionality that is missing or is yet to appear. Muti-page “dialogs” can be created easily, and that addresses a problem we have with the registration process for our portals. Finally, it is possible for pages to be completely written in HTML, and the Shale system takes care of binding it to the business logic; this would be great for our web boys. However, from what I saw in the Shale presentation the day before, there is a great deal of configuration that takes place that may make it hard to follow the logic flow of a page interaction (shale->dialog->tile->JSP?). This is a problem we already face with our current implementation (legacy), and I don’t care to repeat it.

Finally there is Tapestry, which honestly I haven’t looked at deeply. It is described as using POJO for logic, simple HTML for layout and design, and has AJAX support. More importantly, they’ve had all this for a while now and are nearing the release of version 4. Mature open source = good. Bad? The need to re-educate both our integrators and we developers.

In the end, I think we will stick with Struts and Tiles for at least a year, probably a couple of more. As much as its “dead”, I wouldn’t be surprised if it is carried on by the open source community. Plus, as always, there is the issue of time. I would rather have the time I can acquire for redesign/re-architecture to cleaning up the base business logic. Like I said, once major work is done, all of that logic will be simple POJOs, so moving should be much easier.