Open debate: component-based or request-driven web frameworks?

On Wednesday I thoroughly enjoyed Petr Ferschmann's talk about JBoss Seam at CZJUG (recording). As Petr talked through problems with JSF, a little nagging doubt crept in about whether component-based web frameworks are the right approach. Petr is surely spinning in his executive chair and clutching his head right now. He was adamant that, although they had run into problems with JSF, they had turned out to be JSF features.

One issue we discussed was getters being called repeatedly at different stages in the JSF request lifecycle. Petr eventually convinced me that the issue had more to do with how JSF is implemented or designed than with the component approach itself. That left two open questions. Where should the view state be serialized? How much computation is needed to render the component tree? I have always used request-driven or command-based frameworks such as Struts and Spring MVC.

In general, component-based frameworks let developers forget that HTTP is somewhere under the hood, or at least they try to. They are therefore one level above request-driven frameworks in the abstraction they offer. Can we really hide the request-response paradigm? If we can, will request processing become much slower, for instance, or will the solution become excessively complex? It is also worth asking whether JSF, with its problems, is the right representative of a component framework, whether we should reach for something else, or at least wait for JSF 2.0.

Exaggerating a little, I would say it is easier to elect a president in Czechia than to wait for Java developers to agree on a web framework ;-).