Amigos,
Todos as pessoas que pergunto sobre o que eles acham do JSF ele sempre respondem que é um LIXO.
Então decidi criar um Tópico para deixarem as opiniões sobre:
Devo usar o JSF no desenvolvimento WEB?
Se não o que você sugere para uso?
Na realidade gostaria de saber onde investir para obter mais conhecimentos no desenvolvimento WEB, qual a forma mais segura, a menos complexa e etc…
Eu sempre indiquei. [=
Lógico que tem seus problemas como qualquer outra tecnologia web, mas eu o acho bem flexível. Gosto pacas.
a resposta para a a pegunta do tópico é curta e direta: dizem isso por que são fanáticas. Simples assim.
Tem seus pontos fracos, é um pouco mais lento do que vários outros frameworks mas a diferença é minima, você ao desenvolver com este framework tem um pouco menos de controle da parte javascript por exemplo mas a idéia do framework é justamente essa, o desenvolvedor não mecher com isso e focar na regra de negócio. A maioria dos frameworks que não tem estes problemas também não são tão produtivos quanto JSF para se desenvolver… você perde de um lado mas ganha do outro, então escolhe o que lhe valer mais a pena de acordo com os requisitos do projeto. Simples assim.
Cara eu já trabalhei com diversos frameworks do mercado, e os que me chamaram mais atenção foram o wicket e o JSF 2.0, mais com o wicket tinha que criar a interface toda na mão podendo usar componentes do jquery, mais comecei a usar o JSF 2.0 com primefaces e me apaixonei e hoje indico para todos que me pergunto, claro que tudo deve ser avaliado de acordo com a necessidade antes de montar uma arquitetura, mais vai que vc aprenderá muito com ele. Talvés alguém passou pelo JSF 1.3 e conserteza não gostou mais o 2 ta matando…
Aprenda os fundamentos básicos de web JEE…servlet e JSP.
kkkk isso não existe!!! Construir aplicações web hoje é uma atividade complexa, requerendo dos responsáveis uma serie de conhecimentos… Se vc é daqueles desenvolvedores RAD “desktopzeros” dos anos 90 pode se preparar para a borrachada…
Minha maior aplicação web hoje conta com 10 mil usuários habilitando com a media de 1000 sessões por minuto em JSF. Ambiente de produção = 1 Linux com 2GB + tomat e SQLServer.
Que lixo em??? kkkkkkkkkk
Não sei…oque aponta tecnologia da solução é os requisitos da mesma.
Agora que vc pode usar…sim.
Já vi muita gente falando por aí que JSF era ruim. Eu até já fis parte delas Oo. Na verdade quando comecei a aprender frameworks MVC, meu primeiro framework foi JSF e realmente eu não tinha gostado. Eu achava chato pra caramba ter que aprender todos os componentes html de novo para seguir os padrões do jsf, que na minha opinião, realmente não é muito bom sozinho. Então depois de estar desenvolvendo a algum tempo em VRaptor + Hibernate + Spring, tive a curiosidade(esses dias mesmo) de ver um tal de primefaces que li em alguns sites. Depois de entrar nesse site: http://www.primefaces.org/showcase-labs/ui/home.jsf e ver como é simples fazer muita coisa que com jquery + css + html é complicadíssimo, eu mudei de idéia. Hoje estou fazendo uma aplicação em (JSF + Primefaces) + (Hibernate + Spring) e estou gostando bastante. Mas quem deve optar é você mesmo. De uma olhada nesse site do primefaces e veja como é simples usar coisas que com html + jquery + css são muito difíceis.
Utilize frameworks como VRaptor, Play ou Rails. Abuse da arquitetura Restful. Estude muito e abuse de Javascript, ExtJS, jQuery. Abuse dos componentes JEE6 como JPA e EJB, Jax-RS. Mas pelo amor do Ser Superior no qual voce acredita, não use JSF-lixo.
Eu gosto e defendo muito as especificações. Gosto de EJB, JPA, Servlets, Jax-WS e RS. Mas JSFail não.
@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.
Repito, utilize frameworks com arquitetura Restful e SOA-ready como Vraptor, Rails, Play, Servlet, abuse do JS, Extjs, jQuery, e por favor, ajude para que JSFail nao cresça na comunidade Java, deixando de usa-lo.
[quote=lucasmurata]Utilize frameworks como VRaptor, Play ou Rails. Abuse da arquitetura Restful. Estude muito e abuse de Javascript, ExtJS, jQuery. Abuse dos componentes JEE6 como JPA e EJB, Jax-RS. Mas pelo amor do Ser Superior no qual voce acredita, não use JSF-lixo.
Eu gosto e defendo muito as especificações. Gosto de EJB, JPA, Servlets, Jax-WS e RS. Mas JSFail não.
@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.
Repito, utilize frameworks com arquitetura Restful e SOA-ready como Vraptor, Rails, Play, Servlet, abuse do JS, Extjs, jQuery, e por favor, ajude para que JSFail nao cresça na comunidade Java, deixando de usa-lo.
[/quote]
Vc poderia explicar melhor pq o JSF é lixo?
Obrigado amigos pelas respostas, eu tambem estou usando em um sistema que estou criando JSF + PrimeFaces + Hibernate 3 + Spring Security e não estou me arrependendo só queria entender por que JSF é um lixo.
Pode responder isso lucasmurata?
Pois realmente a versão 1.2 do JSF era horrivel, mas a 2.0 parece estar muito estável e bem bacana.
[quote=alltairr]Obrigado amigos pelas respostas, eu tambem estou usando em um sistema que estou criando JSF + PrimeFaces + Hibernate 3 + Spring Security e não estou me arrependendo só queria entender por que JSF é um lixo.
Pode responder isso lucasmurata?
Pois realmente a versão 1.2 do JSF era horrivel, mas a 2.0 parece estar muito estável e bem bacana.
[/quote]
Concordo. Também não tenho grandes experiências com JSF, mas até agora estou trabalhando muito bem com Hiberante + Spring + (JSF + Primefaces). E outra: pra que abusar de jQuery, js, ajax, e todas essas outras coisas sendo que com primefaces + JSF você consegue a mesma coisa com muito mais facilidade e praticidade?? Eu não acho muito certo comparar o JSF com o VRaptor por exemplo por que além de fazerem quase o mesmo trabalho, eles fazem de formas diferente. Eu achei o JSF com Primefaces muito mais produtivo em relação à View e no controller achei em termos de produtividade, igual ao vraptor ou melhor. Ele realmente não é muito simples mas é muito bom.
Eu nao trabelhei com JSF 2.0, nem primefaces, entao o que eu digo eh sobre JSF 1 e richfaces.
Atende de maneira pratica 90% das suas necessidades. Mas se voce precisa qualquer coisa diferente, um javascript, ou uma chamada AJAX que nao tenha que passar pelo ciclo de vida dele voce ta f…
Customizar um componente entao era um parto.
Tem habito tenebroso de falhar silenciosamente. (Ah, voce que nao soube configurar/usar) Eh, tem isso tambem, o ciclo de vida nao eh nenhum pouco intuitivo.
Gera um html terrivel, aplicar css nele eh um saco.
O famoso e maravilhoso sistema de binding de componentes dele nunca funcionou direito (pelo menos eu nunca consegui fazer funcionar direito, olha eu de novo nao sabendo configurar, lembrando que tenho pelo menos uns quatro livros sobre ele aqui em casa, ja li todos e mesmo assim ele vivia me surpreendendo com erros silenciosos inesperados).
Pessoalmente prefiros os frameworks action based, voce tem um pouco mais de trabalho ate criar uma boa infra-estrutura, componentes etc… mas depois eh bem mais produtivo e bem mais facil de dar manutencao.
Quanto ao desempenho, nunca tive problemas com JSF.
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=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]
Olá! Eu concordo com você do jsf gerar o html final e ser um pouco chato de mecher nele. Mas só não entendi quando você falou em quebrar a cara para mecher no css. Você estava falando do JSF puro ou com Primefaces por exemplo? JSF puro realmente não é muito legal, mas com primefaces fica muito melhor. Os temas do primefaces já são legal, e ainda você pode criar seu tema em css no site do jquery tudo visual e depois baixar o css gerado. O que em termos de alteração visual fica bem mais legal.
Desde o início do ano passado, quando comecei a estudar mais a fundo Java, ouço dizer que JSF não é legal.
Resolvi estudar JSF e estou achando o framework muito interessante. Principalmente com PrimeFaces como muitos disseram nesse tópico.
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.
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.
Justamente…
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 !
[quote=lucasmurata]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.
[/quote]
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.
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.