Taverna /dev/All

JavaServer Faces (JSF) já era?

image

Até bem recentemente JSF era um framework que, para mim, era absolutamente irrelevante. Então iniciamos um projeto de manutenção de legados que me fez repensar profundamente esta minha posição e, como resultado, iniciei a escrita de um novo livro que pretendo lançar ainda este semestre.

E hoje topei com o seguinte post do Fernando Franzini no seu blog (mesmo título deste post) que me obrigou a iniciar esta discussão: https://fernandofranzini.wordpress.com/2019/04/01/jsf-ja-era/

No post ele menciona um outro, de 2014 que critica o radar da ThoughtWorks, vindo do site do Primefaces (não é portanto uma fonte imparcial, mas vale à pena a leitura pela autoridade deles no assunto): https://www.primefaces.org/jsf-is-not-what-youve-been-told-anymore/

Na minha opinião o JSF não tem nada de irrelevante, pelo contrário: oferece um modelo de desenvolvimento para interfaces administrativas corporativas que é sim, muito interessante. Especialmente quando se leva em consideração as bibliotecas de componentes, tais como o próprio PrimeFaces e mesmo outras, que permitem ao desenvolvedor que não tem conhecimentos avançados de frontend implementar formulários bastante complexos com esforço mínimo.

Não há como negar que o framework tem lá seus problemas, mas após ter voltado ao estudo mais aprofundado a seu respeito percebo que na realidade estes surgem de uma má compreensão do seu funcionamento (como sempre).

Então levanto aqui a discussão: o que pensam sobre o JSF hoje? Conseguem ver um futuro para ele? Aonde se encaixa?

1 Curtida

Pra mim, só tem futuro para manutenções de legado.

Trabalhei com páginas dinâmicas em Java, renderizadas no servidor, desde quando somente existia Servlet, depois, JSP e depois JSF.

Somente começaria um projeto do zero utilizando JSF se já tivesse uma equipe GRANDE, TODA equipe não conhecesse alguma coisa de React, Angular ou Vue, e o projeto tivesse de começar há duas semanas.

Porque se tivesse 2 semanas para iniciar o projeto, treinaria a equipe em React, Angular ou Vue.

1 Curtida

Graças a Deus está fora de cogitação. É mais para manter legados. Exige muito esforço para esse “uso correto”, devido seu ciclo de vida megalomanico, espantando desenvolvedores web fora da caixa Java e atraindo só desenvolvedores desktop Java.

Fazer formulários com ASP.NET Core MVC por exemplo é tão ou mais produtivo do que JSF, sendo que mais leve e sem o gesso do component based. Spring MVC não é tão produtivo quanto ao ASP.NET Core, mas seria a tecnologia similar no lado Java para HTML sob controle server side.

Não acredito que já era, minha opinião é que o JSF é uma excelente especificação, principalmente para ser utilizado em softwares que necessitam de muitos componentes. Acho que o início da tecnologia foi muito ruim, isso eu credito uma boa parte aos vários problemas de compatibilidade entre os browsers, e o restante há várias implementações com componentes “problemáticos”. Acredito que quando a SUN criou a especificação pensou em ter um suporte por IDE em WYSIWYG, como implementado no Netbeans 5.5 e o Woodstock para tentar bater com o ASP.Net e Visual Studio, mas manter uma especificação aberta, agradar a todos, gerar uma implementação nova, manter uma IDE etc, acabou atrapalhando. Acho que o JSF começou a se reencontrar quando a Primetek apresentou sua implementação com ciclos mais confiáveis de versões, além de possuir documentação melhor. Também a confluência dos browser ajudou bastante, pois com o HTML 5 foi possível tornar a sintaxe das views, menos intrusivas e mais fáceis para entendimento, não tendo marcações complexas.

A alguns anos eu me deixei levar pela frustração de lidar com um legado que está preso a um JSF de 2007 (1.1), e pensava que a especificação como um todo era passado e que SPA era o futuro, sendo que a especificação não tem culpa da não atualização de um sistema. Comecei a ler mais sobre as abordagens e hoje eu sei que cada ferramenta serve pra determinada tarefa, aquela velha afirmação de que não posso ver o mundo como um prego por que só uso um martelo. Vi isso em sistemas mais novos, onde os custos de desenvolver uma tela com muitos componentes aumentaram com o uso de tecnologias “novas”, onde o build se tornou mais “complexo” e foi necessário mais esforço por conta da pouca maturidade da equipe (e não é a curto prazo).

Pra mim o hoje o JSF é uma ótima tecnologia, mas é preciso conhecer o tradeoff da mesma para aplicar da melhor forma e ser feliz. Não acredito que vá acabar (espero que não), mas essa afirmação depende muito mais da utilização e da orientação dos desenvolvedores.

2 Curtidas

caramba, que aula de história!

O problema não é com o JSF, mas com os CEO’s, CTO’s, Gerentes de Projeto, Gerentes de Produto, e qualquer outro título bacana que existe para definir quem “lacra” as tecnologias, e que acha que aquele sistema em Java 1.X não precisa ser atualizado.
O Projeto JakartaEE (antigo JavaEE) já está trabalhando na JSR 3.0 RC5 para o JSF, o que implica dizer que logo logo sairá uma versão final.
No entanto, enquanto os títulos bacanas não entenderem que já estamos no advendo do Java 17 e eles ainda estão no Java 1.X, obviamente, algumas tecnologias não vão passar de especificações legadas e raramente vão ter a empolgação dos novos desenvolvedores.
Eu estou ansioso para o lançamento da versão 3.0, pois sempre uso a última versão disponível do Java nos meus projetos, atualmente uso a versão 11 para JakartaEE, pois é a versão mais moderna suportada pelo Payara Server; e para Java SE, já uso o Java 15.
A minha vantagem é que eu sou o título bacana da minha empresa, e por isso não tenho o pé preso com o passado, e sempre corro pra o futuro, antes que o passado me envolva a ponto de ser culpado pelo fracasso dos meus projetos!

1 Curtida

excelentes pontos, bem vindo Gilberto!

itexto