a ser ainda muito nova e ainda verde. Depois, continuaram a não correr bem. No futuro, espero que não corram.
Cheguei à conclusão que JSF não é a melhor solução para desenvolvimento web em Java e consegui reunir umas quantas razões minhas:

• JSF é uma especificação

JSF é uma especificação e existem diversas implementações, sendo que a Sun fornece uma Reference Implementation. Por um lado, a especificação deixa pequenos detalhes de implementação à escolha dos implementadores e por outro, existem algumas falhas de desenho na especificação, assumidos inclusivamente por quem está a trabalhar na versão 2 do draft de especificação.

• Fases

O processamento JSF é dividido em 6 fases e é definida a ordem e o que ocorre em cada uma delas. O programador, em muitas situações, tem de ter a noção de fase presente quando está a programar, a desenvolver as suas acções, etc. Requer um conhecimento que apenas é adquirido com experiência e muitas falhas Aliás, tanto a noção de fases como as questões de request e sessão também deveriam ser o mais transparentes possíveis para quem desenvolve, deixando o programador dedicar-se a desenhar o interface e adicionar comportamento aos elementos do interface, como se fosse uma simples aplicação.

• Bugs

Historicamente, foram detectados alguns bugs graves nas implementações de JSF. Um dos exemplos é o do JSF gerar identificadores que já existiam declarados pelo utilizador na página, se foi resolvido passado meses.

• Identificadores Únicos

Temos de ter cuidado com identificadores duplicados e acaba-se por ter de se definir o id de cada componente da página. Obtemos um erro quando tentamos consultar a página e a origem do mesmo é não raras vezes difícil de depurar.

• Renderkit

Renderkits são um esquema falhado, no que toca a desenvolver para web. Em casos reais é quase impossível fazer output para múltiplos outputs sem alterar o conteúdo do jsf. Além disso, a geração de html está escondida dentro do renderkit e é difícil de controlar.

• Web Semântica e Acessibilidade

É muito difícil controlar o código que é gerado pelo JSF .
No mundo actual, quer-se markup semanticamente correcto, separação entre informação semântica (XHTML) e apresentação gráfica (CSS) e acessibilidade para utilizadores com necessidades especiais. Deve ser possível ter um controlo fino sobre o markup gerado. As interacções com os designers (mesmo com o meu post anterior não nos safamos) tornam-se mais complexas pois o programador não consegue replicar o código criado pelo designer.

• Manutenção de estado

Para manter o estado entre requests, o JSF fornece apenas a noção de sessão. Componentes como o SaveState do Tomahawk ou novas frameworks facilitadoras como o JBoss Seam permitem ter a noção de Conversation numa aplicação JSF. Se não forem utilizados estes componentes, o programador é obrigado

a usar a sessão, caindo no erro comum de definir Managed Beans como de sessão quando tal não é adequado. Ou então colocando a informação do bean em sessão e recuperando-a quando necessário, no caso de beans de sessão. Ao usarmos estes esquemas de sessão não conseguimos, por exemplo, navegar em duas páginas da mesma aplicação ao mesmo tempo.

• ValueChangeListeners

Os eventos são processados mesmo quando não é esperado. Por exemplo, se tivermos uma dropdown com um ValueChangeListener e um valueBinding para uma nossa String, se submetermos a página sem alterar a dropdown, o evento será lançado porque o valor anterior da variável era null e o que é submetido é o valor default. Além disso, quando temos dropdowns com immediate=”true” e fazemos alterações no ValueChangeListeners, temos de saltar para fase de RenderResponse para que não tenhamos os dados reescritos. Duas palavras: mau desenho.

Estas são razões que chegue para não usar JSF. O que acontece em muitos casos, é usarem-se frameworks que tornem a tecnologia suportável, como sejam os componentes Tomahawk ou as frameworks Facelets e JBoss Seam.
Quando finalmente se chega à conclusão que existem outras frameworks que são melhores que JSF, encontramos coisas como o Tapestry ou o Wicket. Estas duas frameworks permitem-nos definir o interface com markup xhtml, conseguindo assim a desejada interacção com os designers e podendo, inclusivamente, fazer as nossas páginas directamente do protótipo.