It’s hard to believe that it’s been a year since my “burrito” podcasts on JSF. So what have I done in this last year with JSF? What is my opinion now and how has it changed?

Have you ever skipped out on a movie that was popular? Decided not to see it because it either didn’t fit your taste or didn’t mesh with your life in some other way? I have. I usually look back later on without regret. That’s the way I feel looking back at JSF a year later, but let give you some details.

I’ve changed organizations and roles in this last year. At my old place, we continued to use JSF through the time I left. For a couple months at this new place I worked as a Senior Developer on different team, before being asked to step in as the Manager for my current team. During that time, the team was just starting a new project. They had decided to use JSF, and so I had a bit more than a month where I continued using JSF, again pretty much every day (some days were more Hibernate/JPA-focused). We used Facelets, and looked at Seam (decided “No”). The newer JSF stuff was a bit nicer to use, and Facelets made it feel like I was programming with JSP tags again, so I could do layouts easier. I added some stuff from various popular JavaScript libraries (before AjaxFaces), and it seemed to work pretty well with what we had.

Overall, I just found that it only seemed to add complexity without taking a substantial load off my plate. Another issue arose in testing JSF. Again, it’s always been a challenge, since early on. While it’s gotten better, I’ve watched Ed Gibbs’s team struggle with testing JSF. In some ways, he says it’s been a hurdle in adopting TDD in his team:

The core issue comes down to having to use JSF for the GUI layer and dealing with its’ many mock objects using Shale’s mocking package for JSF. Thus many tests cannot simply test a single method without making sure FacesContext and many other stubs are setup. This tends to make the tests harder and more tedious to write especially for developers who haven’t quite caught the whole TDD bug anyway.

As I’ve moved into my position as a Manager, I took on direct responsibilities for not only the technical work of my team, but also for working day in and day out with our main client (internal), the deadlines for our product, and meeting the overall company initiatives started from the upper management (I’m in a weekly meeting with several VP’s and others about an initiative directly affecting my product). In all the work we have to do on our project, very little of it has centered around a need for reusable UI components. We work in an enterprise environment. I work for a Fortune 500 company, with IT sprawled as far as the eye can see. We have standardization efforts, we have a heterogeneous environment. For all intents and purposes, one would predict that we’d really need JSF. And yet I look back over a dozen release cycles that we’ve been through since I took this position, and so few of them have required anything close to the features JSF offers above other web frameworks. There are a couple, sure. But for those few we’ve used some standard solutions that are common to our organization and they’ve been good enough.

Where has the work been? We’ve eliminated EJBs. We’ve implemented Spring. We dumped Ant and moved to Maven 2. We’ve thrown out an older, commercial rules engine and setup JBoss Rules (formerly Drools). We’ve made major shifts in our application functionality to accommodate some fairly significant business changes. We’ve expanded our user base, and improved our turn around time for small items. We’ve started some in-depth User Centered Design work with our HCI group that’s focused on bringing some existing business processes into our app for the first time, and reworking some existing stuff. We’ve made quite a few changes, and done a lot of work over the last seven months. I’ve focused mainly on the technical changes here, but the main thrust of our work has been support for business needs. Those, in turn, drove the technical needs.

In conclusion, I stand by my previous opinions that I feel that solving business problems is both more interesting and more important. For me, the vast majority of that is done outside the UI layer.