Você optou por um framework component based, escolheu trabalhar com JSF e ainda não sabe se deve encarar riscos e custos de migrar para a (não tão) nova versão da especificação? Vale a pena?
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Eu e Rafael Ponte, um ativo participante da comunidade e conhecedor de JSF, enumeramos 10 razões que podem ajudar a sua decisão. Elas também valem se você estiver pensando em adotar um framework component based para um novo projeto.
Desempenho
JSF sempre foi considerado um framework com problemas graves de desempenho desde suas primeiras versões (RI 1.0/1.1). No entanto, após o lançamento do JSF1.2 muitos dos problemas de performance foram resolvidos graças ao talentoso time de desenvolvedores da Mojarra (RI). Mas ainda assim, devido a limitações de design na especificação do JSF1.2, o time de desenvolvedores sempre teve dificuldades para escrever código performático. Somente com a especificação do JSF2 é que tornou-se possível escrever código desde o ínicio com performance em mente.
São muitos os pontos de melhoria, mas gostaremos de ressaltar alguns, principalmente no que concerne à evolução/futuro da plataforma. Ficamos muito tempo parados no JSF1.2 e não vimos progresso na especificação. Contudo, parece que o jogo mudou. Alguns itens que ficaram em aberto no JSF2.0, como a falta de integração do @ViewScope com a combinação JSF + CDI, já estão previstos para serem resolvidos no JSF2.2, assim como melhorias no suporte ao HTML5, AJAX e navegação com o Faces Flow e outros itens resolvidos já no JSF2.1.
Mais componentes!
O número de componentes tem crescido a cada dia devido a facilidade de se implementar componentes no JSF2. Os principais conjuntos de componentes (Primefaces, Richfaces, Trinidad e Icefaces) já possuem um excelente suporte a nova especificação e cada um deles possui diferentes sabores de componentes ricos para praticamente todos os tipos de aplicação. Devido a features como Ajax Nativo e Resource Loading estes mesmos conjuntos de componentes tornaram-se compatíveis, o que tem possibilitado integrá-los sem muitas dificuldades em um mesmo projeto - o que era quase impossível com JSF1.2.
Outro ponto interessante é que com o sucesso do JSF2 as empresas mantenedoras tem diminuído o suporte e a implementação de novos componentes JSF1.2, e, provavelmente, em médio prazo será ainda mais raro obter correções e melhorias para esses componentes de forma gratuita.
Adoção do Primefaces 2.x e 3.x
No tópico anterior ressaltamos sobre a variedade de componentes, nesse ousamos afirmar que o Primefaces (2.x/3.x) está tão interessante que seu uso por si só já é um motivo para migrar. Eles sairam na frente do RichFaces como implementação de componentes compatível com JSF 2. Só esse aspecto já seria o suficiente para ter uma adoção maior. Entretanto, o principal motivo foi a qualidade dos componentes. Comparando as demos de ambos constate-se que o primeiro possui uma variedade muito maior de elementos, além de suporte com componentes mobile. Ainda mais, ele usa o ThemeRoller, facilitando a customização de acordo com sua necessidade.
Há muito movimento ao redor do JSF2 e do CDI. Recentemente foi lançada pelo Bauke Scholtz (talvez o developer mais proeminente na plataforma) o OmniFaces, que é uma biblioteca utilitária para consertar vários problemas que ainda não foram melhorados na especificação. Temos também outros projetos mainstream como o Seam3, CDISource e Apache CODI. Há um claro sombreamento de funcionalidades entre os projetos, porém a cooperação dos times está tão grande que todos resolveram juntar forças em um só projeto, o DeltaSpike. O projeto agora é o foco da comunidade, e para comprovar isso, Pete Muir recentemente enviou um email na lista do seam-dev explicando que o projeto está a pleno vapor.
Aqui entra uma questão mais enterprise. Algumas empresas contratam Oracle, JBoss, IBM, justamente pelo suporte que elas oferecem aos seus produtos. Portanto, é importante identificar a data de expiração desses serviços. Uma outra preocupação é com relação a variedade de implementações para a especificação JavaEE. Alguns vendors demoraram a soltar os seus releases compatíveis, mas temos até alguns menos conhecidos que estão certificados, como Apache Geronimo e Caucho Resign. Há também melhorias consideráveis de desempenho no JBoss 7 e GlassFish 3.1.
Custos
É um tópico complicado e possui uma série de variáveis envolvidas mudando para cada empresa. Entretanto, podemos citar alguns pontos relevantes a serem considerados, como se a sua empresa usa JSF 1.2 puro ou acoplado a algum outro framework como o Seam 2.x. Com a primeira opção, a migração é fácil, e a quantidade e qualidade das novas funcionalidades que entraram na especificação compensará todo este trabalho. Em relação a segunda opção, está saindo do forno o Seam 2.3 que possui suporte ao JavaEE6. Entretanto, não sabemos ainda como será essa nova atualização.
Uma opção disponível é a combinação Seam3+JSF2+CDI, e as novas funcionalidades dessa união foram livremente inspiradas no que o Seam 2.x já provia.
Precisamos ainda considerar um outro ponto relevante: o sistema possui testes automatizados? Unidade, Integração e principalmente Sistema? Caso negativo, seus custos podem ser bem mais altos do que você espera, pois descobrirá incompatibilidades e pequenos problemas de maneira inesperada.
