Mais uma comparação entre frameworks web

[quote=Hebert Coelho][quote=juliocbq]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.[/quote]Caracas…

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

[quote=drsmachado]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.[/quote]Pois é, eu também concordo com você.

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.

[quote=bob_sponja]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).[/quote]

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

[quote=Hebert Coelho][quote=drsmachado]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.[/quote]Pois é, eu também concordo com você.

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

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.

[quote=andre_salvati][quote=bob_sponja]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).[/quote]

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[/quote]
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…

[quote=YvGa]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á.
[/quote]

Não foi não. Ele continua lá.

GWT é Java. Se vc já sabe Java, mais fácil aprender GWT do que JS.

[quote=drsmachado]
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…[/quote]

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.

[quote=drsmachado][quote=juliocbq]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.[/quote]
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.[/quote]

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…)

[quote=x@ndy]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.[/quote]

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).

[quote=drsmachado][quote=andre_salvati][quote=bob_sponja]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).[/quote]

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[/quote]
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…[/quote]

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

http://www.dartlang.org/performance/

[quote=drsmachado][quote=Hebert Coelho][quote=juliocbq]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.[/quote]Caracas…

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

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.

[quote=YvGa]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á.
[/quote]O JSF 2.0 mudou muito, mas muito mesmo com relação ao 1.2.

Eu odeio JSF 1.x. [=

[quote=Hebert Coelho][quote=YvGa]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á.
[/quote]O JSF 2.0 mudou muito, mas muito mesmo com relação ao 1.2.

Eu odeio JSF 1.x. [=[/quote]

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

[quote=jaboot]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[/quote]

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…

[quote=fredericomaia10][quote=jaboot]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[/quote]

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…[/quote]

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…