Questionamento está em quando se deve utilizar o JSF na contrução de uma aplicação.
Analisando por cima, JSF parece ser útil em softwares que possuem muitos formulários, abas, etc…
Um software web com cara de desktop, neste cenário, vejo que JSF facilita o desenvolvimento unido com o RichFaces.
Porém, em sites que não possuem tantos formulários, não vejo necessidade de se usar JSF, uma vez que ele é mais “pesado” do que outras tecnologias, por exemplo, Struts ou VRaptor.
Vocês seguem esta idéia quando escolhem trabalhar ou não com JSF?
Verdade mesmo? Não existe nenhum critério técnico ao se escolher entre os três frameworks. Tudo se resume ao gosto pessoal dos desenvolvedores que estão realizando o trabalho.
Você levantou a questão dos formulários grandes e tal. Isso será difícil de se realizar em qualquer framework escolhido. O RichFaces pode dar uma “cara padrão” à sua aplicação, mas não vai te livrar do trabalho de escrever os campos de texto um a um. Então… é difícil mesmo.
Mas vamos à minha escolha pessoal: escolheria Struts 2 entre os três escolhidos. Porque não gosto da ideia de componentes do JSF, e porque acho que o VRaptor abusa de DSLs sem oferecer uma vantagem real pra tanto. Veja bem, é minha escolha pessoal, nas coisas que acredito, que estão determinando a escolha; e não na capacidade que os frameworks podem oferecer.
Uma opinião pessoal não é digna de um líder técnico q vai dar ao seu grupo a melhor forma de se trabalhar.
Difere sim de aplicação para aplicação qual framework escolher.
Precisa saber muuito bem quais as vantagens e desvantagens de cada um. Não só por ser cheio de telinhas e abas.
[quote=aluisiodsv]Uma opinião pessoal não é digna de um líder técnico q vai dar ao seu grupo a melhor forma de se trabalhar.
Difere sim de aplicação para aplicação qual framework escolher.
Precisa saber muuito bem quais as vantagens e desvantagens de cada um. Não só por ser cheio de telinhas e abas.[/quote]
Discordo.
No fundo, quando um líder técnico escolhe determinado framework, é sua opinião pessoal que está sendo considerado. Se ele mostrar um relatório detalhando as “razões técnicas” de determinada escolha, pode ter certeza que ele: a) primeiro escolheu o framework e b) manipulou cuidadosamente os números para que seu framework favorito ganhasse.
De fato, cada aplicação é uma realidade diferente. Mas o máximo que nós desenvolvedores podemos fazer, tecnicamente, é excluir as opções improváveis de dar certo (exemplo: fazer um site web em C). Ainda assim, sobrará sempre três ou quatro opções viáveis. A equipe poderia discutir até o dia limite sobre as vantagens e desvantagens de cada um. Porém, cada “vantagem” e cada “desvantagem” esconde folclores, FUDs e preconceitos sobre determinada tecnologia, fazendo com que a escolha final não seja ponderada.
Por ser possível realizar o trabalho usando qualquer uma das opções disponíveis, não vejo nenhum problema o líder técnico chegar e falar: “Eu gosto mais desse.”; ou então: “E aí pessoal, qual vocês gostam mais?”. Isso não é demérito, é mais honesto e pode ser a opção mais produtiva, já que alinha o projeto com aquilo que as pessoas mais gostam.
[quote=aluisiodsv]Uma opinião pessoal não é digna de um líder técnico q vai dar ao seu grupo a melhor forma de se trabalhar.
Difere sim de aplicação para aplicação qual framework escolher.
Precisa saber muuito bem quais as vantagens e desvantagens de cada um. Não só por ser cheio de telinhas e abas.[/quote]
Um pouco utópico isso não? A “melhor solução”…
O que mais tem por ae é “lider técnico” leitor de revistas e blogs, que utilizam soluções “atuais” e mirabolantes para solucionar coisas que muitas vezes são simples, um canhão para matar uma formiga… onde muitas vezes erra-se a formiga e acaba dando um tiro no próprio pé.
Quem nunca trabalhou em um projeto com uma versão ou determinada tecnologia zuada, que se arrastava para solucionar o problema do cliente? Ou com um mix que soluções mirabolantes que foram unidas indevidamente, gerando assim uma arquitetura zuada… ou tabela com relacionamento N X N … bom esta já é outra questão… enfim…
Telinhas e abas não são suficientes para definir o que usar, mas tem um peso na escolha.
E o que vejo é que acaba sendo positivo o JSF + RichFaces facilitar neste cenário, porém, onde não se tem muito disso, um Struts ou VRaptor + JSTL tem mais performance.
Por isto eu questionei sobre este “detalhe” na hora de escolher o que usar.
Já usei muito DWR e sei o como é fazer na mão o que RichFaces faz com um comando… por outro lado, se você não precisa destes “orgasmos tecnológicos” na página, não vejo por que utilizar o RichFaces + JSF.
Para a escolha do framework, uma série de fatores vão influenciar na escolha: experiencia da equipe de desenvolvedores, a complexidade do projeto que será desenvolvida e também o $$$$ para o mesmo + uma série de fatores.
Pelo que o autor do topico comentou, para criação de formulários, abas, você terá o trabalho para desenho das paginas (HTML, CSS), ainda mais se o projeto possui um layout super complexo, cheio dos “biro-biro”.
@Leonardo3001, existem várias diferenças técnicas entre JSF e não JSF (Struts, VRaptor, Spring MVC, etc)
JSF é orientado a componentes, e os outros são orientados a ações… são jeitos muito diferentes de se trabalhar, arquiteturas diferentes, entre outras coisas…
se você vai fazer um website que espera ser indexado por sites de busca vc simplesmente não deve usar JSF, por exemplo
[quote=Lucas Cavalcanti]@Leonardo3001, existem várias diferenças técnicas entre JSF e não JSF (Struts, VRaptor, Spring MVC, etc)
JSF é orientado a componentes, e os outros são orientados a ações… são jeitos muito diferentes de se trabalhar, arquiteturas diferentes, entre outras coisas…
se você vai fazer um website que espera ser indexado por sites de busca vc simplesmente não deve usar JSF, por exemplo[/quote]
Concerteza Lucas, essas questoes de SEO é super importante para determinados projetos.
[quote=renanpto]Para a escolha do framework, uma série de fatores vão influenciar na escolha: experiencia da equipe de desenvolvedores, a complexidade do projeto que será desenvolvida e também o $$$$ para o mesmo + uma série de fatores.
Pelo que o autor do topico comentou, para criação de formulários, abas, você terá o trabalho para desenho das paginas (HTML, CSS), ainda mais se o projeto possui um layout super complexo, cheio dos “biro-biro”.
[quote=renanpto][quote=Lucas Cavalcanti]@Leonardo3001, existem várias diferenças técnicas entre JSF e não JSF (Struts, VRaptor, Spring MVC, etc)
JSF é orientado a componentes, e os outros são orientados a ações… são jeitos muito diferentes de se trabalhar, arquiteturas diferentes, entre outras coisas…
se você vai fazer um website que espera ser indexado por sites de busca vc simplesmente não deve usar JSF, por exemplo[/quote]
Concerteza Lucas, essas questoes de SEO é super importante para determinados projetos.
É o que eu falei.
Orgasmos tecnológicos escolhidos por leitores de revistas.
JSF concerteza não seria uma das tecnologias que eu utilizaria para fazer um site de e-commerce.
[quote=Lucas Cavalcanti]@Leonardo3001, existem várias diferenças técnicas entre JSF e não JSF (Struts, VRaptor, Spring MVC, etc)
JSF é orientado a componentes, e os outros são orientados a ações… são jeitos muito diferentes de se trabalhar, arquiteturas diferentes, entre outras coisas…
se você vai fazer um website que espera ser indexado por sites de busca vc simplesmente não deve usar JSF, por exemplo[/quote]
Lucas,
sim, existem várias diferenças, até mesmo entre os não-JSF. Mas a minha argumentação não era que os frameworks fossem iguais (porque não são mesmo), mas de que todos ajudam, de um jeito ou de outro, a chegar ao mesmo objetivo: construir aplicações web.
Eu havia falado acima de que discutir “vantagens e desvantagens” é improdutivo. Nessas conversas, caem informações desatualizadas, achismos, medos bobos, fanboyismo… e muito pouco sobre argumentos racionais. Talvez, com o site completo no ar, usar JSF não fosse mesmo a melhor opção. Mas e daí? Mesmo uma opção “não-ótima” pode entregar resultados de acordo com a expectativa. Muitas vezes, escolher o que a equipe de desenvolvedores gosta é suficiente.
Outra, dá sim pra fazer páginas indexáveis usando JSF. A versão 2.0 suporta GET, e ainda existem vários plugins para as versões 1.x para acrescentar esse suporte. Pode até ser mais difícil com JSF, mas impossível não é. (Nota: não gosto de JSF).
[quote=jesieltrevisan]
Existem coisas interessantes no VRaptor.
Porém, nunca fiquei sabendo de um projeto “grande” que utilizou ele, entendo os motivos.[/quote]
o que é um projeto grande pra você? o garcia-jj aqui do guj tem um sistema bem grande implementado em VRaptor.
qual seria a desvantagem de usar o VRaptor num projeto grande pra você?
escolher uma tecnologia só por gosto é no mínimo imprudente…
claro que o conhecimento e a afinidade com a tecnologia pesam bastante,
mas existem muitos outros fatores a se levar em consideração…
fazer SEO em JSF é 100x mais difícil que fazer em qqer framework action-based
fazer Interfaces ricas em action-baseds é 10x mais difícil que fazer em JSF
não existe framework X melhor que framework Y,
existe framework X é melhor que framework Y para fazer Z
[quote=Lucas Cavalcanti][quote=jesieltrevisan]
Existem coisas interessantes no VRaptor.
Porém, nunca fiquei sabendo de um projeto “grande” que utilizou ele, entendo os motivos.[/quote]
o que é um projeto grande pra você? o garcia-jj aqui do guj tem um sistema bem grande implementado em VRaptor.
qual seria a desvantagem de usar o VRaptor num projeto grande pra você?[/quote]
Entenda projeto “grande” como ponposo contrato ($$$) para grandes clientes, WallMart, Vale, Itau, Bradesco, UPS, etc…
A desvantagem seria em relação ao suporte que eu digo, onde estes projetos “grandes” focam no que está mais difundido no mercado global, como o Struts, Spring e agora entrando o JSF.
Acontece o mesmo com soluções IBM, BEA, Oracle, etc.
Não tenho uma lista de projetos que usam o VRaptor, mas se você der uma olhada no aqui guj no forum de Frameworks brasileiros, você vai ver a movimentação em torno dele…
não acho que quem desenvolve com o VRaptor tenha problema com suporte (sou desenvolvedor do VRaptor, e eu mesmo resolvo as dúvidas geralmente). Você precisa de suporte quando o que você tá usando é difícil de usar. O Vraptor é bem fácil de usar. Mas se você acha que precisa de um contrato para garantir suporte técnico, realmente não tem o que fazer…
Eu tenho várias aplicações que rodam com Vraptor. O que pesou na escolha foram a facilitade em usar, facilidade em fazer testes unitários já que ele não é intrusivo, convenção reduzindo a quantidade de configurações, performance fantástica em relação ao JSF. Struts em nem pensei por causa da quantidade enorme de configurações necessárias.
Atualmente tenho um sistema de gestão escolar que é o maior, roda com EJB3 remoto + Vraptor3. O sistema possui ~40 usuários que executam ~2 milhões de consultas diárias com picos em alguns horários chegando a 500 mil consultas em 1h (isso fazendo uma média dos logs de vários clientes). O sistema roda em cluster com 32 nós encima de um glassfish. Esse sistema usa o Vraptor 3.1.
Em algumas outras empresas que prestei consultoria tenho aproximadamente 8 projetos rodando em Vraptor 3.1.2 sendo que um deles é para uma empresa de distribuição de energia. O sistema roda encima de um OC4J 10G com dois clusters ativo-passivo e usa EJB3 local junto com o Vraptor.
Outro sistema que está em laboratório é um sistema de pagamentos que envia mensalmente dados de débito automatico para bancos (aqueles arquivos layout Febrabam). Esse atualmente está em testes e o Vraptor atendeu bem porque as máquinas onde ele vai rodar possuem poucos recursos. Então usei nesse caso apenas Vraptor sem EJB. No caso o Vraptor faz todo o controle de JPA, transação, etc.
Em praticamente todos os projetos foram necessárias pequenas customizações, e algumas delas eu enviei a equipe do Vraptor e foram já colocados no core do Vraptor. Algumas outras customizações eu ainda não envie por falta de tempo minha. As customizações foram bem simples, já que o core do Vraptor facilita que você facilmente altere todo o comportamento dele. E isso foi uma das peças chaves pela escolha do framework.
Outra facilidade grande é quanto ao refactoring. Como tudo é Java, se você tem, por exemplo, um forwardTo(MinhaClasse.class).metodo() e você altera ele, o refactoring já faz todas as alterações. No Struts e JSF você precisa alterar as Strings em XML.
Conforme eu for lembrando de mais alguma coisa vou postando aqui.