I’m working with different JSF frameworks for some time now and had a look back to the Struts-based Common-Controls recently.
My last hands-on on Struts was in 2003. So, I can’t remember in detail if I had a good or bad feeling about using it. I remember that I chose it to get faster results. The learning curve was quite steep. But, reconsidering the time-frame I had the result was ok to me.
Todays JSF experiences in mind it was a quite different feeling to use Struts. Common-Controls adds some pretty nice controls to it, e.g. table and tree, but it’s still the “good old design” I already did in 2003.
When I did the JSF stuff the first time I discovered complexity. Much complexity. “Why we do so much for so little HTML code to generate?” I wondered. Doing a lot of pure HTML and JavaScript coding over the last decade I compared the expenditure of time of JSF and pure HTML/JavaScript. Well, to be more realistic I also thought about using PHP to get the database stuff into it. Even considering scalability, performance and the like the result was always: JSF is toooooo expensive in small and mid-sized projects.
But, comparing it to Struts, I’ve to say that Struts is even more expensive. If I have a look at the results I can create with both, JSF and Struts, and correlate this to the expected maintenance I’ve to dissuade from using both.
Mostly annoying to me is the fact that a lot of stuff in JSF and Struts has to be checked at runtime. Tags are loosely coupled to type-safe backing bean code (what I prefer most). The glue between all this is a bunch of complex configuration files. If you wanna track underlying dependencies you’ve to have a look in different presentations, switching from JSP/JSPX/XHTML with a bunch of taglibs behind to XML and then to Java and vise versa. For short, time-consuming and needless mental stress. Best of all, useless stacktraces with “meaningful” line numbers instead of context descriptions.
Well, JSF and Struts are Java standards and a lot of people use them. So, we can’t skip all this. Additionally, there are no real alternatives in the Java world to me at the moment. Well, to be honest, if we only look at the “markup-based world”. So, we’ve to pray that we’ll get better tool support in the near future to get rid of this error prone coding. Eclipse users may have a look at the (open-sourced) Exadel Studio Pro, delivering native support for Struts and JSF. Although, its visual tag designer has its limits the architecture is open enough to support even exotic JSF frameworks 
.
Cutting-edge …
There are new technologies at the horizon that may change the world the next years. You still think that the Flash player is a toy? Imagine it is a runtime, like the JVM, but in the third (multimedia-based) dimension, and with a JEE backend . Most interesting with Flex (you followed the link, didn’t you?): the creation of a desktop-like presentation is a snap. OpenLaszlo proves this, too.
… or back to the roots
Remembering the first steps of Java doing Web layer stuff, using Servlets, some weeks ago I developed the idea to skip all this tag stuff and take back the control using self-written Java classes doing the rendering on your own. Well, today I found an article describing a concrete project following this idea.
To get this idea into a project we need a framework, too. The article delivers some code. Maybe this is the first step. For me Spring is a good base to create such a framework. Simple POJOs doing the rendering and also the page definition. Maybe the Template Method Pattern can help here.
But, to be honest, there’s no time left to evaluate all this and start an OpenSource project on my own. For me Flex is a candidate for deeper exploration to get rid of all this error-prone markup stuff. Maybe it’s the base for Web 3.0 that allows us to create real desktops and not only AJAX fakes.
