To Seam or not to Seam

It seamed a good choice back then, to choose for JBoss/Seam. When looking at the various examples available on the Net, it all just looked so simple and neat. It was only until we started to actually write code ourselves we figured out things wouldn't be as easy as we would have hoped for.

In the beginning, most of us had a hard time to get the smallest thing working. There was always a little something that went wrong, and when it went wrong, it was pretty hard to figure out where the actual problem was situated, as debugging information is, at least for the untrained Seam-programmer, obscure to say the least.

However, it's not all bad news: once you get the hang of programming the various facets Seam provides and you start understanding more of the error messages Seam throws in your face, you also begin to appreciate the true power, flexibility and variety of functions Seam has to offer.

This evolution in knowledgde about the framework was also clearly visible in the rate of development. As we mentioned during the second conference, it was hard to gain some momentum in de developement process. However, once the ball got rolling, it was hard to make it stop and it seems, at this time at least, we are producing massive amounts of clear, correct and complete code.

So the question is, do I still question our decision to start our project in the Seam framework? Well, I guess the answer is still two-fold: on one hand we really got a grasp on a major part of the featureset Seam has to offer, allowing us to program a modern webservice, written in flexible views allowing support for future webstandards. On the other hand, we still, from time to time, run into small, and sometimes bigger, problems, and when we do, we still spend a lot of time figuring out where things do go wrong.

I guess I will be able to give a more definitive answer to the question asked before, once the project is finished up and final implementation is delivered.