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

Front-end
#21

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…

#22

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.
#23

[quote=victorwss]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![/quote]
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.

#24

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.

#25

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.

#26

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

#27

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?

#28

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!

#29

Fala Lucas tudo bem?

Alguns pontos me chamaram atenção:

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.

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.

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 :smiley:

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.

#30

[quote=raf4ever][quote=FernandoFranzini]
Não sei…oque aponta tecnologia da solução é os requisitos da mesma.
[/quote]
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?[/quote]

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)

#31

[quote=raf4ever][quote=FernandoFranzini]
Não sei…oque aponta tecnologia da solução é os requisitos da mesma.
[/quote]

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?[/quote]
A pergunta não foi para mim, mas vou dar um exemplo: (caso vc não se importe com pessoas que metem o nariz onde não são chamadas hehe)

Enquanto o JSF pode se sair muito bem em aplicações empresariais, não é uma boa idéia para Sites de internet por exemplo (redes sociais, loja virtual, etc) devido a duas características que já foram citadas aqui:

  • Falta de controle sobre o HTML gerado.
    Para Internet, um design inovador e detalhes de usabilidade podem fazer toda a diferença. Usando JSF você tem certas limitações que não permitirão colocar em prática todas as suas idéias.

  • Número de usuários desconhecido.
    Com JSF, o uso da sessão está fora de controle do desenvolvedor (seja por objetos do próprio framework, seja por managed beans que por motivos diversos só funcionam assim). Isso exige um cuidado todo especial com a infra-estrutura, instalando servidores que dêem conta do número de usuários planejado. Como na Internet o número de usuários não é previsível, existem boas chances de o servidor acabar não suportando.

#32

Ola Rafael, como vai, tudo bem?

E se se tornar necessário? Ou será que desenvolvimento de software é tão previsível que posso apontar e falar: “Vou usar esses X componentes visuais dessa biblioteca e me basta”?. Se teus requisitos, em questão de front-end, se adequa aos N componentes de uma biblioteca, tudo bem. É só torcer pro cliente nao pedir alteração ou customização em algum componente.

Sim, é a mesma questao da situação acima. Mas isso não é pior parte do JSF. Isso é um probleminha a mais.

Sim, exatamente é o que quis dizer. Muitos novatos se encantam com “facilidade” de gerar o componente com as tags e levam uma surra posteriormente.

Hoje eu utilizo uma arquitetura que me permite ter várias tecnologias (web) por trás. A minha view é totalmente independente de Servidor. Ela nao é gerada no servidor como JSP, JSF ou PHP. Eu integro minha View de uma forma transparente, principalmente atraves de JSON. Hoje tenho aqui na mesma App módulos em VRaptor /Servlet e outros em Rails (e agora estamos pensando em usar JAX-RS em EJBs também para disponibilizar seviços para view), na mesma App.

Minha View nao conhece o server. Isso me permite ter uma arquitetura mais Restful possível, stateless, desacoplado e muito leve. Hoje o desenvolvimento web em geral estao caminhando para este lado.

Se voce usar JSF, sua View é praticamente 98% dependente de Server, depende dos Managed Beans. Há altíssimo acoplamento. Isso é um dos piores pontos do JSF.

#33

Isso não é tão verdade assim,

  • vc pode parametrizar o provedor de JSF para atuar de forma controlada.
  • vc pode parametrizar seu container para controlar as sessões de forma customizada.
  • vc pode retirar tudo controle de JSF da sessão movendo para o “client”.
#34

[quote]Hoje eu utilizo uma arquitetura que me permite ter várias tecnologias (web) por trás. A minha view é totalmente independente de Servidor. Ela nao é gerada no servidor como JSP, JSF ou PHP. Eu integro minha View de uma forma transparente, principalmente atraves de JSON. Hoje tenho aqui na mesma App módulos em VRaptor /Servlet e outros em Rails (e agora estamos pensando em usar JAX-RS em EJBs também para disponibilizar seviços para view), na mesma App.
Minha View nao conhece o server. Isso me permite ter uma arquitetura mais Restful possível, stateless, desacoplado e muito leve. Hoje o desenvolvimento web em geral estao caminhando para este lado.
Se voce usar JSF, sua View é praticamente 98% dependente de Server, depende dos Managed Beans. Há altíssimo acoplamento. Isso é um dos piores pontos do JSF. [/quote]

Oi Lucas, vc tem razão. Mas o JSF é server side…ou seja, JSF não para ser usado como estilo REST (digo a comunicação da VIEW para o CONTROLLER dentro do MVC). Mas vc tem razão, algumas aplicações hoje tendem a usar essa arquitetura sim.
Diante disso, vc ta usando o framework errado… oque vc esperava? Ligar as ações e os componentes visuais do JSF em um REST? quem sabe não acontece num futuro…mas atualmente JSF não foi estabelecido para essa filosofia.

#35

Nesse ponto eu me baseei mais na minha experiência msm,nunca tive(e não conheço quem teve) necessidade de criação de algum widget que a biblioteca que eu uso (no caso o RichFaces) não forneça.

Quanto a estilizar componentes e mexer em CSS ,esse é o único tradeoff que me incomoda,vc fica refém demais do que a ferramenta gera pra vc.

#36

Isso não é tão verdade assim,

  • vc pode parametrizar o provedor de JSF para atuar de forma controlada.
  • vc pode parametrizar seu container para controlar as sessões de forma customizada.
  • vc pode retirar tudo controle de JSF da sessão movendo para o “client”.[/quote]

Sim, você tem a possibilidade de realizar o setup mais adequado ao seu cliente (e por que não dizer, talvez tenha bastante sucesso nisso). Só que no fim das contas tudo se baseia em “trade-offs”, por exemplo, ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. Tudo isso requer um conhecimento do cenário de utilização, o que não acontece com sites de Internet…

#37

FernandoFranzini interessante 1000 req por minuto.

Vc pode falar mais sobre essa solucao? Que outras praticas usou como cache, pool e etc?

abrassss

#38

[quote=renanreismartins]FernandoFranzini interessante 1000 req por minuto.

Vc pode falar mais sobre essa solucao? Que outras praticas usou como cache, pool e etc?

abrassss[/quote]

Eu disse 1 mil usuarios por minuto e não mil request. Bem diferente…
Detalhes arquiteturais vc pode falar comigo pelo meu email particular…

#39

"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "

desculpa mas não entendi essa parte, vc poderia explicar melhor?

#40

[quote=mhjmhj2002]"ao mandar o estado para o client ganha-se em memória do servidor mas perde-se em volume de dados trafegados. "

desculpa mas não entendi essa parte, vc poderia explicar melhor?[/quote]
Leia - http://www.rponte.com.br/2007/10/14/state_saving_method-server-ou-client/