JSF vs. JSF

Ninguém usa JSF sozinho, como ninguém usa Spring sozinho, como ninguém usa Struts sozinho. E utilizar a premissa que se deva utilizar o JBoss Seam para afirmar que o JSF é ruim, na se sustenta, até por que muitos sistemas são desenvolvidos em JSF sem a utilização do Seam. O erro é acreditar que o JSF, ou qualquer outro framework, deva resolver todos os seus problemas e o mundo de desenvolvimento deva ser um paraíso sem dificuldades. As aplicações estão cada vez mais complexas e mais difíceis de desenvolver, e o natural é que uma solução proposta a anos atras, com um conjunto de problemas daquela época, possa falhar ou acertar em diversos níveis aos problemas atuais. E é diante desses novos desafios que surgem novos frameworks e novas tecnologias, foi assim q surgiu o Spring, o Seam e o próprio JSF, ser contra isso é ser contra a própria evolução da área de tecnologia. Quando existir uma solução perfeita nos todos estaremos desempregados.

Não venho afirmar que JSF é perfeição em termos de framework web, ele possui problemas, desde de concepção, como de evolução, mas esse problemas TODOS possuem.
Talvez a questão do JSF foi seu relativo pioneirismo, pois enfrenta os problemas quem ninguém conhece e deve lidar com as consequências disso. Enfim, afirmar que um framework é somente bom por sua generalidade, é uma analise superficial e desnecessária. São tantas coisas que se deve pensar para se afirmar a competência de um framework, que vai muito alem do aspecto técnico, como sua aceitação do mercado, numero de profissionais que o conhecem, apoio da comunidade, apoio de grandes players, numero de ferramentas, qualidade do suporte disponível se é q existe, dentre diversos outros.

Então, respondendo sua pergunta, não existe modismo na utilização do JSF, ele é um ótimo framework em diversos aspectos, atende bem o que se propôs resolver, possui problemas (principalmente a validação, mas isso é uma visao minha) mas não significa que deva ser descartado ou que quem o utiliza são seguidores da moda incapazes de escolher um framework. A utilização do Seam é um ganho, principalmente no aspecto de transacional, e nao significa que o JSF seja ruim, já que nenhum outro framework web tinha algo parecido, nem o Spring MVC… Ah, e Spring nunca foi uma solução simples e madura…

Att.

Olá.

Comecei a desenvolver em JSF profissionalmente não faz muito tempo, um ano e meio no máximo - antes utilizava Servlets e JSP. Concordo com você que a curva de aprendizado do framework é bem grande, e há conceitos como o ciclo de vida da página JSF que são exclusivos do framework, e não têm muito a ver com o paradigma de desenvolvimento web.

E concordo também que utilizá-lo sozinho não é muito bom. Nunca usei o JBoss Seam, mas eu não inicio mais projetos JSF sem utilizar Facelets e componentes com suporte a Ajax, como o Richfaces que acho excelente. Até aqueles que cuidam da especificação do framework reconheceram isso e incluíram Facelets e suporte nativo a Ajax muito semelhante ao fornecido pelo Ajax4JSF, contido no Richfaces.

Entretanto, depois que transpus esses obstáculos, passei a gostar de usá-lo. Porém preciso utilizar outros frameworks orientados a componentes para fazer uma comparação de facilidade de uso e de produtividade. Agora nessa questão da moda, JSF é igual bebida e cigarro: você não começa a usar sem ser pelos outros.

Bastante interessante os pontos de vista.

Gostaria apenas de acrescentar algumas questões em relação ao dito pelo Hal Jordan:

Concordo que o framework tenha escopos, e não resolva todos os problemas. E por isso não utilizamos um framework sozinho. O meu questionamento sobre o JSF é que ele traz novos problemas que antes não existiam. Ou seja, alguns problemas que o JSF tem que resolver, foram causados por ele mesmo.

O que eu acho que aconteceu nos últimos anos em relação ao desenvolvimento de aplicações web, foi a maior utilização de AJAX e aplicações distribuidas principalmente. Mas isso não muda o problema original. Eu penso que se você tem uma solução genérica, ela se sustenta melhor ao longo dos anos. O caso do Spring por exemplo, eu considero que é um framework que tem uma proposta genérica, visto que desde a versão 1, ele é o mesmo framework, e ainda resolve os problemas propostos. O JSF eu acho que é diferente, mesmo quando ele foi criado, ele tinha problemas, um exemplo é que no inicio nem o botão Atualizar ou Voltar do navegador podiam ser utilizados. Eu vejo isso como uma tentativa de um novo paradigma que não era compatível com o ambiente em que ele deveria ser utilizado. Sim sim, esses problemas foram resolvidos, foi só um exemplo, mas parece que sempre tem um problema que o JSF tem que resolver, e não é porque ele é antigo, eu considero que seja porque o paradigma seja diferente de uma aplicação web.

Eu considero por exemplo o Tapestry nesse caso. O Tapestry era uma framework orientado a componentes assim como o JSF, só que mais maduro e com menos problemas.

Sobre o Spring MVC, considero que ele seja fraco também, mas o funcionamento dele é diferente do JSF. Apesar de que eu ache que o estilo de programação request-response é mais simples do que uma orientação a componentes.

Mas voltemos a discussão original, o JSF, resolve realmente o problema proposto? Ou cria novos problemas e tenta resolve-los?
Ele traz mais problemas, ou mais soluções?

Uma outra coisa que gostaria de perguntar…

No inicio, não tinhamos um framework orientado a componentes, e tinhamos o controle do que acontecia com a requisição. Se utilizarmos um framework como JSF, esse controle fica com o JSF. Vejo que grande parte dos problemas que acontecem com o JSF, são devidos a não sabermos o que realmente acontece por baixo dos panos.

Uma pergunta, é necessário que a parte View de uma aplicação seja orientada a componentes? Será que isso não aumenta a complexidade e com isso o tempo de desenvolvimento?

Se o mesmo investimento que foi feito no JSF, tivesse sido feito em uma solução para agilizar o desenvolvimento request-response (baseado em controllers), não teriamos menos problemas, e uma solução mais estável do que temos hoje com JSF?

rogelgarcia:

Uma outra coisa que gostaria de perguntar…

No inicio, não tinhamos um framework orientado a componentes, e tinhamos o controle do que acontecia com a requisição. Se utilizarmos um framework como JSF, esse controle fica com o JSF. Vejo que grande parte dos problemas que acontecem com o JSF, são devidos a não sabermos o que realmente acontece por baixo dos panos.

O que não sabemos acontecer por debaixo dos panos? Alguma coisa você gostaria de alterar ou ter o comportamento diferente e o JSF não lhe permite? Explique esta colocação com algum exemplo se possível.

Pelo contrário, sinto-me bem mais confortável com component based do que action based. A programação para GUIs utilizam essa abordagem a anos, não vejo mal algum nisso.

Mais uma vez, não sei a qual problema de estabilidade quanto ao JSF (como framework) você se refere. Exemplos?

Olá Alessandro… beleza?

Sobre o por baixo dos panos, é que o controle fica sendo do JSF, então temos que aprender sobre ciclo de vida e funcionamento do JSF, o que não é fácil, e sempre tem algum detalhe que não sabemos. Fazer debug para saber o que acontece também é algo inviável no caso de JSF.
Você tem que conhecer como funciona o JSF por exemplo, para adicionar um campo dinamicamente na página. Não é possível por exemplo, usar um javascript para fazer:

div.innerHTML = '<input type="text" name="campo-dinamico"/>';

Component based é utilizado em GUIs mas a programação é local. Então, não é a mesma coisa trabalhar com component based em GUIs e web.

Sobre a terceira colocação, ‘estável’ foi uma palavra infeliz minha. Eu quis dizer uma solução que traz menos problemas, e menos dificuldade para o desenvolvimento. Em action based por exemplo, você tem o poder para fazer o que quiser do jeito que quiser.

Tem um pessoa com dúvidas como fazer um combo-box nesse outro post http://www.guj.com.br/posts/list/138341.java, veja que tem uma série de detalhes para fazer funcionar. Implementar um Converter, e depois utilizar na tag <f:converter… Esse tipo de problema, foi criado pelo próprio JSF, pela sua natureza componentizada, clico de vida, etc. Isso é uma dúvida das mais comuns de JSF, veja como dá trabalho fazer algo trivial como um combobox. É esse tipo de questionamento que eu levanto…

Se comparasse Spring MVC com Rails, eu concordaria. Mas Spring MVC não é fraco, muito menos perto do coitado do JSF, pelo contrário. Possui muitos conceitos de desacoplamento que faz inveja em muitos frameworks. O mais interessante é que não o vemos aqui no Brasil, porém ele é bem conhecido fora daqui.
Agora, vejo o JSF sempre com 1 passo atrás dos demais. Se pegarmos um Wicket da vida, ai sim, comparar com JSF dá uma dó, e são ambos componentes.

Olá djemacao… eu utilizo o Spring MVC… e considerei ele fraco não no sentido arquitetural…

Mas na camada de visão, JSPs e tal… que tem poucas tags… acaba que não acelera muito o desenvolvimento… nesse ponto.
Falta uma certa produtividade… mas acho que o JSF não tem tanta produtividade assim também não… mesmo por causa dos problemas que acontecem e você trava no desenvolvimento de coisas relativamente simples.

A comparação entre JSF e Spring MVC, eu não considero muito válida pois são arquiteturas diferentes. Não dá pra saber qual está mais a frente. Mas minha opinião pessoal, é que prefiro o Spring MVC ao JSF.

Já vi relatos que o Wicket é melhor também… mas não conheço…

Valew

Trabalhava com spring e agora comecei a trabalhar num projeto utilizando o Seam. O que percebo é que no Spring é muito mais simples fazer as mesmas coisas que faço utilizando JSF… Um ponto positivo do JSF é o resultado final das views utilizando RichFaces, já existem muitos compónentes prontos e as interfaces ficam realmente boas, porém ainda exige muita codificação desnecessária

O JSF é uma merda, desculpe o palavreado, mas é isso o que ele é. Mas antes, adianto duas coisas:

1. Não sou troll, porque quando solto uma declaração como essa, nunca volto ao tópico pra treplicar.
2. Conheço bem JSF, e até respondo a dúvida de alguns aqui no GUJ, coisa que muito fã de Faces não faz.

Bem, pra entender o porque do JSF não prestar, você precisa conhecer a lei da abstração vazada, criada por Joel Spolsky (antes de virar o idiota que é hoje):

Essa frase é uma luva de pelica pra qualquer desenvolvedor metido que fica matutando a solução “elegante”. E se aplica como uma luva no caso do JSF, que pretende criar uma visão de componentes (leia-se: arrasta-e-solta) pra um protocolo que lida com envio e recebimento remoto de documentos. Usando esse framework, sempre haverá o problema de quando precisar criar janelas ou algum tipo de ajax (como o label que vira input), ou qualquer coisa não-trivial.

Aí, é claro, alguém lembra que precisa usar, além do JSF, um outro plugin que resolva situação X. Bom, você só está adiando o vazamento de abstração pra um outro momento. Chegará logo aquele dia em que você precisa fazer algo específico, e o framework não fará direito, nem com a ajuda de nenhum outro plugin.

Bons frameworks MVC não tentam ser abstrações não-triviais em cima do protocolo HTTP, o Rails é um exemplo clássico disso, onde você entende como são geradas as URLs e como serão as páginas html resultantes. Frameworks bons são o Spring MVC (quem acha ruim, só o conhece numa versão antiga), e o VRaptor do pessoal da Caelum. E quem prefere (não sei porquê) os frameworks orientados a componente, uma excelente pedida é o Wicket, que não esconde noções como form e evento de submit.

Concordo, no JSF sempre tem uma nova tag ou uma anotação (agora com o Seam) para tratar determinado caso especifico. Por isso o pessoal fala que tem mil opções, cada uma na verdade é para tratar um caso diferente.

Por isso sempre teve o tal: espere até a versão 1.2, espere até a versão 2… e assim vai…

Leonardo3001, achei bastante interessante seu post, e também o artigo que você passou. Já conhecia sua opinião sobre o JSF a partir de outros posts seus, mas foi a primeira vez que vi o porquê.

Gostaria de perguntar duas coisas a você:

1. Pode dar alguns exemplos de vazamento da abstração no JSF? Os serviços disponibilizados pela classe ExternalContext seria um deles?
2. Por que você não prefere frameworks component-based, de um modo geral?

Leonardo3001:

O JSF é uma merda, desculpe o palavreado, mas é isso o que ele é. Mas antes, adianto duas coisas:

1. Não sou troll, porque quando solto uma declaração como essa, nunca volto ao tópico pra treplicar.
2. Conheço bem JSF, e até respondo a dúvida de alguns aqui no GUJ, coisa que muito fã de Faces não faz.

Bem, pra entender o porque do JSF não prestar, você precisa conhecer a lei da abstração vazada, criada por Joel Spolsky (antes de virar o idiota que é hoje):

Essa frase é uma luva de pelica pra qualquer desenvolvedor metido que fica matutando a solução “elegante”. E se aplica como uma luva no caso do JSF, que pretende criar uma visão de componentes (leia-se: arrasta-e-solta) pra um protocolo que lida com envio e recebimento remoto de documentos. Usando esse framework, sempre haverá o problema de quando precisar criar janelas ou algum tipo de ajax (como o label que vira input), ou qualquer coisa não-trivial.

Aí, é claro, alguém lembra que precisa usar, além do JSF, um outro plugin que resolva situação X. Bom, você só está adiando o vazamento de abstração pra um outro momento. Chegará logo aquele dia em que você precisa fazer algo específico, e o framework não fará direito, nem com a ajuda de nenhum outro plugin.

Bons frameworks MVC não tentam ser abstrações não-triviais em cima do protocolo HTTP, o Rails é um exemplo clássico disso, onde você entende como são geradas as URLs e como serão as páginas html resultantes. Frameworks bons são o Spring MVC (quem acha ruim, só o conhece numa versão antiga), e o VRaptor do pessoal da Caelum. E quem prefere (não sei porquê) os frameworks orientados a componente, uma excelente pedida é o Wicket, que não esconde noções como form e evento de submit.

Leonardo, entendo seu posicionamento mas não acredito ser verdade para toda e qualquer situação. Se for falar em preciosíssimo em abstração, então todos deveríamos utilizar apenas Servlets. Todo framework especializa APIs para abstrair interações entre desenvolvedores e a tecnologia subjacente, definir se algo é trivial ou não, pode ser um parâmetro um tanto quanto particular.

Você pode optar por utilizar um determinado framework em um projeto de acordo com as especificações deste, e um outro para demais projetos com caracterísitcas diferentes.
Nos projetos JBoss por exemplo, a interface para o novo jBPM Console é baseada em GWT, assim como no Guvnor(Business rules management system). Ambos projetos possuem pouquíssimas páginas, mas MUITO ricas, com vários estados que se resolvem via Ajax (como o GMail, por exemplo). Em sistemas maiores, como o projeto JOPR (plataforma de monitoramento de servidores), a tecnologia é JSF, tendo em vista que o foco são formulários, tabelas e menus… típico da maioria de sistemas convencionais. As vantagens de usar JSF foi possuir todos os componentes para o cenários prontos, como menus, estrutura de árvores, ajax de campos e bind para geração de gráficos sem grandes esforços.

Ja trabalhei em projetos, que acredite, a melhor solução ainda agora foi Struts 1.x. A equipe precisava fazer um sistema rapidamente, com poucas páginas, todos da equipe dominavam apenas Struts por estarem a muito tempo com projetos efetivos com estes… eu iria sugerir aprender um novo framework? Não, para o prazo e para o projeto a melhor escolha é o Struts, com certeza.

Sou cético quando se refere ao “melhor framework”. Isso deve levar em consideração projeto, equipe e prazos. Sem isso, não acho sensato qualquer avaliação mais profunda.