[Conclusão Resolvida]Por que as pessoa não indicam JSF e falam que é u LIXO?

Debugger Membro desde: 20/05/2011 10:03:10 Mensagens: 51 Offline

O único problema do JSF é que ele tem uma curva de aprendizado um pouco mais complexa e muitas pessoas desistem de "bater a cabeça" com ele muito rápido, eu particularmente já apanhei muito, mas depois de algumas horas de estudo hoje desenvolvo bem nele, acho uma ótima tecnologia.

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

@FernandoFranzini, se sua aplicação suporta várias pancadas, nao é mérito somente do JSF, e o Container JEE? Boas Praticas? Os recursos do JEE? A infra? acho que JSF é o que menos influencia ai.

Justamente....

This message was edited 1 time. Last update was at 05/01/2012 07:10:25

eu desenvolvo com JSF 2.0 + Primefaces 3.0 + Hibernate, acho muito legal e facil de usar, uso o JSF 2 por conta do primefaces que é uma ótima biblioteca de componentes.

P/S: estou aprendendo Grails e achei bem legal, VRaptor achei um saco para configurar (Bibligoteca X+Y+Z+++++) quase nunca eu acertava porém é um framework muito bom !

lucasmurata wrote:Posso citar vários motivos do porque o JSF ser um lixo e ser fail. Motivos técnicos, pragmático, comunitario e pessoal.

Primeiro gostaria de salientar, antes que digam que nao conheço o framework tecnicamete, tenho sim experiencia com JSF 2. Estudei livro e tutoriais, desenvolvi um sistema do zero (que inclusive esta rodando em produção com sucesso e estamos migrando para VRaptor). Usei JSF 2 mais de 1 ano. Entao não é de repente que eu e outros desenvolvedores Java chegamos a esta conclusao do JSF ser ruim. São muitos os desenvolvedores Java com esta visão.

Posso citar aqui alguns motivos rapidamente para que o meu post nao fique grande:

1 - Dependecia excessiva de biblioteca de terceiros. Tente desenvolver voce mesmo seus componentes sem usar Prime, Open ou Richfaces. Para isso voce precisa entender o ciclo de vida de uma requisicao em JSF, e criar voce mesmo seus componentes em cima desse ciclo que nao é nada elegante. Ah, faz assim, cria um componente que renderiza rapido no browser e que trabalhe com requisicoes GET, PUT ou DELETE. Boa sorte.

2 - Voce ja lidou com um usuario de sistema? Voce esta usando seu componente pronto em Primefaces. Seu cliente pede pra voce mudar uma coisa no seu Datatable. Boa sorte com as gambiarras. Ou faz o seguinte: espere por uma atualizacao do Rich ou Primefaces que demoram eternidade para ver se vem com a mudanca.

3 - Impressao que da é que JSF nao foi desenhado para WEB. HTTP? REST? HTML, CSS e JS? XHTML do JSF 2 é um xml sem flexibilidade. Tente ter um controle fino de Javascript, de Ajax e de CSS. Tente estilizar seus componentes. Voce verá estrelinhas rodando na cabeça.

4 - Mistura entre cliente-side e server-side, acho que este é o seu pior ponto. Nao há transparencia. Voce chama componete da View no seu ManagedBean, e chama ManagedBean no seu View. Atualmente eu utilizo uma arquitetura que me permite independecia entre Client e Server usando VRaptor e Rails. O desenvolvimento Web tende a isso.

5 - Muita imaturidade para um projeto que esta ai desde 2003. Sao quase 9 anos. Nao vejo amadurecimento. Na web a evolucao é muito rápida. Menos com JSFail que é um framework mal acabado. 9 anos pra sair da versao 1 pra 2?

6 - Ele é Statefull e depende muito de sessions por ser component-based.

7 - Ele é um atrativo para os novatos e para os que nao gostam de estudar. "Olha! É tao simples. Basta esta tag e aparece esse componente!!" e caem na armadilha.

8 - Pesquise no proprio GUJ quantos e quantos topicos sobre, por exemplo, atualizar uma combobox com outro, combobox aninhados, atualizar datatable, etc, em JSF. Sao muitos desenvolvedores batendo a cabeça numa coisa que com jQuery + Ajax faria rapidamente.

9 - Sucetivel a POG, mesmo voce seguindo boas praticas no backend.

10 - Quase impossivel de integrar com outras tecnologias. Uma vez JSF, seu projeto sera JSF.

E posso citar tambem outros motivos.

Olha aqui uma lista de grandes figuras e desenvovedores Java criticando JSF (citacoes de 2004 a 2011): http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ (JSF Sucks). Tem inclusive o video do James Gosling, pai do Java dizendo: "I hate JSF with a passion" - Eu odeio JSF com paixao. Isso pode te ajudar a se definir tecnicamente o que é mais importante.

Ponto positivo do JSF:
1 - Fazer CRUD. Ok, voce vai viver de CRUD?

Hoje tem tanta coisa legal pra aprender e usar nos seus projetos. Largue o JSF, livre-se enquanto é tempo. Estude frameworks Restful como Vraptor, Rails, Grails, Play, aprenda Javascript (de verdade), para view use Extjs, jQuery UI, YUI, Dojo toolkit. Faça o que quiser. Mas nao contribua para que este cancer chamado JSFail se alastre na comunidade Java.

bom...descordo da maioria, alguns dos seus argumentos por outro lado considero válidos mas vamos la:

1 - Ué não é uma coisa completamente normal ter bibliotecas de terceiros quando desenvolvemos na plataforma java? Vai me dizer que nunca reparou na quantidade que o hibernate por exemplo usa? Quanto a trabalhar com requisições put, delete, etc, se você precisa fazer isso, você pode integrar o jsf com spring e usar o controller do spring para isso, me parece uma excelente dupla mesmo que você não precise disso.

2 - Eu não tive estes problemas... com um simples reRender e o código de como tem que ficar nesse caso você resolve isso (e não é nenhuma gambiarra).

3 - Você tem como chamar funções js suas no que você precisa na imensa maioria dos casos, normalmente em algum evento de algum componente, até hoje no que eu precisei (normalmente chamar em algum evento como onblur da vida) nunca tive problema. Quanto a css os componentes tem um styleClass, isso normalmente resolve meu problema (nem preciso tanto por que normalmente deixo o estilo pego do skin do rich faces...). Casos onde isso não atende são bem raros (normalmente é por que o programador "quer" fazer com js, não por que ele "precisa").

4 - Pera ai, você tem como chamar componente do managed bean na view e da view no managed bean e não ha transparência? A unica coisa que vejo de ruim ai é um possível mau uso, um uso excessivo de binding. Tem casos onde considero uma boa por exemplo para preencher menus, mas acho que tem que ser o minimo usado possível por uma questão de camadas.

5 - Eu concordo quanto a lerdeza neste ponto, poucas versões novas saem... mas isso não muda o fato de que jsf 2 hoje é um framework recente e bem aceito pela comunidade, bastante produtivo.

6 - De uma forma geral ele é statefull, o comum com ele é que muitos managed beans fiquem com escopo de sessão e muitos dados dados fiquem carregados, mas não é dificil trabalhar com estes beans em escopo de requisição e passando parâmetros via get por exemplo. Para ser sincero eu acho que certas coisas vale bem mais a pena ser statefull mesmo por que não pesam na memória, podem ser aproveitadas por vários dos muitos usuários logados (configurações relacionadas a perfil de acesso por exemplo) e assim evitam novos acessos a base de dados, além de ser mais fácil programar assim, o problema é quando o individuo deixa tudo statefull, mas isso não é problema do framework, mas sim de quem o usa.

7 - Ele é mesmo um atrativo para novatos por que esse negocio de "só por a tag" faz parecer que é simples programar com jsf, e na verdade é simples mesmo, mas programar "bem" envolve conceitos que estes novatos normalmente não conhecem ou ao menos não na prática. Ai que entra o problema mas novatos vão fazer "novatisses" com qualquer framework...

8 - Cara isso de preencher um combobox depois que o usuário selecionar uma opção no outro usando jsf (com algum outro add como o rich ou o prime) é uma coisa simples, com o rich por exemplo é só colocar no primeiro um a4j:support no evento onblur chamando o método que preenche os itens do segundo combo e colocando no reRender um painel de onde esteja o segundo para atualizar. Se tem um monte de tópico perguntando sobre isso é por que tem um monte de gente que não conhece abrindo tópico perguntando, mas é simples sim.

9 - Qualquer framework é suscetível a pog. Nunca duvide da criatividade de certos individuos e como eu disse novatos vão fazer "novatisses" com qualquer framework...

10 - Integrar com outras tecnologias tipo o que por exemplo?

quanto ao ponto positivo que você deu, bom acho que não é novidade pra ninguém que você foi meio tendencioso quanto a isso.

JavaTeenager Membro desde: 15/07/2011 14:36:43 Mensagens: 158 Offline

Polverini wrote:uso o JSF 2 por conta do primefaces

hum...bom saber. Tira o primefaces, crie seus proprios componentes e taglibs que tenha boa performance e com suporte a arquitetura Restful e que seja stateless, vai querer continuar a usa-lo? Esse é um ponto que citei acima como uma das coisas que torna JSF um lixo.

Quanto ao VRaptor, acho que voce se equivocou. Nunca precisei configura-lo. As bibliotecas adicionais são as mesmas que voce colocaria em qualquer outro framework. No site do VRaptor voce pode baixar o blank-project que ja esta configurado e pronto para o uso.

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Fala Lucas !! Preciso falar com vc mas perdi seu email...vc pode enviar um e-mail para mim? To aguardando....

Algumas coisas q vc falou no seu texto existe, outras podem ser contornados e outras eu acho que vc pode estar equivocado em algumas conclusões. Eu não vou entrar em "flames" contradizendo seu texto..prefiro ficar aparte disso. Por exemplo, a partir do momento que vc configura o estado da arvore do JSF para a "client", o JSF se torna STATELESS. E por ai vai.
JSF é um framework objetivado para um fim. Usa-lo para um fim diferente, realmente terá que contornar situações. Tudo na vida é assim...Não existe um framework MVC lindo maravilhoso bala de prata..Existe? kkkkk Ja existe gente levantando issues destes frameworks que vc indicou ai...e avida é assim..a coisa gira.
Quando vc idealiza uma solução, vc precisa buscar no mercado ferramentas/frameworks para te ajudar...mas mesmo assim vc terá issues para resolver....
Eu na verdade fico feliz por ter toda essa gama de opções para minha escolha....

GUJ Ranger Membro desde: 11/05/2007 19:46:22 Mensagens: 901 Offline

Resumindo bastante os dois lados:

BOM:
O JSF traz uma produtividade incrível na criação de UI, fazendo automaticamente coisas que dariam um trabalho imenso.

RUIM:
1) JSF sozinho não é nada, as vantagens só são conseguidas utilizando-se uma boa biblioteca de componentes. A criação de componentes personalizados é praticamente uma lenda urbana, tamanha sua complexidade...
2) Para obter a produtividade que ele oferece, é preciso aceitar suas condições (é uma espécie de Pacto hehe). Aí perde-se o controle sobre HTML/javascript gerados (quem nunca teve que convencer o cliente a desistir de uma idéia porque o JSF não permitiu implementar?) e também sobre URLs, métodos HTTP (ele faz POST para quase tudo) e sobre os dados armazenados em sessão.

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

victorwss wrote:O principal problema do JSF é que ele gerencia a criação da HTML final e também o formato das URLs. Em aplicações RIA para web 2.0, aonde você tem que mexer diretamente na estrutura DOM da página gerada e se preocupar com o formato e estrutura das suas URLs, você acaba se ferrando por causa do JSF.

Para demonstrar isso dê uma olhada na HTML gerada pelo JSF e você vai ver muita coisa gerada automaticamente. Então tente implementar no seu template JSF, sem usar nenhuma gambiarra escrota, algum efeito na página via javascript (com ou sem jQuery). Provavelmente você vai quebrar a cara. Se conseguir, tente então baixar algum conteúdo por ajax e alterar a estrutura da página dinamicamente com base na resposta do ajax. Vai quebrar a cara de novo. Tente personalizar algum detalhe do CSS, quebrou a cara de novo!

É aí que está o problema do JSF: Uma vez que ele toma para si a tarefa de gerenciar a criação da HTML, você acaba perdendo a liberdade de personalizá-la, sendo obrigado a seguir as regras impostas pelo JSF, e para alguns tipos de aplicações, estas regras impostas não são aceitáveis.

Uma possível saída para esse problema é você criar os seus componentes JSF personalizados para fazer isso, mas aí você acaba perdendo a produtividade prometida pelo JSF e tem ainda a tarefa extra de ajustar os seus componentes as necessidades do JSF, uma tarefa árdua. Assim acaba sendo mais simples, mais fácil e mais rápido fazer tudo com javascript e HTML você mesmo, pois o JSF vai acabar se tornando um elefante branco inútil no sistema.

Para sistemas que são compostos basicamente de telas de cadastro, consultas e relatórios CRUD, você pode usar o JSF e seja feliz. No entanto, você também pode usar uma grande gama de outras ferramentas (ex: REST + JSP + jQuery) e também ser do mesmo jeito.

No entanto se você quer fazer um site cheio de animações e efeitos, carregamento dinâmico de dados em tempo real, etc, o JSF não é uma boa ideia.

Talvez você decida que o que você precisa é simples o suficiente para que o JSF dê conta e você vai produzir muito bem e mais rápido do que se estivesse usando alguma outra coisa. Até que em uma bela sexta-feira 13 de lua cheia, o cliente chega com um requisito de fazer a sua tela de consulta de situação de venda de produtos que é completamente estática, ter que monitorar em tempo real a atividade do fluxo de provisionamento de venda de produtos, para que o operador não precise ficar dando F5 a toda hora e possa agir imediatamente sem estourar o prazo máximo de 30 minutos para a conclusão da venda. Isso daí você pode fazer com Ajax e jQuery, mas... OH NO!

Pois é...não seria o objetivo do JSF é realmente esse??? kkkkk
Mais uma vez, se a sua solução requer controle de baixo nível do geração do html,js, css, bla bla bla, não use um framework para isso. Faça na unha ou use outros produtos de mais baixo nível de controle (como esse que vc citou). Agora apontar isso como ponto negativo é incoerente, uma vez que isso é requisito do seu cenário.

GUJ Expert Membro desde: 22/01/2007 22:00:53 Mensagens: 4200 Offline

Acho engraçado que vejo milhares de pessoas reclamando do Ciclo de Vida do JSF mas nunca pararam para aprender/estudar.

Para aprender OO o cara estuda, agora para aprender sobre JSF quer um texto de 3 linhas explicando tudo?

Se tudo em Java fosse simples e objetivo...

Quantas vezes já vi pessoas usando actionListener quando elas precisam de um action?
As vezes dá vontade de perguntar para as pessoas que abrem um post sofre JSF: "vc a diferença entre action e actionListener?", "Vc sabe oq acontece se um método de uma action retornar um null?"

Serinho, não entendo esse povo que quer que a solução caia no colo deles. E ao ver que vai precisar estudar para entender alguma coisa começa a reclamar... pfff.

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

Queridos amigos, segue minha opinião como arquiteto....

Se vc concluiu que um framework não é adequado para seu cenário, não quer dizer que ele não presta, ou que é um lixo, ,flames ,flames... Não é positivo para nenhum profissional se posicionar dessa forma. Simplesmente não é o adequado para ser adotado na solução A. Mas num outro momento, pode ser perfeito para ao cenário da solução B. Não se torne um profissional fanático contra ou nem a favor. Entenda um framework, para que serve, como funciona, quem ta usando, resultados desse uso, pros e contras e use para seu próprio beneficio.

Java Ninja Membro desde: 19/09/2011 05:06:59 Mensagens: 266 Offline

olha pessoal eu descordo um pouco se dizem que o JSF é ma droga

eu sou um cara bem doido e uso o minimo do JSF puro, mas sabe o que ele tem de melhor e muitos não observam
é que com ele você pode jogar qualquer ou pelo menos a maioria das tecnologias nele
eu consigo juntar tudo que é tranqueira no JSF seja javascript, CSS , prime, my, rich, flash, o que tiver de interessante eu coloco tudo e vira uma zona que só eu entendo mas é divertido além disso estou criando meu próprios componentes
sugiro a vocês que leiam
Pro JSF e Ajax
construindo componentes ricos para a Internet

uma coisa que eu percebo, não quero ofender ninguém, é que o pessoal está mal acostumado e que querem coisas rápidas
sei que o mercado exige, mas eu tomo muito cuidado quando são rápidas de mais já que pode vir problemas mais tarde que vai saber onde é o erro

a unica coisa que eu não gostei é que levei umas duas semanas para aprender usar o JSF
ou seja tem muito tempo para aprender a brincar com o JSF

FernandoFranzini wrote:
Não sei.....oque aponta tecnologia da solução é os requisitos da mesma.

Fernando,vc tocou num ponto importante.

Em que situação vc,que é um cara experiente com JSF em sistemas de grande porte,deixaria JSF de lado?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Se vc comparar JSF e Struts 1 por exemplo, tudo que vc faz em JSF vc pode fazer com Struts 1, mas o contrário não é verdade. O mesmo se aplica a Play, Rails, VRaptor e outros contra JSF.

Pra mim nao existe este papo de framework-web certo para cada tipo de problema. Framework web é gosto pessoal, ou tu sente prazer programando nele ou nao.

Desde que seu sistema seja um backend (apenas telas administrativas) ainda acho aceitavel alguem gostar e escolher JSF. Agora se vc chegar no nivel de escolher JSF para desenvolver front-ends, o JSF nao tem culpa, o problema é vc quem é muito ruim!

Simples assim!

Fala Lucas tudo bem?

Alguns pontos me chamaram atenção:

1 - Dependecia excessiva de biblioteca de terceiros. Tente desenvolver voce mesmo seus componentes sem usar Prime, Open ou Richfaces. Para isso voce precisa entender o ciclo de vida de uma requisicao em JSF, e criar voce mesmo seus componentes em cima desse ciclo que nao é nada elegante. Ah, faz assim, cria um componente que renderiza rapido no browser e que trabalhe com requisicoes GET, PUT ou DELETE. Boa sorte.

Pra que eu iria querer reiventar a roda criando meus próprios componentes se já tenho a disposição toda essa gama de bibliotecas que vc mesmo citou?A necessidade de criação de componentes me parece dispensável na maior parte dos casos.

3 - Impressao que da é que JSF nao foi desenhado para WEB. HTTP? REST? HTML, CSS e JS? XHTML do JSF 2 é um xml sem flexibilidade. Tente ter um controle fino de Javascript, de Ajax e de CSS. Tente estilizar seus componentes. Voce verá estrelinhas rodando na cabeça.

Quanto ao 'controle fino' eu concordo com vc,a tonelada de javascript/css que é gerada por baixo dos panos torna praticamente inviável qualquer customização mais detalhada.

7 - Ele é um atrativo para os novatos e para os que nao gostam de estudar. "Olha! É tao simples. Basta esta tag e aparece esse componente!!" e caem na armadilha.

Como assim "para os que nao gostam de estudar"?Experimenta entrar num projeto sem conhecer pelo menos razoavelmente o funcionamento da tua biblioteca de componentes e vc vai ver a surra que vc leva

10 - Quase impossivel de integrar com outras tecnologias. Uma vez JSF, seu projeto sera JSF.

Aqui me pareceu uma predisposição a falar mal.Meus projetos utilizam Spring,JPA+Hibernate,Webservices p/autenticação;Uma vez Rails,meu projeto não será sempre Rails?Ou então eu não entendi direito o que vc quis dizer com 'outras tecnologias'

Um abraço.

GUJ Master Membro desde: 24/04/2009 12:58:16 Mensagens: 1541 Offline

raf4ever wrote:

FernandoFranzini wrote:
Não sei.....oque aponta tecnologia da solução é os requisitos da mesma.

Fernando,vc tocou num ponto importante.
Em que situação vc,que é um cara experiente com JSF em sistemas de grande porte, deixaria JSF de lado?

Eu não em acho muito experiente(mas um dia chego la kkkk) e tb acho até hoje nunca fiz nada de GRANDE PORTE (talvez tenhamos parâmetros diferentes de coisas de "grande porte", mas ok...).
Muitas razões, por exemplo, se vc for desenvolver uma solução interna de uma corporação que vc tenha controle das workstations e navegadores que usaram o sistema. Vc pode optar por FLEX como camada de apresentação ou inves do JSF. Flex é realmente super lindo e vc consegue com menos tempo interfaces gráficas com gráficos maravilhosos conversando com seu back-end java. E por ai vai...
Como eu falei, tudo depende aonde vc quer chegar....ou seja requisitos.
Entretanto pode haver cenários no qual múltiplos frameworks concorrente podem ser usados intercambialmente. Ou seja, tanto A ou B ou C pode ser usado que tb chegara no mesmo resultado. Para esses casos vc pode optar pelo gosto pessoal, aquele que a equipe ja saiba ou aquele que a equipe deseja aprender a usar (sem alterar a data de entrega é claro kkkkk)

Notícias, artigos e o maior fórum brasileiro sobre Java