Desvantagens de JSF

bom a grande vantagem do jsf é q ele é muito componentisavel, vc pode criar seus proprios componentes e reutiliza-los qnd bem entender, dessa forma fica facil quando vc quer agregar funcionalidades RIA em seus componentes jsf, ou usar uma pronta, richfaces, icefaces, primefaces … bom tem varios.

eu so meio suspeito pra falar de jsf, pq trabalho com ele :twisted:

mas acho q a grande desvantagem ta no aprendizado, ele tem uma api exclusiva, e é bem chatinho de aprender, mas nada impossivel…

no jsp + servlets, vc tem q fazer tudo na mao, e ainda vai usar de jstl, concerteza vai ter codigo java dentro do seus jsp, isso n é legal, procure nunca usar scriplets nas suas jsps .

enfim, entre fazer praticamente tudo na mao e ter uma ferramenta q me da muitos componentes prontos, porem customizaveis, eu fico com a segunda.

uma vantagem que eu acho que o jsf tem, é a legibilidade de codigo. fica bem mais organizado e simples de entender!!
e pra mim a desvantagem maior é o aprendizado como foi dito anteriormente mas é só uma questão de tempo e prática pra se entender a funcionalidade

Faz um código (uma página de login por exemplo) em PHP e outro em JSF e outro em JSP e Servlets e depois volta aqui e me diz qual você codificou mais :twisted:

Bem eu pessoalmente concordo com tudo que foi dito e ainda acrecentaria mais, como por exemplo a Orientação a Objeto do Java que é muito boa, já a do PHP 5 decha a desejar. Eu pessoalmete acho horrível.
No entanto se vc quer saber sobre quem é melhor acho que isso vai depnder do seu gosto e se todos querem saber quem é melhor ou quem é pior deve ser feito um estudo mais aprofundado com métricas para definir tal situação. Com tudo procurar ler relatos de amigos também é totalmente válido.

Bem, eu sei que JSF tem muitas vantagens, mas eu diria que algumas desvantagens são:

• alguns componentes são caixas pretas que vc precisa adivinhar como trabalhar com elas.
• Mudança de paradigma: para quem trabalhou muito tempo com os frameworks baseados em ações fica difícil mudar o pensamento

Espero que ninguém jogue pedra. É só minha opinião.

Abraço,

quais ?

acho muito dificil, geralmente so a documentação é mais do q suficiente …

mas qualquer framework pra mim tem componentes caixa preta…
rsrs

mas tudo se resolve com uma boa documentacao e estudo!

No tutorial de JSF do site Core Servlets, há uma excelente lista de desvantagens do JSF em comparação com a API de JSP e Servlets e com o Struts. Eu ainda acrescentaria a essa lista o fato de as requisições estarem amarradas ao método POST, não sendo possível usar GET, PUT, DELETE ou outros. A não ser, claro, que você utilize RESTFaces.

Não tem porque ninguém jogar pedra. O autor do tópico perguntou as desvantagens do framework - e elas existem. Esse não é o tópico de falar sobre as suas vantagens.

Não tem porque ninguém jogar pedra. O autor do tópico perguntou as desvantagens do framework - e elas existem. Esse não é o tópico de falar sobre as suas vantagens.

Eu sei, mas vc reparou que ninguém havia citado uma desvantagem sequer antes de mim?

Na minha opinião, as principais são as seguintes:

1. O ciclo de vida muito grande e adiciona muita complexidade.

2. AJAX deveria ser transparente, próprio dos componentes.

3. Ainda é baseado em páginas.

4. Se me lembro bem, é chato vc derivar os componentes.

Ainda não montei um projeto em JSF, apenas estudei; então desculpem ai se falei @#$%@ gigante rsrsrs.

flws

Eu concordo com o andrepestana, ninguem ainda tinha citado desvantagens o que sempre existe. E se quiserem saber desvantagens do JSF em relação ao JSP posso dizer que se exisitir algum erro este só poderar ser corrigido com uma nova versão deixando vc preso. Já o JSP não, vc está livre e a aplicação ainda pode ficar mais rápida se for usada de maneira limpa sem nenhum outro framework apenas com JDBC.

Minhas sinceras opniões:

Os cliclos são os mesmo: Application, Session, Request, Page.

O uso da biblioteca A4J do RichFaces é excelente e bastante funcional.

Não entendi o problema aqui ??? Então não vou comentar…

É chato e desnecessário. Portanto aceitável.

Estou trabalhando com JSF há muito tempo e não tenho do que reclamar…já passei por struts, vraptor, seam e servlets. Não que eles sejam piores que o JSF, mas na minha opnião o JSF é mais produtível.

[]'s

Não confunda ciclo de vida da página JSF com escopo do Managed Bean. E mesmo assim, escopo de Page está previsto apenas para o JSF 2.0.

tnaires wrote:

andrepestana wrote:Espero que ninguém jogue pedra. É só minha opinião.


Não tem porque ninguém jogar pedra. O autor do tópico perguntou as desvantagens do framework - e elas existem. Esse não é o tópico de falar sobre as suas vantagens.

Eu sei, mas vc reparou que ninguém havia citado uma desvantagem sequer antes de mim?

ta … n vo leva pro lado pessoal se naum vai virar flamewar …

Na minha opinião, as principais são as seguintes:

1. O ciclo de vida muito grande e adiciona muita complexidade.

2. AJAX deveria ser transparente, próprio dos componentes.

3. Ainda é baseado em páginas.

4. Se me lembro bem, é chato vc derivar os componentes.

Ainda não montei um projeto em JSF, apenas estudei; então desculpem ai se falei @#$%@ gigante rsrsrs.

flws

o ciclo de vida é complexo, um pouco, mas n é muito grande.

concordo que o ajax deveria ser transparente, afinal de contas, os componentes do jsf n tem ajax, sendo necessario usar terceiros, como o richfaces.

ele é baseado em paginas pq é statefull(me corrijam se estiver errado!)

n vamos entrar em patterns, isso pode ser feito com qql framework…

é questao de gosto no final das contas…

Não confunda ciclo de vida da página JSF com escopo do Managed Bean. E mesmo assim, escopo de Page está previsto apenas para o JSF 2.0.

Ah sim…ele estava se referindo aos ciclos de vida da página…foi mals…

Ainda sim acho que é ponto pro JSF que nos garante coisas como Validação e Conversão no java (e não no JavaScript) de uma forma programaticamnte fácil de se implementar.

http://www.roseindia.net/jsf/jsflifecycle.shtml

É verdade, mas não faz parte da arquitetura JSF.

P.S Gosto da idéia do JSF, quando for possível vou utiliza-lo em algum projeto por aqui.

flws

Possivelmente estou falando besteira, ainda não sei como confirmar ou não por isso tenho esta duvida se ela existe e se existir eh sim uma grande desvantagem.

Mas tenho a impressão de que todos os ManagerBean ou BackBean do seu projeto fica instanciado (após ser chamado a primeira vez), então se vc tiver um sistema com muitos ManagerBean sua aplicação vai comer memória com fome de leão!!!

Lembrando que o que estou falando eh o que eu acho, não verifiquei por não saber como fazer.

Abraço,

Marcelo Gomes

marcelogomesrp:

Possivelmente estou falando besteira, ainda não sei como confirmar ou não por isso tenho esta duvida se ela existe e se existir eh sim uma grande desvantagem.

Mas tenho a impressão de que todos os ManagerBean ou BackBean do seu projeto fica instanciado (após ser chamado a primeira vez), então se vc tiver um sistema com muitos ManagerBean sua aplicação vai comer memória com fome de leão!!!

Lembrando que o que estou falando eh o que eu acho, não verifiquei por não saber como fazer.

Abraço,

Marcelo Gomes

Assim como acontece com as Servlets

Não vejo isto como desvantagem, o que vc não pode fazer é deixar recursos pesados (conexões abertas, estrutura de dados enormes, etc…) anexados nestes beans. Esta questão está mais relacionada com boas praticas de programação e arquitetura mais elaborada.

flws

fantomas:

Não vejo isto como desvantagem, o que vc não pode fazer é deixar recursos pesados (conexões abertas, estrutura de dados enormes, etc…) anexados nestes beans. Esta questão está mais relacionada com boas praticas de programação e arquitetura mais elaborada.

Onde posso encontrar documentações que explica como lidar com isso (algum manual de boas praticas para jsf) ? caso tenha estruturas de dados enormes não sei como fugir de anexar elas.

Obrigado,

Marcelo Gomes

Isso depende apenas de como você configura o escopo dos seus managed beans. Se todos forem configurados com escopo de request, será sim criada uma nova instância para cada requisição. Se forem configurados com escopo de session, haverá uma única instância do managed bean para cada sessão do usuário. Finalmente, se forem configurados com escopo de application, haverá apenas uma instância daquele managed bean para toda a aplicação.

Ou seja, tudo é uma questão de configurar o escopo adequado para cada managed bean.

A melhor forma de lidar com isso é aprendendo a usar completamente o framework. Geralmente o desenvolvedor aprende JSF no momento em que precisa utilizá-lo, e acaba pulando conceitos básicos - como o ciclo de vida da página de JSF, que é um dos mais importantes - que influenciam na sua forma de desenvolver.

Este post do Rafael Ponte mostra um roteiro de aprendizado do framework JSF. Bastante completo, por sinal. Recomendaria também ler o livro Core JSF e também o tutorial de JSF do Core Servlets.

Obrigado pelas dicas.

JSF é lixo! Trabalhei um ano e meio com essa porcaria e ainda não entendo como alguém gosta da fazer as coisas pela maneira mais difícil. Como os problemas são vários, vou citar a pior delas:

- Dada uma lista de ítem (exibido por MenuItem ou por DataTable), exibir uma nova página que detalha esse simples elemento:
Se fosse num framework action-based de verdade, tudo que seria necessário era “apendar” o id do elemento desejado no link da nova página. Maaaaaaasss, é o JSF né? Precisa ser beeem mais difícil! É assim, se for um MenuItem, então monta um Map de valores que aparecerão como chave (acredite, não é nada intuitivo), depois crie uma propriedade get/set que receba o valor selecionado, e depois se vira com esse valor. Se for um DataTable, melhor o objeto encapsular um DataModel, porque aí eu chamaria o getObject() (de novo, nada intuitivo) desse model que devolve o elemento selecionado. Se não puder encapsular com DataModel, está na roça!

Detalhe, nos dois casos, sou obrigado a usar Session! Se eu utilizar Request, a lista de elementos desaparece e o JSF não sabe o que fazer. Já tentei usar escopo Page no JSF 2.0 Beta e, incrivelmente, dá erros muito mais estranhos.

Ai, como a solução oficial não atende, existem os famosos hacks de JSF que fica pegando o que foi colocado em <f:param/>, que deixa uma macarronada no código.

Não é o único problema, como disse antes, é apenas o pior. E não me venha dizer que eu não conheço o “maravilhoso” ciclo de vida do JSF. Conheço de cor-e-salteado, porque a burrice do framework me obrigou a isso.

Leonardo3001:

JSF é lixo! Trabalhei um ano e meio com essa porcaria e ainda não entendo como alguém gosta da fazer as coisas pela maneira mais difícil.

Não é o único problema, como disse antes, é apenas o pior. E não me venha dizer que eu não conheço o “maravilhoso” ciclo de vida do JSF. Conheço de cor-e-salteado, porque a burrice do framework me obrigou a isso.

Desculpa te dizer isso, mas você ainda não sabe bem usar o JSF.

Esse problema da lista desaparecer se botar com o escopo de request tem solução.

é só usar o a4j:keepAlive do richfaces… dá uma olhada no lide demo dele…

Eu concordo que usar o JSF puro é ruim, mas uma vez que você consegue entendê-lo e usar bibliotecas de terceiros você vai ver que ele pode ser muito produtivo e intuitivo. Porém gosto é gosto.

SanjuanRJ:

Leonardo3001:

JSF é lixo! Trabalhei um ano e meio com essa porcaria e ainda não entendo como alguém gosta da fazer as coisas pela maneira mais difícil.

Não é o único problema, como disse antes, é apenas o pior. E não me venha dizer que eu não conheço o “maravilhoso” ciclo de vida do JSF. Conheço de cor-e-salteado, porque a burrice do framework me obrigou a isso.

Desculpa te dizer isso, mas você ainda não sabe bem usar o JSF.

Esse problema da lista desaparecer se botar com o escopo de request tem solução.

é só usar o a4j:keepAlive do richfaces… dá uma olhada no lide demo dele…

Eu concordo que usar o JSF puro é ruim, mas uma vez que você consegue entendê-lo e usar bibliotecas de terceiros você vai ver que ele pode ser muito produtivo e intuitivo. Porém gosto é gosto.

Achei muito curiosa sua opinião, o que vc indicaria struts 1, 2…?

Leonardo3001:

JSF é lixo! Trabalhei um ano e meio com essa porcaria e ainda não entendo como alguém gosta da fazer as coisas pela maneira mais difícil. Como os problemas são vários, vou citar a pior delas:

- Dada uma lista de ítem (exibido por MenuItem ou por DataTable), exibir uma nova página que detalha esse simples elemento:
Se fosse num framework action-based de verdade, tudo que seria necessário era “apendar” o id do elemento desejado no link da nova página. Maaaaaaasss, é o JSF né? Precisa ser beeem mais difícil! É assim, se for um MenuItem, então monta um Map de valores que aparecerão como chave (acredite, não é nada intuitivo), depois crie uma propriedade get/set que receba o valor selecionado, e depois se vira com esse valor. Se for um DataTable, melhor o objeto encapsular um DataModel, porque aí eu chamaria o getObject() (de novo, nada intuitivo) desse model que devolve o elemento selecionado. Se não puder encapsular com DataModel, está na roça!

Detalhe, nos dois casos, sou obrigado a usar Session! Se eu utilizar Request, a lista de elementos desaparece e o JSF não sabe o que fazer. Já tentei usar escopo Page no JSF 2.0 Beta e, incrivelmente, dá erros muito mais estranhos.

Ai, como a solução oficial não atende, existem os famosos hacks de JSF que fica pegando o que foi colocado em <f:param/>, que deixa uma macarronada no código.

Não é o único problema, como disse antes, é apenas o pior. E não me venha dizer que eu não conheço o “maravilhoso” ciclo de vida do JSF. Conheço de cor-e-salteado, porque a burrice do framework me obrigou a isso.

eu concordo em genero, numero e grau… apesar de eu usar jsf no dia a dia, e modestia a parte gosto de trabalhar com ele …

ele na maioria das vezes complica as coisas … mas eu acho que sou masoquista :twisted:

e vc precisa fazer do ciclo de vida do jsf seu livro da cabeceira da cama, aquele que vc le antes de dormir … se naum n tem como trabalhar com ele satisfatoriamente

Leonardo3001:

JSF é lixo! Trabalhei um ano e meio com essa porcaria e ainda não entendo como alguém gosta da fazer as coisas pela maneira mais difícil. Como os problemas são vários, vou citar a pior delas…

Cara…vou ter que concordar com o amigo acima. Você não conhece o JSF ou não possui o paradigma de frameworks Component Based bem definido. Se JSF fosse ruim ele não seria maioria absoluta nas empresas quem empregam o JEE.

SanjuanRJ:

Desculpa te dizer isso, mas você ainda não sabe bem usar o JSF.

Esse problema da lista desaparecer se botar com o escopo de request tem solução.

é só usar o a4j:keepAlive do richfaces… dá uma olhada no lide demo dele…

Eu concordo que usar o JSF puro é ruim, mas uma vez que você consegue entendê-lo e usar bibliotecas de terceiros você vai ver que ele pode ser muito produtivo e intuitivo. Porém gosto é gosto.

Claro!

Vejamos, tenho a camada web “pura” (Servlets e JSP). Aí adiciono uma camada acima, o JSF, que cria um paradigma esquisito que cria uma série de problemas. Solução? Use uma biblioteca que fica em cima do JSF pra consertar o que ele mesmo errou!

Ótimo!

Conheço o JSF, como disse antes, trabalhei com ele por um ano e meio. O grande problema dos fanáticos do JSF é o tal do “paradigma do sei-lá-o-quê” que só o JSF tem! Aí, quando alguém questiona a maneira idiota de se fazer programas web com JSF, é porque não conhecem o paradigma mágico ou o ciclo de vida bem definido que esse “maravilhoso” framework tem.

Ah, tenha dó!

Leonardo3001:

SanjuanRJ:

Desculpa te dizer isso, mas você ainda não sabe bem usar o JSF.

Esse problema da lista desaparecer se botar com o escopo de request tem solução.

é só usar o a4j:keepAlive do richfaces… dá uma olhada no lide demo dele…

Eu concordo que usar o JSF puro é ruim, mas uma vez que você consegue entendê-lo e usar bibliotecas de terceiros você vai ver que ele pode ser muito produtivo e intuitivo. Porém gosto é gosto.

Claro!

Vejamos, tenho a camada web “pura” (Servlets e JSP). Aí adiciono uma camada acima, o JSF, que cria um paradigma esquisito que cria uma série de problemas. Solução? Use uma biblioteca que fica em cima do JSF pra consertar o que ele mesmo errou!

Ótimo!

Nisso eu concordo com você. Mas a solução é relativamente simples. É óbvio que nada é perfeito, mas o que você recomendaria???

O JSF é o framework com que eu tenho mais produtividade no momento. Se vc sugerir algum outro eu vou dar uma estudada.

Ainda tenho muito o que estudar então não vou entrar no merito do que é melhor ou pior, mas realmente fico curioso com qual framework atual pode ser mais produtivo que o jsf.

Com o ganho de espaço que o jsf esta tendo, acho que ele é o caminho e é o que estou estudando…

marcelogomesrp:

Ainda tenho muito o que estudar então não vou entrar no merito do que é melhor ou pior, mas realmente fico curioso com qual framework atual pode ser mais produtivo que o jsf.

Com o ganho de espaço que o jsf esta tendo, acho que ele é o caminho e é o que estou estudando…

[quote=SanjuanRJ]

Leonardo3001:

JSF é lixo! Trabalhei um ano e meio com essa porcaria e ainda não entendo como alguém gosta da fazer as coisas pela maneira mais difícil.

Não é o único problema, como disse antes, é apenas o pior. E não me venha dizer que eu não conheço o “maravilhoso” ciclo de vida do JSF. Conheço de cor-e-salteado, porque a burrice do framework me obrigou a isso.

Leonardo3001 você foi totalmente equivocado no seu exemplo, sem querer ofende-lo, mas você perdeu um ano e meio trabalhando com uma tecnologia que você desconhece até hoje. Acho seu comentário inválido pois muitas pessoas que pretendem começar podem ler esse tópico e ficar “envenenadas” por uma opinião muito errada e sem fundamento.

A maior desvantagem do JSF é realmente a curva de aprendizado.
Essa resposta pode ser encontrada nesta própria discussão. Com certeza o pessoal que têm mais experiência com o framework ao dar uma passada de olhos nesse fórum encontra muitas respostas equivocadas tomadas como verdadeiras.

Uma vez um cara me disse que o JSF nao separa bem o controlador da view. É verdade isso?

na verdade a camada view do jsf seria o html gerado, aquele q é exibido no navegador, e o controle seria o seus managed beans e suas jsp com os componentes jsf …

posso ta redondamente errado mas tivemos uma discussao acerca disso a algum tempo aqui, foi essa a conclusao q chegamos …

uma dica boa pra separar bem as camadas seria a integração de spring com flex

Se JSF é um lixo então todo mundo ficou louco e resolveram colocar este “lixo” como padrão para a camada de visualização web enquanto as páginas jsp estarão na próxima especificação apenas para manter a compatibilidade?
[edit] Não que eu ache o JSF a oitava maravilha mais pra mim é obvio que é uma solução muito melhor que trabalhar simplesmente com jsp + algum outro framework ajax pra uma interface RIA.
Tem um framework que quer se “a” alternativa para jsf, o ZKoss. Eu até ví um comparativo entre os dois.
Parece ser bem interessante.

andrepestana:

Bem, eu sei que JSF tem muitas vantagens, mas eu diria que algumas desvantagens são:

• alguns componentes são caixas pretas que vc precisa adivinhar como trabalhar com elas.
• Mudança de paradigma: para quem trabalhou muito tempo com os frameworks baseados em ações fica difícil mudar o pensamento

Espero que ninguém jogue pedra. É só minha opinião.

Abraço,

Concordo em parte que são caixas pretas os componentes, exemplo richfaces e etc…

Conheço o JSF, como disse antes, trabalhei com ele por um ano e meio. O grande problema dos fanáticos do JSF é o tal do “paradigma do sei-lá-o-quê” que só o JSF tem! Aí, quando alguém questiona a maneira idiota de se fazer programas web com JSF, é porque não conhecem o paradigma mágico ou o ciclo de vida bem definido que esse “maravilhoso” framework tem.

Ah, tenha dó!

Cara…1 ano e meio é categoria junior (quanto a JSF) no meu conceito. Segundo, uma pessoa que comenta um forúm com palavras como “idiota” não tem muita maturidade ainda.

[]'s

rogeriuslima:

Se JSF é um lixo então todo mundo ficou louco e resolveram colocar este “lixo” como padrão para a camada de visualização web enquanto as páginas jsp estarão na próxima especificação apenas para manter a compatibilidade?
[edit] Não que eu ache o JSF a oitava maravilha mais pra mim é obvio que é uma solução muito melhor que trabalhar simplesmente com jsp + algum outro framework ajax pra uma interface RIA.
Tem um framework que quer se “a” alternativa para jsf, o ZKoss. Eu até ví um comparativo entre os dois.
Parece ser bem interessante.

Eu cheguei a ver esse zkoss também. Larguei mão depois de umas 2 semanas.

Primeiro que é pago e segundo porque ele não é muito flexível. Você pode até criar os seus próprios componentes nele, mas achei que ele força muito com uma padronização de certas coisas e achei que falta um material mais completo também.

Com JSF vc não tem somente o richfaces. Eu estava dando uma olhada em um tal de “prime JSF” e me parece ser legal tb…

Eu cheguei a ver esse zkoss também. Larguei mão depois de umas 2 semanas.

Primeiro que é pago e segundo porque ele não é muito flexível. Você pode até criar os seus próprios componentes nele, mas achei que ele força muito com uma padronização de certas coisas e achei que falta um material mais completo também.

Com JSF vc não tem somente o richfaces. Eu estava dando uma olhada em um tal de “prime JSF” e me parece ser legal tb…

Valeu pela opnião.

Vamos lá, de programação, tenho cinco anos de experiência e nesse período estudei muito. Então não acho que eu seja júnior ou que desconheço muita coisa. Pra vocês terem uma idéia, no período em que trabalhava com JSF, li e reli o Core Java Server Faces várias vezes pra ver se achava alguma luz e ainda tava umas pageadas no JavaServer Faces Reference. Cheguei ao nível de olhar o código do MyFaces em detalhes para ver se eu fazia um PhaseListener ou um ActionListener que superava limitações que eram facilmente encontradas. Desculpem, mas se vocês me acham inexperiente, é problema de vocês.

Quanto a acharem minha argumentação sem fundamento, veja que eu apresentei um problema sério, que só o JSF apresenta, que é: quando há uma lista, é necessário colocar todo mundo na session. Existe o keepAlive? Existe, mas é muito POG! Não tem uma coisa dessas em qualquer framework que se encontra por aí, onde a solução pra isso é simples e intuitivo.

A coisa é mais complicada do que parece. O JSF é interessante do ponto de vista comercial por causa dos componentes, pois qualquer “vendor” pode adicionar seus penduricalhos e forçar um lock-in no cliente. E também, quem compra esses produtos não são o desenvolvedor final, mais algum gerente que não entende de programação.

Minha opinião, existem frameworks melhores e mais produtivos. Um é nosso conhecido VRaptor, outro é o Struts 2.1, onde é possível usar bastante convenção. E futuramente, a versão 3.0 do Spring vai dar uma repaginada no seu framework MVC pra ser uma coisa bem agradável de se usar. Então, opção melhor nunca faltou.

Leonardo é um gênio! Repito o que ele disse: JSF é um lixo. Quem só conhece Chã de Dentro acha maravilhoso. Prova o filet mignon amigo, please!

Outra coisa que as pessoas simplesmente não entendem, pois receberam as coisas garganta abaixo sem questionar, ou seja, são apenas repetidores das opiniões dos seus “mestres”, é que um projeto web envolve MUITO MAIS QUE MVC E CONTROLADOR. Claro que o controlador é importante, mas ele é a parte menor do problema.

Por isso que um framework web tem que ser full-stack, ou seja, tem que resolver TODOS os problemas relacionados a uma aplicação web, como autenticação, autorização, pool de conexões, ioc, autowiring, envio de email, ajax, i18n, etc. Um projeto web não deve ser uma salada de frameworks.

Frameworks web full-stack que eu conheço: RoR, Mentawai e Rife.

O Mentawai por exemplo é full-stack desde 2005, muito antes de VRaptor2, Struts2, Seam, etc. existirem. Como centenas de pessoas relataram, qualquer um lê a documentação do Mentawai e começa a programar full-speed em menos de um dia. Não existem milhões de detalhes e sacanagens tolas como o JSF. É a simplicidade pela objetividade e vice-versa.

Fiz alguns sites com JSF e foi uma tortura. Já com o Mentawai coloquei em menos de 30 dias no ar um site bem complexo com dezenas de funcionalidades.

Faça uma análise isenta de influencias externas e decida por si mesmo o que é filet mignon e o que é chã de dentro. O que é macio e desce fácil e redondo e o que te obriga a mastigar até os seus dentes doerem. Porque no final do mês o que importa é a produtividade, qualidade e a eficiência do seu trabalho e não o grupinho que vc pertence ou o time que vc torce.

Não sei ao que você se refere da necessidade de colocar todo mundo na sessão quando existe uma lista. Tem certeza que este é um problema da especificação JSF?

O JSF hoje em dia está sendo o novo Struts em termos de mercado. Em alguns lugares você simplesmente precisa usar JSF, sem poder escolher outro framework, por isso é importante estudá-lo independente de gostar dele ou não. Sorte daqueles que não tem esse problema…

Não sei o que querem dizer com o JSF ter sido enfiado goela a baixo. Pelo que eu estou vendo se foi, foi para uma minoria.
Eu não gosto de struts mais tive de engolir o fato de que struts era praticamente um padrão e aprendê-lo.

O colega saoj fez criticas realmente construtivas ao JSF (tirando a parte em que ele afirma que “a maioria” não passa passa de papagaios que repetem o que seus mestres falam (não exatamente com estas palavras)), pois apresentou alternativas que aliás eu vou até começar a estudar.
Porém, na parte em que ele cita os serviços que o framework deve prover parece que ele esqueceu um pequeno detalhe, que é o fato de que JSF é mais uma especificação de J2EE e que a maioria dos serviços apontados estão presentes em outras especificações e portanto estão fora do escopo do JSF.

Cara…o JSF faz parte da especificação JEE. Essa sim dá tudo o que uma aplicação WEB precisa.

Tem muita opção melhor que JSF, mais produtivas e simples hoje em dia, este negócio de padrão de mercado é puro medo por parte dos gerentes em apostar em tecnologias.

aleck:

Tem muita opção melhor que JSF, mais produtivas e simples hoje em dia, este negócio de padrão de mercado é puro medo por parte dos gerentes em apostar em tecnologias.

Cara, eu não digo que JSF seja “a” melhor opção, mas concerteza é uma das melhores.
Agora chegar e simplesmente dizer que tem muita opção melhor e não citar pelo menos uma é no minimo uma opnião vazia.

Qualquer programador descente sabe que JSF fede. A razão de ser muito usado? Simples, especificação.
Tudo que é especificação tem apoio dos “grandes” players do mercado.
Se eu pudesse escolher, colocaria um Rails, Django ou Fit da vida. Tem aplicações que em JSF levariam 2 semanas para fazer e no Rails algumas horas, sem dó.
Mas tenho que aceitar o JSF quer eu queira ou não. Em relação a ser ou não full-stack, nem tudo é legal ser assim, por que? Se você um dia escolher mudar, sua aplicação é “big”, seu framework faz tudo, fedeu mais ainda. Você fica preso ao bicho e ele está lá, mofando.
Imagine se o Struts fosse full-stack como o Rails, nossa, tem empresas que morreriam, com certeza.
Devemos lembrar que nem tudo é bom. Mesmo que o framework X diga que pode destacar Y parte, depende do cenário.
Também não culpem uma grande empresa por usar uma tecnologia X, olhem por seus lados, eles querem garantias. Mesmo sabendo que não há, eles querem sentirem-se seguros do investimento que as vezes é milionário.

rogeriuslima:

Cara, eu não digo que JSF seja “a” melhor opção, mas concerteza é uma das melhores.
Agora chegar e simplesmente dizer que tem muita opção melhor e não citar pelo menos uma é no minimo uma opnião vazia.

http://wicket.apache.org/

djemacao:

Se eu pudesse escolher, colocaria um Rails, Django ou Fit da vida. Tem aplicações que em JSF levariam 2 semanas para fazer e no Rails algumas horas, sem dó.

Vc reparou que a maioria das alternativas que vc citou não são alternativas ao JSF e sim ao Java? (não conheço o Fit, por isso coloquei a maioria).
Se for assim, eu também prefiro Zope/Plone e daqui a pouco vai aparecer alguém dizendo que a solução definitiva para JSF se chama .NET

Uma afirmação tão cheia de conteúdo quanto um pastel de vento merece uma resposta igualmente cheia de conteúdo:
Não, não fede.
Cara, desculpa se estou parecendo grosseiro, não é minha intenção, mas é muito fácil chegar e falar o que quiser e não dá uma razão lógica pra isso.
EJB também é uma especificação e vc não vai encontrar tantos desenvolvedores vindo aqui defendê-lo e nem sendo utilizado pela maioria das empresas.

Com rich faces esse problema é contornado ridiculamente. E nem precisa de página nova, um simples modal panel resolve.

rogeriuslima:

djemacao:

Se eu pudesse escolher, colocaria um Rails, Django ou Fit da vida. Tem aplicações que em JSF levariam 2 semanas para fazer e no Rails algumas horas, sem dó.

Vc reparou que a maioria das alternativas que vc citou não são alternativas ao JSF e sim ao Java? (não conheço o Fit, por isso coloquei a maioria).
Se for assim, eu também prefiro Zope/Plone e daqui a pouco vai aparecer alguém dizendo que a solução definitiva para JSF se chama .NET

Uma afirmação tão cheia de conteúdo quanto um pastel de vento merece uma resposta igualmente cheia de conteúdo:
Não, não fede.
Cara, desculpa se estou parecendo grosseiro, não é minha intenção, mas é muito fácil chegar e falar o que quiser e não dá uma razão lógica pra isso.
EJB também é uma especificação e vc não vai encontrar tantos desenvolvedores vindo aqui defendê-lo e nem sendo utilizado pela maioria das empresas.

Edit: Coloquei os links das linguagens para não vir outro “esperto” achar que comendo mortadela se arrota caviar.

djemacao:

Desculpa, mas de que planeta vc veio mesmo?
JRuby roda onde mesmo?
Jython roda onde mesmo?
Scala é de onde mesmo?
JSF é componentes, mas não precisa comparar com framework similar, como o .Net, que não é Java.
Quer o que? Usar o Seam? Ainda prefiro JRuby on Rails, Jython com Django.
Acho que seu “pastel de vento” que não possui argumentos. Se não conhece, não trabalhou com um destes que citei, não fale. Eu uso cada um deles e posso dizer e afirmar: JSF fede. Talvez, digo porque ainda não me convenci, que o JSF 2 fique “melhorzinho”. Mas de 0 a 10, dou -1 pro JSF atual. Já era para ter melhorado, mas tudo anda como lesma na Sun. QUem sabe a Oracle sacode o negócio.

Edit: Coloquei os links das linguagens para não vir outro “esperto” achar que comendo mortadela se arrota caviar.

KKKKKK, putz, valeu pelos momentos divertidos, se tem uma coisa que eu adoro é ver a hemorroida alheia pulando por coisa besta.
Quando vc mencionou estes frameworks em nenhum momento vc mencionou que eram eles rodando em java, pois pelo menos “no meu planeta”, Ruby on Rails e Django nasceram fora e só depois vieram JRuby e Jython, e “no meu planeta” também se sabe que java é uma plataforma que engloba outras linguagens.
O restante do seu comentario continua um pastel de vento. Continua dizendo que JSF fede e sem dizer uma única razão para isso, só acrescentou que trabalha com todos os frameworks citados e blablabla.

Edit:

Vc diz uma bestera dessa e vem me perguntar de que planeta eu vim?
Já ouviu falar do JCP?
Segue o link

Neste topico seria para ser citadas os pos e contras do JSF, na verdade todo e qualquer problema em JSF pode ser contornado, e por ser muito utilizado pelas empresas o material disponível para ele é cada dia maior, a produtividade dele esta entre as melhores, não todo e qualquer problema de desempenho dele depende de como vc implementa o codigo, Isso não quer dizer que os outros frameworks são ruins, na verdade o melhor framework é aquele que vc tem o melhor dominio dele.

Eu escolhi o JSF, pois dominar o framework lider de mercado abre mais portas, não por que ele é melhor ou pior que os outros. Mais uma coisa é certa, ele não perde em nada para os outros, é utiliza-lo da forma correta e com as combinações certas, quem desenvolve o sistema é o programador e não o framework.