Arquivo Discussoes de Programacao e Tecnologia Muito boa esta comparação entre frameworks feita pela zeroturnaround. Ou pra quem não tem paciência, olhe direto o resultado da comparação
Compara os frameworks Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts e JSF. Ainda estou no Spring e não sabia que era o mais usado e um dos piores.
Melhor começar a rever alguns conceitos.
esse post vai dar o que falar.rsrs
Obrigado por compartilhar o material. Muito bom saber esse tipo de coisa. Estava pensando em aprender Spring, mas me desmotivei um pouco depois de ler esse material, estou mais interessado em aprender Grails agora.
Legal a comparação, embora não esteja certo se os resultados devam ser considerados ao "pé da letra".
O interessante ao meu ver é não ficar preso apenas a um framework.
Muitos novatos querem começar logo a programar usando JSF(ou outro), sem ao menos ter estudado web/servlet/jsp, passei por isso. Acaba não sabendo o que está acontecendo, vira um mero utilizador do framework e um imprevisto pode travar seu projeto(até alguém socorrer).
Grato pelo compartilhamento.
Tomem cuidado pessoal. Só dei uma olhada aqui nos resultados e o framework que ele cita é o Spring MVC que é apenas uma parte do framework Spring.
A stack do Spring é muito boa.
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.
O play é ótimo também na minha opinião.
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.
O play é ótimo também na minha opinião.
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.
O play é ótimo também na minha opinião.
JSF pra aplicações Web eu tbm não utilizo mais, não tenho razão pra isso,
Minha arquitetura preferida hoje sem dúvida é Rest, json pra cima e pra baixo, com HTML5, um bom framework JS(backbone, ember) pra organizar o front-end e bourbon pro scss, o play e vraptor é massa tbm
2 pontos que me chamaram atenção no Play e pra min de extrema importância é a Scalability e Rapid Application Development com nota 5
Mas , afinal , qual framework de controle está dominando o mercado atualmente aqui no brasil.
Eu por exemplo sou da galera que não tem nem um ano de programação,já sabe desenvolver aplicações web com servlets controlando as requisições(logico,tenho muito que aprender ainda) mas tem que escolher seu primeiro framework para estudar e entrar no mercado de trabalho,já estudei vraptor e gostei muito,mas quero escolher entre springs ou struts,porém,parece que o struts está bem fraquinho…
Mas , afinal , qual framework de controle está dominando o mercado atualmente aqui no brasil.
Eu por exemplo sou da galera que não tem nem um ano de programação,já sabe desenvolver aplicações web com servlets controlando as requisições(logico,tenho muito que aprender ainda) mas tem que escolher seu primeiro framework para estudar e entrar no mercado de trabalho,já estudei vraptor e gostei muito,mas quero escolher entre springs ou struts,porém,parece que o struts está bem fraquinho…
Mercado de trabalho JSF e Spring sem dúvida.
Se o VRaptor melhorasse um pouco sua documentação e tivesse um marketing mais agressivo, ia brigar de igual pra igual com muitos ali.
Agora, fui direto pro resultado e me espantei ao ver Throughput/Scalability, e pra não tirar conclusões precipitadas fui ver a avaliação do quesito. Ele cita um monte de coisas que o Spring possui pra aumentar a vazão e processamento paralelo, além de facilmente escalar memória com a adição de EHCache. E na avaliação do JSF afirma que pode ser performático, mas que o real ganho só vem com clusterização e que não possui nativamente nada que possibilite o paralelismo, apoiando-se para isso em outros pontos do Java. Com isso, acho que ele fugiu do domínio do JSF como framework web. No fim, atribui a mesma nota aos dois, e acho que foi totalmente incoerente.
Mas , afinal , qual framework de controle está dominando o mercado atualmente aqui no brasil.
Eu por exemplo sou da galera que não tem nem um ano de programação,já sabe desenvolver aplicações web com servlets controlando as requisições(logico,tenho muito que aprender ainda) mas tem que escolher seu primeiro framework para estudar e entrar no mercado de trabalho,já estudei vraptor e gostei muito,mas quero escolher entre springs ou struts,porém,parece que o struts está bem fraquinho…Mercado de trabalho JSF e Spring sem dúvida.
Obrigado!
Continuando sobre a vazão, ele comenta que o ponto alto do GWT é o compilador Java para javascript, e por isso parte da lógica pode ser executada no cliente e não no servidor. Daí ele fala que o Struts é todo server-side, e que isso é uma desvantagem. Mas espera aí, com qualquer framework action-based você pode fazer misérias no client-side e só trafegar JSON em requisições assíncronas na maioria das vezes.
Não posso falar do GWT e de vários outros ali pq não conheço mas, se o GWT gera esse javascript pra vc, acredito que não seja tão simples e livre a manipulação do lado cliente. Conheço o JSF e ele não permite tanto controle assim no lado cliente, fora o overhead pra montar a árvore de componentes. No fim, atribui nota maior ao JSF que para frameworks que te deixam fazer tudo no cliente (action-based).
Obrigado por compartilhar o material. Muito bom saber esse tipo de coisa. Estava pensando em aprender Spring, mas me desmotivei um pouco depois de ler esse material, estou mais interessado em aprender Grails agora.Cuidado. Não fique apenas com uma opinião.
Isso pode te tornar um péssimo profissional por sempre pegar uma opinião e seguir.
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.Caracas…
O play é ótimo também na minha opinião.
Desde antes de escrever o livro de JSF eu odiava esse tipo de comentário, e ainda continuo…
Pessoal acha que JSF é simples igual JSP, que basta colocar o código na tela e sair usando. Triste ver pessoas falando isso.
Se o VRaptor melhorasse um pouco sua documentação e tivesse um marketing mais agressivo, ia brigar de igual pra igual com muitos ali.Agora, fui direto pro resultado e me espantei ao ver Throughput/Scalability, e pra não tirar conclusões precipitadas fui ver a avaliação do quesito. Ele cita um monte de coisas que o Spring possui pra aumentar a vazão e processamento paralelo, além de facilmente escalar memória com a adição de EHCache. E na avaliação do JSF afirma que pode ser performático, mas que o real ganho só vem com clusterização e que não possui nativamente nada que possibilite o paralelismo, apoiando-se para isso em outros pontos do Java. Com isso, acho que ele fugiu do domínio do JSF como framework web. No fim, atribui a mesma nota aos dois, e acho que foi totalmente incoerente.
Acho que se o VRaptor quer crescer mesmo, tá na hora de colocar documentação também inglês e vender para o mundo a idéia.
Se o VRaptor melhorasse um pouco sua documentação e tivesse um marketing mais agressivo, ia brigar de igual pra igual com muitos ali.Agora, fui direto pro resultado e me espantei ao ver Throughput/Scalability, e pra não tirar conclusões precipitadas fui ver a avaliação do quesito. Ele cita um monte de coisas que o Spring possui pra aumentar a vazão e processamento paralelo, além de facilmente escalar memória com a adição de EHCache. E na avaliação do JSF afirma que pode ser performático, mas que o real ganho só vem com clusterização e que não possui nativamente nada que possibilite o paralelismo, apoiando-se para isso em outros pontos do Java. Com isso, acho que ele fugiu do domínio do JSF como framework web. No fim, atribui a mesma nota aos dois, e acho que foi totalmente incoerente.
Pois é. Concordo com tudo, até mesmo a parte do VRaptor.Acho que se o VRaptor quer crescer mesmo, tá na hora de colocar documentação também inglês e vender para o mundo a idéia.
Mas tem documentação em inglês:
http://vraptor.caelum.com.br/en/docs/one-minute-guide/ 
Mas tem documentação em inglês:Uia, quando eu havia olhando (e isso um bom tempo atrás) só havia em português. [=
http://vraptor.caelum.com.br/en/docs/one-minute-guide/ ;)
Bom saber, já posso indicar p/ gringos. [=
Acho interessante e boa essa comparação entre frameworks, mas o Slow colocou uma questão interesante que a adoção no brasil desses frameworks. Como foi respondido JSF e Spring dominam (ainda tem muito struts por ai).
Dos frameworks que conheço (Spring e VRaptor, JSF), se fosse para escolher um framework baseado na pesquisa e no mercado brasileiro eu ira de JSF com Primefaces. Eu acho ele bem produtivo (para um ambiente web) embora Spring e VRaptor deem uma flexibilidade maior em relação a implementação das views, JSF permite a construção de views por quaquer programador.
Para mim Spring e VRaptor são bons, mas é necessário a utilizção de de dois programadores ou que se encontre um muito bom em backend e frontend (não é meu caso)!
Excluindo o mercado, um que achei bastante interessante é o GWT, embora não tivesse tempo de aprende-lo ainda. Contudo acredito com ele ficaria bem dependente do CSS para ter uma interface interessante.
Essa é uma opnião pessoal. Sempre tive problemas para criar interfaces, não sou designer! Mesmo no mundo desktop, criar uma interface fluida era complicado, embora fosse bem mais simples do que utilizando HTML e CSS.
Continuando sobre a vazão, ele comenta que o ponto alto do GWT é o compilador Java para javascript, e por isso parte da lógica pode ser executada no cliente e não no servidor. Daí ele fala que o Struts é todo server-side, e que isso é uma desvantagem. Mas espera aí, com qualquer framework action-based você pode fazer misérias no client-side e só trafegar JSON em requisições assíncronas na maioria das vezes.Não posso falar do GWT e de vários outros ali pq não conheço mas, se o GWT gera esse javascript pra vc, acredito que não seja tão simples e livre a manipulação do lado cliente. Conheço o JSF e ele não permite tanto controle assim no lado cliente, fora o overhead pra montar a árvore de componentes. No fim, atribui nota maior ao JSF que para frameworks que te deixam fazer tudo no cliente (action-based).
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.Caracas…
O play é ótimo também na minha opinião.Desde antes de escrever o livro de JSF eu odiava esse tipo de comentário, e ainda continuo…
Pessoal acha que JSF é simples igual JSP, que basta colocar o código na tela e sair usando. Triste ver pessoas falando isso.
Foi o que eu disse sobre conhecer o framework.Pois é, eu também concordo com você.
A maioria reclama deste e daquele framework, sendo que sequer chegou a estudá-los, entende-los e fazer algo com eles.
O único para o qual eu dou crédito quando critica algo é o saoj, por que o sujeito vai até o último detalhe dentro do framework para entender e então falar sobre.
Não gosto do Struts 1.2 mas nunca falei mau sobre o Struts 2 por exemplo. Nunca trabalhei, apenas fiz alguns estudos sobre o framework.
O JSF é engraçado por que neguim vê o site do primefaces e fica babando, ainda mais quando percebe que basta 3 linhas de código para fazer um trem muito maneiro. Aí começa colocando ManagedBeans como SessionScoped, lota de lista e fala que o framework é lente e pesa a máquina.
Eu não conhecia o Spring, mas antes de falar qualquer coisa não fiquei apenas no hello word da vida. Já li mais de 1.2k de páginas sobre o Spring e hoje começo a entender melhor o que ele faz.
Fala sério. É legal ver essas pesquisas, é. Agora é triste ver pessoas com a mente tão pequena e a preguiça tão grande.
Continuando sobre a vazão, ele comenta que o ponto alto do GWT é o compilador Java para javascript, e por isso parte da lógica pode ser executada no cliente e não no servidor. Daí ele fala que o Struts é todo server-side, e que isso é uma desvantagem. Mas espera aí, com qualquer framework action-based você pode fazer misérias no client-side e só trafegar JSON em requisições assíncronas na maioria das vezes.Não posso falar do GWT e de vários outros ali pq não conheço mas, se o GWT gera esse javascript pra vc, acredito que não seja tão simples e livre a manipulação do lado cliente. Conheço o JSF e ele não permite tanto controle assim no lado cliente, fora o overhead pra montar a árvore de componentes. No fim, atribui nota maior ao JSF que para frameworks que te deixam fazer tudo no cliente (action-based).
A manutenção de código GWT é bem mais simples do que JS, afinal vc está usando a mesma linguagem do servidor (Java), obtendo os benefícios da tipagem forte nas variáveis. Além disso, vc ganha a vantagem de o GWT otimizar e ofuscar o código JS gerado. Quer mais? O GWT é component-based, o que permite alta reutilização de código, principalmente em grandes projetos.
Veja abaixo um benchmark entre GWT e outros engines:
http://gwtquery.googlecode.com/svn/trunk/demos/gwtquery.samples.GwtQueryBench/GwtQueryBench.html
Foi o que eu disse sobre conhecer o framework.Pois é, eu também concordo com você.
A maioria reclama deste e daquele framework, sendo que sequer chegou a estudá-los, entende-los e fazer algo com eles.
O único para o qual eu dou crédito quando critica algo é o saoj, por que o sujeito vai até o último detalhe dentro do framework para entender e então falar sobre.Não gosto do Struts 1.2 mas nunca falei mau sobre o Struts 2 por exemplo. Nunca trabalhei, apenas fiz alguns estudos sobre o framework.
O JSF é engraçado por que neguim vê o site do primefaces e fica babando, ainda mais quando percebe que basta 3 linhas de código para fazer um trem muito maneiro. Aí começa colocando ManagedBeans como SessionScoped, lota de lista e fala que o framework é lente e pesa a máquina.
Eu não conhecia o Spring, mas antes de falar qualquer coisa não fiquei apenas no hello word da vida. Já li mais de 1.2k de páginas sobre o Spring e hoje começo a entender melhor o que ele faz.
Fala sério. É legal ver essas pesquisas, é. Agora é triste ver pessoas com a mente tão pequena e a preguiça tão grande.
Cara, eu era um crítico ferrenho do JSF, não gostava dele, achava complexo, com implementações mal documentadas na época que usei (richfaces), que falhava em silêncio, dava uma série de problemas relacionados a eu não saber usar (ou seja era pouco intuitivo) e com componentes complexos.
Hoje não critico mais JSF porque não trabalho mais com ele e porque não sei a quantas andam as versões atuais. Mas meu preconceito contra ele continua grande. Principalmente do ponto de vista de quem trabalha com VRaptor, que é extraordinário, na minha humilde opinião.
Mas de tanto argumentar e contra-argumentar e argumentar novamente do porque eu não gostava do JSF eu desenvolvi uma linha de raciocínio que já não sei se é valida hoje, mas com certeza era a época do JSF 1 e richfacesl. Que se baseia nos porquês de se componetizar elementos de tela. Quando você está lidando com uma aplicação desktop no Windows trabalhar os seus controles de entrada e saida de dados diretamente com a API padrão do Windows é impensável. O que foi feito com as APIs do VB e Delphi foi simplificar o acesso a API de entrada e saída de dados, com componentes bem amigáveis, intuitivos e fáceis de configurar.
Mas os componentes de entrada e saída html são extramente simples para serem simplificados, então essa componentização (na minha opinião), que começou pelo .NET e depois veio para o Java, veio para atender o hábito que a maioria dos programadores tinha de lidar com componentes ao invés de ações. Porém o que as camadas de componentes fizeram (camadas porque no fundo vira tudo em html mesmo) foi complicar o que era simples.
Hoje eu digo que não gosto de JSF porque html já é simples o suficiente para ser componentizado. Claro, a listas e grids e e outras coisas que não são tão simples com html, mas será que essas exceções compensam essa complicação toda.
Agora me digam uma coisa: Aquele ciclo de vida infame do JSF já foi banido? Se não, muito obrigado, mas eu continuo preferindo eu aqui e ele lá.
Eu já prefiro JSF, pois como disseram aí, também não sou webdesigner, e tenho dificuldades com html/css/javascript. Pra mim fica muito mais produtivo usando componentes. Mas é claro, isso não tira a vontade ainda de aprender essas tecnologias e construir um sistema tudo action-based. Mas por enquanto, sou muito mais(++++) produtivo com JSF e não tive sérios problemas com lentidão, talvez porque fiz a coisa certa, ou pq talvez nunca fiz um sistema do mesmo porte em html/css e nem prestei atenção em sistemas action-based pra comparar.
Continuando sobre a vazão, ele comenta que o ponto alto do GWT é o compilador Java para javascript, e por isso parte da lógica pode ser executada no cliente e não no servidor. Daí ele fala que o Struts é todo server-side, e que isso é uma desvantagem. Mas espera aí, com qualquer framework action-based você pode fazer misérias no client-side e só trafegar JSON em requisições assíncronas na maioria das vezes.Não posso falar do GWT e de vários outros ali pq não conheço mas, se o GWT gera esse javascript pra vc, acredito que não seja tão simples e livre a manipulação do lado cliente. Conheço o JSF e ele não permite tanto controle assim no lado cliente, fora o overhead pra montar a árvore de componentes. No fim, atribui nota maior ao JSF que para frameworks que te deixam fazer tudo no cliente (action-based).
A manutenção de código GWT é bem mais simples do que JS, afinal vc está usando a mesma linguagem do servidor (Java), obtendo os benefícios da tipagem forte nas variáveis. Além disso, vc ganha a vantagem de o GWT otimizar e ofuscar o código JS gerado. Quer mais? O GWT é component-based, o que permite alta reutilização de código, principalmente em grandes projetos.
Veja abaixo um benchmark entre GWT e outros engines:
http://gwtquery.googlecode.com/svn/trunk/demos/gwtquery.samples.GwtQueryBench/GwtQueryBench.html
Agora me digam uma coisa: Aquele ciclo de vida infame do JSF já foi banido? Se não, muito obrigado, mas eu continuo preferindo eu aqui e ele lá.
Não foi não. Ele continua lá.
GWT é Java. Se vc já sabe Java, mais fácil aprender GWT do que JS.
Com relação ao benchmark, me mostre um independente, que não esteja ligado à Google Corporation.
Ver uma comparação do GWT a partir de uma análise da google é o mesmo que ver uma do Oracle promovido pela Oracle…
Não, dá uma olhada direito aí. O projeto só está hospedado no GoogleCode e é tocado por pessoas da comunidade.
Mais uma informação para os srs, o Vaadin (segundo colocado) usa o GWT no núcleo.
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.
O play é ótimo também na minha opinião.
Desculpe, mas se você utilizar Ajax + HTML 5 de forma incorreta, também terá um sistema moderno, porém, pesado e lento.
Eu penso que os frameworks são como as guitarras, não que uma Gibson tenha a mesma sonoridade que uma Tonante, mas se você sabe como usá-la, com certeza se sairá bem melhor que alguém que não sabe. Ou seja, talvez não seja o framework, seja a forma como se está utilizando o mesmo.
Uma coisa é certa, não existe bala de prata, nada será 100% perfeito para tudo.
Não existe bala de prata mas existe software carregado(com várias camadas que talvez sejam inúteis a determinada solução). A vantagem de se usar ajax ou javascript diretamente é que você consegue dosar a carga do servidor fazendo trafegar na rede apenas json e deixando boa parte do processamento no próprio cliente. JSF tem sobrecarga excessiva mas isso é culpa dos próprios programadores do framework. Já sofri muito tentando resolver algum bug fazendo workaround em cima desses componentes. Ele é produtivo, mas não é a solução ideal para o meu caso. Portei vários sistemas escritos em jsf (como frameworks prime, rich faces, ou algum faces da vida) para componentes escritos(customizados mesmo) pela própria empresa onde trabalho. A gente ganhou uns 30% de desempenho de tráfego, memória, processamento etc…)
Acho interessante e boa essa comparação entre frameworks, mas o Slow colocou uma questão interesante que a adoção no brasil desses frameworks. Como foi respondido JSF e Spring dominam (ainda tem muito struts por ai).Dos frameworks que conheço (Spring e VRaptor, JSF), se fosse para escolher um framework baseado na pesquisa e no mercado brasileiro eu ira de JSF com Primefaces. Eu acho ele bem produtivo (para um ambiente web) embora Spring e VRaptor deem uma flexibilidade maior em relação a implementação das views, JSF permite a construção de views por quaquer programador.
Para mim Spring e VRaptor são bons, mas é necessário a utilizção de de dois programadores ou que se encontre um muito bom em backend e frontend (não é meu caso)!
Excluindo o mercado, um que achei bastante interessante é o GWT, embora não tivesse tempo de aprende-lo ainda. Contudo acredito com ele ficaria bem dependente do CSS para ter uma interface interessante.
Essa é uma opnião pessoal. Sempre tive problemas para criar interfaces, não sou designer! Mesmo no mundo desktop, criar uma interface fluida era complicado, embora fosse bem mais simples do que utilizando HTML e CSS.
Já trabalhei com gwt e hoje utilizo dart nas minhas produções. Ambos sdks possuem um compilador de uma linguagem x para javascript além de otimizar o resultado. GWT compila java para javascript enquanto dart usa sua própria(com vários conceitos funcionais e OO).
Continuando sobre a vazão, ele comenta que o ponto alto do GWT é o compilador Java para javascript, e por isso parte da lógica pode ser executada no cliente e não no servidor. Daí ele fala que o Struts é todo server-side, e que isso é uma desvantagem. Mas espera aí, com qualquer framework action-based você pode fazer misérias no client-side e só trafegar JSON em requisições assíncronas na maioria das vezes.Não posso falar do GWT e de vários outros ali pq não conheço mas, se o GWT gera esse javascript pra vc, acredito que não seja tão simples e livre a manipulação do lado cliente. Conheço o JSF e ele não permite tanto controle assim no lado cliente, fora o overhead pra montar a árvore de componentes. No fim, atribui nota maior ao JSF que para frameworks que te deixam fazer tudo no cliente (action-based).
A manutenção de código GWT é bem mais simples do que JS, afinal vc está usando a mesma linguagem do servidor (Java), obtendo os benefícios da tipagem forte nas variáveis. Além disso, vc ganha a vantagem de o GWT otimizar e ofuscar o código JS gerado. Quer mais? O GWT é component-based, o que permite alta reutilização de código, principalmente em grandes projetos.
Veja abaixo um benchmark entre GWT e outros engines:
http://gwtquery.googlecode.com/svn/trunk/demos/gwtquery.samples.GwtQueryBench/GwtQueryBench.html
Mas isso exige conhecimento de GWT, certo? Embora seja relativamente fácil aprender, javascript (e jquery) são mais difundidos.
Com relação ao benchmark, me mostre um independente, que não esteja ligado à Google Corporation.
Ver uma comparação do GWT a partir de uma análise da google é o mesmo que ver uma do Oracle promovido pela Oracle…
Os únicos que eu conheço estão ligados à google também. Na dartlang dizem que a dartvm já bateu o v8, mas existe uma biblioteca que você pode instrumentar os seus próprios. Útil para medir a parte crítica do seu sistema
http://www.dartlang.org/articles/benchmarking/
Se olhar aqui vai ver que o v8 perde feio pra dartvm já:
Eu tive uma lição: não usar nada baseado em jsf se quiser escrever um software leve e moderno. Uso somente ajax e html5.Caracas…
O play é ótimo também na minha opinião.Desde antes de escrever o livro de JSF eu odiava esse tipo de comentário, e ainda continuo…
Pessoal acha que JSF é simples igual JSP, que basta colocar o código na tela e sair usando. Triste ver pessoas falando isso.
Foi o que eu disse sobre conhecer o framework.
A maioria reclama deste e daquele framework, sendo que sequer chegou a estudá-los, entende-los e fazer algo com eles.
O único para o qual eu dou crédito quando critica algo é o saoj, por que o sujeito vai até o último detalhe dentro do framework para entender e então falar sobre.
Eu trabalhei bom tempo com jsf e percebi que os componentes são pesados e fazem requisições demasiadas com o servidor. Percebi isso depois que passei a usar gwt porque a premissa deste é jogar tudo que possa ser feito pelo browser deve ser feito pelo browser. GWT só trafega json depois que que o cliente foi carregado. Hoje na minha opinião o dart bate todos esses porque junta a facilidade de uma ótima linguagem e um compilador. Inclusive pode-se escrever o server side com dart também.
Cara, eu era um crítico ferrenho do JSF, não gostava dele, achava complexo, com implementações mal documentadas na época que usei (richfaces), que falhava em silêncio, dava uma série de problemas relacionados a eu não saber usar (ou seja era pouco intuitivo) e com componentes complexos.O JSF 2.0 mudou muito, mas muito mesmo com relação ao 1.2.Hoje não critico mais JSF porque não trabalho mais com ele e porque não sei a quantas andam as versões atuais. Mas meu preconceito contra ele continua grande. Principalmente do ponto de vista de quem trabalha com VRaptor, que é extraordinário, na minha humilde opinião.
Mas de tanto argumentar e contra-argumentar e argumentar novamente do porque eu não gostava do JSF eu desenvolvi uma linha de raciocínio que já não sei se é valida hoje, mas com certeza era a época do JSF 1 e richfacesl. Que se baseia nos porquês de se componetizar elementos de tela. Quando você está lidando com uma aplicação desktop no Windows trabalhar os seus controles de entrada e saida de dados diretamente com a API padrão do Windows é impensável. O que foi feito com as APIs do VB e Delphi foi simplificar o acesso a API de entrada e saída de dados, com componentes bem amigáveis, intuitivos e fáceis de configurar.
Mas os componentes de entrada e saída html são extramente simples para serem simplificados, então essa componentização (na minha opinião), que começou pelo .NET e depois veio para o Java, veio para atender o hábito que a maioria dos programadores tinha de lidar com componentes ao invés de ações. Porém o que as camadas de componentes fizeram (camadas porque no fundo vira tudo em html mesmo) foi complicar o que era simples.
Hoje eu digo que não gosto de JSF porque html já é simples o suficiente para ser componentizado. Claro, a listas e grids e e outras coisas que não são tão simples com html, mas será que essas exceções compensam essa complicação toda.
Agora me digam uma coisa: Aquele ciclo de vida infame do JSF já foi banido? Se não, muito obrigado, mas eu continuo preferindo eu aqui e ele lá.
Eu odeio JSF 1.x. [=
Cara, eu era um crítico ferrenho do JSF, não gostava dele, achava complexo, com implementações mal documentadas na época que usei (richfaces), que falhava em silêncio, dava uma série de problemas relacionados a eu não saber usar (ou seja era pouco intuitivo) e com componentes complexos.O JSF 2.0 mudou muito, mas muito mesmo com relação ao 1.2.Hoje não critico mais JSF porque não trabalho mais com ele e porque não sei a quantas andam as versões atuais. Mas meu preconceito contra ele continua grande. Principalmente do ponto de vista de quem trabalha com VRaptor, que é extraordinário, na minha humilde opinião.
Mas de tanto argumentar e contra-argumentar e argumentar novamente do porque eu não gostava do JSF eu desenvolvi uma linha de raciocínio que já não sei se é valida hoje, mas com certeza era a época do JSF 1 e richfacesl. Que se baseia nos porquês de se componetizar elementos de tela. Quando você está lidando com uma aplicação desktop no Windows trabalhar os seus controles de entrada e saida de dados diretamente com a API padrão do Windows é impensável. O que foi feito com as APIs do VB e Delphi foi simplificar o acesso a API de entrada e saída de dados, com componentes bem amigáveis, intuitivos e fáceis de configurar.
Mas os componentes de entrada e saída html são extramente simples para serem simplificados, então essa componentização (na minha opinião), que começou pelo .NET e depois veio para o Java, veio para atender o hábito que a maioria dos programadores tinha de lidar com componentes ao invés de ações. Porém o que as camadas de componentes fizeram (camadas porque no fundo vira tudo em html mesmo) foi complicar o que era simples.
Hoje eu digo que não gosto de JSF porque html já é simples o suficiente para ser componentizado. Claro, a listas e grids e e outras coisas que não são tão simples com html, mas será que essas exceções compensam essa complicação toda.
Agora me digam uma coisa: Aquele ciclo de vida infame do JSF já foi banido? Se não, muito obrigado, mas eu continuo preferindo eu aqui e ele lá.
Eu odeio JSF 1.x. [=
O problema que vejo são os componentes por demais engessados.
Cara, taí… eu vou aprender GWT. Eu vi que o Vaadin usa ele no núcleo, dei uma pesquisada ontem mesmo, e pensei: poxa, talvez não seja uma má ideia.
Atualmente eu uso Spring MVC + JQuery + JSP. O poder do JQuery é fantástico, você pode criar N componentes com ele. Mas toda hora você tem que botar a mão na massa, já existem algumas coisas prontas, mas a maioria você faz na mão mesmo.
E daí eu fico pensando que ao invés de estar me preocupando com camada de negócio, estou fazendo design/página floricultura
Cara, taí… eu vou aprender GWT. Eu vi que o Vaadin usa ele no núcleo, dei uma pesquisada ontem mesmo, e pensei: poxa, talvez não seja uma má ideia.Atualmente eu uso Spring MVC + JQuery + JSP. O poder do JQuery é fantástico, você pode criar N componentes com ele. Mas toda hora você tem que botar a mão na massa, já existem algumas coisas prontas, mas a maioria você faz na mão mesmo.
E daí eu fico pensando que ao invés de estar me preocupando com camada de negócio, estou fazendo design/página floricultura
Já trabalhei com GWT e prefiro usar HTML, JS e CSS mesmo. No final das contas é pessoal, pq o resultado final do GWT com certeza tem uma performance muito boa. Mas vou de fazer meu próprio frontend e pra melhorar com algum framework JS MVC como AngularJS, Ember…
Cara, taí… eu vou aprender GWT. Eu vi que o Vaadin usa ele no núcleo, dei uma pesquisada ontem mesmo, e pensei: poxa, talvez não seja uma má ideia.Atualmente eu uso Spring MVC + JQuery + JSP. O poder do JQuery é fantástico, você pode criar N componentes com ele. Mas toda hora você tem que botar a mão na massa, já existem algumas coisas prontas, mas a maioria você faz na mão mesmo.
E daí eu fico pensando que ao invés de estar me preocupando com camada de negócio, estou fazendo design/página floriculturaJá trabalhei com GWT e prefiro usar HTML, JS e CSS mesmo. No final das contas é pessoal, pq o resultado final do GWT com certeza tem uma performance muito boa. Mas vou de fazer meu próprio frontend e pra melhorar com algum framework JS MVC como AngularJS, Ember…
sou dessa opinião também.
Concordo. O cara não estuda o framework, sai usando e faz um monte de m e sai dizendo que o framework é lento. Me lembro muito disso no hibernate. O cara dizia que era lento, que não dava para trabalhar, ai tu ia ver o código dele ele tava trazendo o banco inteiro quando carregava uma classe. Ai não tem como né!
O JSF sofre muito também devido ao 1.0 que era muito ruim.
Pessoalmente eu não conheço um que de a mesma produtividade. Claro que os componentes tem limitações, mas nada que não seja possivel resolver com JQuery. É possivel também usar ajax para evitar que a pagina seja inteiramente carregada ou enviada.
Vc conhece o VRaptor?
É como eu disse, eu tenho pessimas impressões das primeiras versões, mas como já faz tempo que parei de procurar framework web, nem vi mais o JSF. Além de que, pelo que dizem, aquele ciclo de vida ainda está lá, com seus listeners, suas fases, suas árvores de componente. Então, ainda tenho minhas dúvidas, mesmo com as implementações atuais.
Existe algum caso por aqui de alguém que experimentou o VRaptor e desistiu dele? Se sim, por que?
Pois é, as minhas opiniões não foram pra desmerecer nenhum framework. Eu só achei algumas defesas do artigo incoerentes…
E em relação ao JSF, eu entrei aqui em outro tópico há um tempo e desci a lenha, mas baseado na versão 1.2. Ela tinha tanto problema que não tive saco pra ir atrás da versão 2, e o Hebert Coelho me criticou (sabiamente, diga-se de passagem) porque estava falando mal de algo que nem tinha me disposto a conhecer.
Pois bem, fui atrás (inclusive comprei seu livro Hebert =]), estudei e vi que realmente tinha melhorado bastante…
Hj eu fico com action-based porque gosto de ter a liberdade na visão, e não acho que “esconder” a web num “desktop” seja algo tão benéfico pq tira o que o HTTP tem de melhor (ser stateless). Mas não posso negar que a versão 2 está boa e é a melhor opção pra quem migra de delphi, oracle forms e afins…
Vc conhece o VRaptor?É como eu disse, eu tenho pessimas impressões das primeiras versões, mas como já faz tempo que parei de procurar framework web, nem vi mais o JSF. Além de que, pelo que dizem, aquele ciclo de vida ainda está lá, com seus listeners, suas fases, suas árvores de componente. Então, ainda tenho minhas dúvidas, mesmo com as implementações atuais.
Existe algum caso por aqui de alguém que experimentou o VRaptor e desistiu dele? Se sim, por que?
Sim, é um ótimo framework, mas sou um péssimo “web designer”! A produtividade que digo que o JSF é em relação as views. Com ele essa tarefa se torna extremamente simples, porém se perde em flexibilidade. Já com com frameworks action based como o VRaptor eu ganho em flexibilidade no design da view, porém aumento a complexidade para cria-la.
Eu JSF permite que “programadores” criem views de forma simples e rápida. Agora se o cara é um bom designer (eu nunca conheci um programador que você), ou se ele trabalha em conjunto com um web designer o ganho em flexibilidade ganho na utilização de um framework action based supera as facilidades do JSF. O programador, nesse caso, se preocuparia apenas com o html e o javascript e deixaria o CSS a cargo do designer.
Mesmo quando apenas programadores trabalham (que para web é longe de ser recomendado), é possível ter design razoável com action based usando frameworks de front-end como Bootstrap ou JQueryUI, além de plugins JQuery para gráficos estatísticos, CSS prontos para grids, etc. Tem muita coisa pronta de design para se adaptar. De resto é mais abrir a mente para a programação web normal, se acostumar mais com HTML puro, JQuery e mais pra frente vai ver que ganhará pelo lado da liberdade. Mas não descarte um dia trabalhar em parceria com um designer nem que seja freelance, terá mais retornos assim.
Abri a página o primefaces e tirei um screen shot (em anexo).
Só teve um request disparado para buscar a página, o resto foi conteúdo estático (png, gif, etc).
E essa página é o showcase, então ele carrega tudo. Em um programa normal, não teria isso.
Ele chama a mesma classe diversas vezes enquanto produz a saída pois é o comportamento normal de component based.
Tem que saber trabalhar com isso, se não, o request fica lento, ferra com perfomance e depois a culpa vira do JSF…
Crie o seu.Cara, eu era um crítico ferrenho do JSF, não gostava dele, achava complexo, com implementações mal documentadas na época que usei (richfaces), que falhava em silêncio, dava uma série de problemas relacionados a eu não saber usar (ou seja era pouco intuitivo) e com componentes complexos.O JSF 2.0 mudou muito, mas muito mesmo com relação ao 1.2.Hoje não critico mais JSF porque não trabalho mais com ele e porque não sei a quantas andam as versões atuais. Mas meu preconceito contra ele continua grande. Principalmente do ponto de vista de quem trabalha com VRaptor, que é extraordinário, na minha humilde opinião.
Mas de tanto argumentar e contra-argumentar e argumentar novamente do porque eu não gostava do JSF eu desenvolvi uma linha de raciocínio que já não sei se é valida hoje, mas com certeza era a época do JSF 1 e richfacesl. Que se baseia nos porquês de se componetizar elementos de tela. Quando você está lidando com uma aplicação desktop no Windows trabalhar os seus controles de entrada e saida de dados diretamente com a API padrão do Windows é impensável. O que foi feito com as APIs do VB e Delphi foi simplificar o acesso a API de entrada e saída de dados, com componentes bem amigáveis, intuitivos e fáceis de configurar.
Mas os componentes de entrada e saída html são extramente simples para serem simplificados, então essa componentização (na minha opinião), que começou pelo .NET e depois veio para o Java, veio para atender o hábito que a maioria dos programadores tinha de lidar com componentes ao invés de ações. Porém o que as camadas de componentes fizeram (camadas porque no fundo vira tudo em html mesmo) foi complicar o que era simples.
Hoje eu digo que não gosto de JSF porque html já é simples o suficiente para ser componentizado. Claro, a listas e grids e e outras coisas que não são tão simples com html, mas será que essas exceções compensam essa complicação toda.
Agora me digam uma coisa: Aquele ciclo de vida infame do JSF já foi banido? Se não, muito obrigado, mas eu continuo preferindo eu aqui e ele lá.
Eu odeio JSF 1.x. [=
O problema que vejo são os componentes por demais engessados.
Pois é, as minhas opiniões não foram pra desmerecer nenhum framework. Eu só achei algumas defesas do artigo incoerentes…Opa, valeu pela força.E em relação ao JSF, eu entrei aqui em outro tópico há um tempo e desci a lenha, mas baseado na versão 1.2. Ela tinha tanto problema que não tive saco pra ir atrás da versão 2, e o Hebert Coelho me criticou (sabiamente, diga-se de passagem) porque estava falando mal de algo que nem tinha me disposto a conhecer.
Pois bem, fui atrás (inclusive comprei seu livro Hebert =]), estudei e vi que realmente tinha melhorado bastante…
Hj eu fico com action-based porque gosto de ter a liberdade na visão, e não acho que “esconder” a web num “desktop” seja algo tão benéfico pq tira o que o HTTP tem de melhor (ser stateless). Mas não posso negar que a versão 2 está boa e é a melhor opção pra quem migra de delphi, oracle forms e afins…
Só um detalhe. Já está disponível nas novas versões do JSF a opção de deixá-lo stateles. =D
Crie o seu.
Se você faz algo com Struts, Spring MVC vc usa algum componente css pronto ou então faz na unha. Pq que com JSF seria diferente?
Mas eu faço isso. Crio todos. Inclusive aquele componente de captura de vídeo que postei feito em dart que você comentou.
No seu exemplo acima, experimenta usar o componente e clicar na aba network. Dai me fala .
Fora que existem gargalos na renderização de componentes como alguns do primefaces como mostra o screenshot abaixo.
