[quote=Fabio_Barboza]Não costumo participar de floods ou alimentar bate bocas, mas confesso que é revoltante ver alguem condenar uma tecnologia por pura inexperiência.
O JSF assim como o Java é uma tecnologia aberta e a evolução dela depende de todos nós, seria um tanto estranho acreditar que o JSF foi criado por apenas UMA pessoa e que ela fosse uma “toupeira” a ponto de fazer um framework tão ruim a ponto de ter se tornado o framework padrão da especificação.
Apesar de achar errado, qualquer um que queira criticar alguma coisa, que pelo menos se mantenha atualizado sobre o assunto para não acabar fazendo papel de bobo.
Fábio
[/quote]
Oi Fabio, eu trabalhei com 2 projetos de grande porte com JSF 2. Li livros de capa a contra capa a respeito do JSF 2. E confesso que sofre e me frustei com JSF: http://guj.com.br/java/236788-crise-com-jsf/
Infelizmente, por mais que seja especificação, o problema do JSF (1 ou 2) está na sua filosofia Component-Based. Por mais que ela evolua, e fique boa, ao utilizá-la, sempre estaremos presos aos componentes . E como o asaudate disse, os componentes vem em uma caixa-preta. Ao usar JSF, não temos muito domínio de Html, Css e JS, faz uma sopa de mistura com Cliente e Server. Ficamos dependente de terceiros (Prime, Rich, Open e cia.), além de alguns bugs misteriosos e problemas de performance.
Quanto ao SEAM 3.0 boa notícia para quem insiste ou é obrigado usar JSF.
Concordo com o fábio, as vezes é mais fácil criticar algo que não conhecemos do que entender como as coisas realmente funcionam, procurar se interar a respeito das capacidades, caracteristicas e pontos fortes de determinada ferramenta ou tecnologia. Falhas todo software/framework possui, isso é fato, não existe software perfeito. Mas também vale lembrar que o JSF é especificação e não se tornou especificação so porque acharam o negócio bonito, porque encontraram muitas caracteristicas que podiam beneficiar e facilitar a vida de muita gente. E o Seam segue a mesma linha, foi a primeira implementação de referência para o que veio se tornar o CDI. Além de Wicket e Gwt também você pode usar flex se preferir ou até mesmo jsp puro. Vai do gosto do freguês. Se não quiser usar ejb também pode-se usar spring, vai do seu gosto e das suas necessidades como desenvolvedor em atender o seu cliente.
[quote=Lucas Emanuel][quote=Fabio_Barboza]Não costumo participar de floods ou alimentar bate bocas, mas confesso que é revoltante ver alguem condenar uma tecnologia por pura inexperiência.
O JSF assim como o Java é uma tecnologia aberta e a evolução dela depende de todos nós, seria um tanto estranho acreditar que o JSF foi criado por apenas UMA pessoa e que ela fosse uma “toupeira” a ponto de fazer um framework tão ruim a ponto de ter se tornado o framework padrão da especificação.
Apesar de achar errado, qualquer um que queira criticar alguma coisa, que pelo menos se mantenha atualizado sobre o assunto para não acabar fazendo papel de bobo.
Fábio
[/quote]
Oi Fabio, eu trabalhei com 2 projetos de grande porte com JSF 2. Li livros de capa a contra capa a respeito do JSF 2. E confesso que sofre e me frustei com JSF: http://guj.com.br/java/236788-crise-com-jsf/
Infelizmente, por mais que seja especificação, o problema do JSF (1 ou 2) está na sua filosofia Component-Based. Por mais que ela evolua, e fique boa, ao utilizá-la, sempre estaremos presos aos componentes . E como o asaudate disse, os componentes vem em uma caixa-preta. Ao usar JSF, não temos muito domínio de Html, Css e JS, faz uma sopa de mistura com Cliente e Server. Ficamos dependente de terceiros (Prime, Rich, Open e cia.), além de alguns bugs misteriosos e problemas de performance.
Quanto ao SEAM 3.0 boa notícia para quem insiste ou é obrigado usar JSF.
[/quote]
Oi Lucas,
Problemas com alguma lignuagem/framweork são muito relativos.
Quando eu comecei com o JSF/Richfaces também tive muitos problemas, pensei até em desistir e correr para outro framework, concordo que tinham alguns problemas mas eram contornáveis.
Hoje eu posso afirmar que conheço muito bem a tecnologia e que não trocaria por nenhuma outra. No MEU ponto de vista, trabalhar a base de componentes é o ideal (Pode ser que daqui a algum tempo mude).
Eu pessoalmente não gosto de Struts e GWT, tive más experiências com ambos principalmente na hora de dar manutenção em código alheio, mas não acho que eles sejam frameworks ruins.
E mais, MUITAS da features que eram do Seam foram incoporadas ao JSF 2 / EE 6. Exs: Contexto de conversação, declaração de managedbeans por annotation e o CDI.
Resumindo, é tudo uma questão de gosto, o que eu não acho legal e ficar sujando a imagem de outras tecnologias.
O Prime, Rich e Open Faces são tão “caixa-preta” quanto o jquery, yui, etc. Não vejo nenhum problema em utilizar “caixa-preta” desde que ela cumpra o que promete. Antes de começar qualquer projeto, em qualquer tecnologia, sempre temos que homologar os componentes que serão utilizados. E em caso de problemas, nada impede de abrirmos a “caixa-preta” e corrigirmos eventuais problemas e colaborar com o crescimento da tecnologia.
Acredito que JSF resolve bem o que se propõe. É para todos casos? Resolve todos os problemas? Óbvio que não, mas é uma excelente opção para certos cenários.
Na minha opinião, o conceito de “caixa-preta” é relativo. Tem que ter muito bom senso para pesar bem: controle do código, produtividade, utilização de bibliotecas de terceiros, etc. No final, sempre a melhor resposta é: depende. Cada caso é um caso.
[quote=“asaudate”]Do aspecto não funcional, tem a performance e capacidade. Um exemplo é um bug que foi reportado recentemente que dizia que uma sessão Ajax4JSF consumia 10 MB por cliente. (Não gostaria de imaginar um código desses indo para produção…). Além disso, pelo fato de cada página ficar extremamente carregada com javascript + html gerado pelo próprio JSF, as páginas podem levar muito tempo para serem produzidas e enviadas pela rede. O que faz de JSF uma carroça.
EDIT: ah, e acabei de lembrar, também - JSF complica a vida de quem quer usar um javascript próprio para manipulação de um componente qualquer. Ou seja, os componentes JSF que vêm com as bibliotecas são todos do tipo caixa-preta.
Do aspecto prático, tem o desenvolvimento de componentes: quem já tentou desenvolver um componente sabe que é super complicado ter que desenvolver um componente, porque é preciso editar vários arquivos de configuração, estender várias classes, etc. Sem contar que o desenvolvimento pra uma versão de JSF nem sempre vai se aplicar a uma próxima versão. Só pra exemplificar, o primeiro componente JSF que desenvolví foi um simples componente para controle de datas (o da biblioteca que a gente usava, na época, não era suportado por uma versão de browser que nós precisávamos). Foi um pesadelo de três dias.
Pra finalizar, tem aquele ciclo de vida dele. Completamente não prático, cada vez que fazemos uma requisição, ele precisa desencadear todo um processamento só por causa do ciclo de vida. E note que não é por ser component-based, já que outros frameworks orientados a componentes, como o Wicket, não precisam realizar todo esse processamento de ciclo de vida.
Então, resumindo: por esses motivos, JSF é um problema para o cliente, para o desenvolvedor e para o arquiteto.[/quote]
De fato, seus pontos condiz com a realidade do framework, e sempre soube disso.
Não é negável que ele é pesado, talvez para aplicações com milhares de acessos ao mesmo tempo, ele possa se tornar uma tecnologia inviável, pois gera uma quantidade absurda de código para gerenciar seus recursos de componentização.
É o preço que pagamos por ter componentes poderosos sendo incorporados facilmente nas aplicações. Nos abstrae de muita lógica, inclusive, muitos css e javascripts (que pode ser very boring), mas é pesado, ineficiente para sites, bom para sistemas e com ciclo de vida confuso.
o povo ta misturando as coisas… vocês chamam de pesado isso e aquilo, javascript aos quilos por que o prime isso o richfaces aquilo, mas vocês esquecem que essas bibliotecas não são parte da especificação, são algo que alguém(uma empresa) criou para facilitar a vida dos programadores(que acham bonitinho e vão usando de qualquer jeito).
JSF pode ser usado com componentes que você mesmo pode criar, vai de você criar um componente bom ou não.
** Edited
feito em JSF, tem muito acesso, é o parceiro do banco do brasil e renderiza rápido a dar com o pau, ou seja, existe prova que algo bem feito fica bom.
pegue um livro, estude, e aprenda a utilizar a framework/tecnologia de maneira correta, não importa qual seja.
sem mais.
[quote=rodriguezrps]o povo ta misturando as coisas… vocês chamam de pesado isso e aquilo, javascript aos quilos por que o prime isso o richfaces aquilo, mas vocês esquecem que essas bibliotecas não são parte da especificação, são algo que alguém(uma empresa) criou para facilitar a vida dos programadores(que acham bonitinho e vão usando de qualquer jeito).
JSF pode ser usado com componentes que você mesmo pode criar, vai de você criar um componente bom ou não.
** Edited
feito em JSF, tem muito acesso, é o parceiro do banco do brasil e renderiza rápido a dar com o pau, ou seja, existe prova que algo bem feito fica bom.
pegue um livro, estude, e aprenda a utilizar a framework/tecnologia de maneira correta, não importa qual seja.
sem mais.[/quote]
Aham. 162 kb só de texto na primeira página (note que eu fiz a contagem só do texto, ou seja, com recursos importados, como CSS/imagens/javascript fica ainda mais pesado). Multiplique 162 kb, por, digamos, 100 usuários em uma hora (estou chutando até baixo). Isso dá 16 MB de transferência em uma hora. Considere o dia inteiro (como eu chutei baixo pra uma hora, acho justo desconsiderar picos de acesso, para efeito de cálculo). Dá 390 MB. De texto. E você vem me falar que foi bem feito?
Pegue então a latência de transferência pros roteadores, o custo de fazer o processamento disso no firewall, o custo do processamento disso no web server e no application server e… ixe, eu acho melhor migrar pra JSP ou outros frameworks que não precisam disso (como o Play, Ruby/Rails, Grails…).
Note que eu não falei, em momento algum da minha explicação, que usei porque era bonitinho. Também acho que não demonstrei inexperiência com o framework (exceto na parte em que disse que não conheço JSF 2. Eu procuro ser honesto na minha visão sobre as coisas, sabe?).
De qualquer maneira, muitas pessoas não gostam de JSF. E isso tem motivos. E não pensem vocês que só porque uma especificação é feita que a gente deve abraçar cegamente (afinal de contas, duvido que alguém aqui tenha argumentos pra defender, por exemplo, EJB 1 ou 2).
Meus caros, peço a vocês que tenham visão crítica das coisas. Não somente sair por aí abraçando porque alguém falou que é bom (ou que é ruim - ou seja, não vou tentar convencê-los do contrário; espero somente que a minha visão seja respeitada, assim como eu respeito a de vocês). Corram atrás. Procurem checar se o que eu falei é verdade. Eu disse que não conhecço JSF 2, vocês dissem que conhecem. OK, vocês têm benchmarks para mostrar? O rodriguezrps disse que o comprafacil é usado por muitos usuários. Quantos são “muitos usuários” ? Tem picos de acesso? Quantos servidores são usados para atender essa demanda?
Peço a vocês, novamente, que não tomem tudo como verdade, mas sim que analisem os fatos.
Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.
Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.
Abs,[/quote]
Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).
Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?
Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.
Abs,[/quote]
Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).
Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?[/quote]
Realmente, mas acho que em relação ao compra fácil pouco tem haver com o fato de ser JSF. Com o Firebug percebe-se que os maiores “vilões” são os SWFs (Flash).
Triste é a plataforma de software que tem em um framework como o JBoss Seam (“costura” em inglês, sabe, tipo aquelas das fantasias de São João…) como sua referência de alta tecnologia e do melhor que há para seu desenvolvimento.
Triste é o fórum de discussão da web em que usuários “não querem alimentar bate bocas” mas rebaixam o argumento dos outros classificando-os como “falta de experiência”, e que seus argumentadores estão “fazendo papel de bobo”.
[quote=asaudate]
Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).
Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?[/quote]
Ta, estou chegando agora, não disse nada sobre nenhum, mas gostaria de ver o seguinte, pegue outro site com ± a mesma carga e cheio de parafernalhas que o comprafacil, porem feito em outra coisa, sei la: rails, vraptor, struts, aspx, e faça este mesmo teste que voce fez, bora ver o q da!
Sei la? que sites temos ae? Alguem sabe em q é feito shoptime, americanas, submarino, polishop, magazineluiza, etc, etc. Bora testar e ver os resultados. Testar apenas um, olhar os valores e achar altos, puramente por achar, sem comparar com outros, acho sem noção! E não é pra comparar com “meu sitezinho feito em vRapror”, nao, vamos comparar estes grandes portais!!
E só pra constar, sem levar em conta que seja feito em JSF ou action based, eu acho sim o compra facil bem acessado, inclusive ele tem programas com empresas e tals.
Por que as pessoas ficam ofendidas quando se fala mal do JSF? Parece até que está fazendo uma coisa errada. Eu vou além, sugiro que somente as pessoas que gostem desta tecnologia tenham o direito de trabalhar. Já o resto, da noite pro dia virou um bando de bundão, não acompanhou a evolução “natural” do desenvolvimento de sistemas e, por isso mesmo, por serem tratados como estagnados deveriam mudar de área.
De fato essa gororoba Seam é o que torna JSF viável. Propositalmente, igual acontece com a placa-mae e o processador, um completa o outro. JSF é puro marketing, sem qualquer novidade, a velha história de criar dificuldade para vender facilidade. Foi o jeito que a Head Ret encontrou para entrar no mercado de desenvolvimento de sistemas. Como seria competitivo se continuasse com JSP? Spring e struts 2.
A “facilidade”, “flexibilidade” e “agilidade” se resumem a uma tela de 3 a 4 controles, e termina por ai, o resto é workaround. JSF é uma mistura de egoísmo e arrogância: Somente Nick Belaevski é sábio o bastante para utilizar JavaScript na camada de apresentação, nenhum outro programador é capaz de utilizar esta linguagem de forma responsável.
A criação de novos componentes JSF deveria vir com letras grandes “NÃO TENTE FAZER ISSO EM CASA”. De fato, a criação de um componente envolve uma babozeira tão absurda que desencoraja qualquer tentativa.
É a maldição dessas revistinhas JAVA. Se um dia publicarem que esfregar cocô na careca faz nascer cabelo, todo mundo vai querer usar.
Alguém sabe se em um projeto usando: JSF 2 + Spring + Hibernate + Primefaces, com o spring resolvendo as ELs e injetando os services nos ManagedBean, o SEAM teria alguma função?
Da mesma forma que muitos ficam ofendidos quando alguém fala que gosta ou que vê vantagens. Nada mais é que briga de egos, se a pessoa prefere um framework, quer se justificar depreciando os outros ou quem prefere outro, não aceitam opinião diferente. Não sei se é insegurança por não conseguir trabalhar bem de outra forma da que está acostumado, se é pra dar uma de esperto ou por briga de egos, mas isso é muito comum por aqui.
Particularmente, nunca vi todos esses problemas com JSF, minhas páginas nunca ficaram “extremamente” grandes e nunca achei a criação de componentes tão complexa assim como o pessoal postou, trabalhar com javascript nele tem o mesmo trabalho do que com outros frameworks. E está cheio de empresas que ganham uma produtividade absurda com a componentização de seus sistemas.
Aliás, até fico admirado do tanto de gente que trabalha um bom tempo com Java e acha difícil criar componentes com JSF ou vê isso como uma “caixa preta”.
Concordo em gênero, número e grau com o Marcos. E, por incrível que pareça, com o JEE 6 a adoção do Seam é até questionável. Perguntas que chovem nas listas do seam hoje são sempre assim: “Seam or JEE 6 only?”. Boa parte das idéias do Seam 2 foram incorporadas ao JEE 6. O Seam 3 só constrói alguns módulos “periféricos” totalmente opcionais, por isso que não acredito que ele vai ter o mesmo boom que teve no JEE 5. Boa parte dos problemas do JSF 1.x era devido a integração com JSP, por isso que a criação de componentes era relativamente trabalhosa (não digo difícil). O JSF 2 utiliza facelets e fazer componentes ficou trivial, qualquer desenvolvedor que trabalhe com xhtml faz um rapidinho. Praticamente, grosseiramente falando, está bem semelhante a desenvolver taglibs no JSP.
Aconselho para quem quiser aprender mais sobre o JSF 2, sem preconceitos, fazer a leitura desse material:
[quote=ranophoenix][quote=asaudate][quote=ranophoenix]Um artigo que acho bastante relevante nessas discussões sobre perfomance, benchmarks, desempenho, etc:
Concordo com o que asaudate disse, evitem acreditar em qualquer coisa, seja de quem for e, principalmente, evitem os preconceitos. Tenham bom senso acima de tudo, conheçam o máximo (e quem sabe ao máximo) o maior número de tecnologias possível e escolham a mais adequada para o cenário em questão.
Abs,[/quote]
Aliás, por falar em benchmarks, fiz um testezinho rápido em cima do comprafacil.com.br. Simulei cinco usuários simultâneos, fazendo requests pra página inicial, durante um minuto. O tempo médio de resposta foi 733,32 ms, com 32.471.239 bytes transferidos no total (~ 32 MB), sendo 540 KB de transferência média, por segundo. Além disso, o tempo máximo de resposta 3472 ms (3 segundos e meio).
Vocês não acham que cinco usuários simultâneos, durante um minuto só, é um valor para testes muito baixo para ter valores de resposta tão altos?[/quote]
Realmente, mas acho que em relação ao compra fácil pouco tem haver com o fato de ser JSF. Com o Firebug percebe-se que os maiores “vilões” são os SWFs (Flash). [/quote]
O teste que eu fiz puxava somente o texto. Lembra o que eu falei, só de texto são 160 KB? Não precisei fazer o teste puxar tudo pra ter esses tempos absurdos.
Da mesma forma que muitos ficam ofendidos quando alguém fala que gosta ou que vê vantagens. Nada mais é que briga de egos, se a pessoa prefere um framework, quer se justificar depreciando os outros ou quem prefere outro, não aceitam opinião diferente. Não sei se é insegurança por não conseguir trabalhar bem de outra forma da que está acostumado, se é pra dar uma de esperto ou por briga de egos, mas isso é muito comum por aqui.
Particularmente, nunca vi todos esses problemas com JSF, minhas páginas nunca ficaram “extremamente” grandes e nunca achei a criação de componentes tão complexa assim como o pessoal postou, trabalhar com javascript nele tem o mesmo trabalho do que com outros frameworks. E está cheio de empresas que ganham uma produtividade absurda com a componentização de seus sistemas.
Aliás, até fico admirado do tanto de gente que trabalha um bom tempo com Java e acha difícil criar componentes com JSF ou vê isso como uma “caixa preta”.
[/quote]
Concordo contigo, Marcos. A idéia de mostrar o benchmark do comprafacil foi feita porque algumas pessoas, na hora de defender uma argumentação, falam que é porque outras não tem “experiência suficiente” para fazer uma colocação. Como falaram pra mim que o tal do comprafacil é um exemplo bem feito, fiz o benchmark (e, repito, somente puxando o texto) para demonstrar que o que é bem feito do ponto de vista do usuário pode ser um pesadelo pro administrador do sistema, por exemplo (tenho certeza que o tal do comprafacil está hospedado em uma farm gigante!).
Mas não tenho nenhum problema com quem trabalha com isso. Oras, eu mesmo trabalho mais com JSF do que com outras tecnologias. É uma questão de gosto.
A quem falou de fazer outros benchmarks, aviso que tentei fazer com o UOL. Só que a minha ferramenta de testes tem um drawback de só fazer POST (o comprafacil devolve a página inteira mesmo quando a requisição é POST… ). Ficaria feliz de aplicar o mesmo teste em sites feitos com outras tecnologias, só pra ter uma base de comparação.
Eu reconheço o lado positivo e negativo da tecnologia JSF. Nunca achei que ele fosse resolver todos os problemas web, e de fato, não resolve. Também não concordo com o ponto de vista de ele ser sempre uma tecnologia mal vista, onde não serve nem para sistemas quanto sites.
Acredito que o maior mérito seja o poder de permitir várias implementações com vários recursos já on built, porém, como eu disse antes, isso tem um preço. Por mais que se crie novas implementações não há como fugir do core do JSF, a especificação deve ser seguida, e queira ou não, os componentes ainda se tornarão pesados.
Eu mesmo, fui desenvoler um projeto para minha mulher para ela melhor organizar seus estudos, já que o concurso que ela está estudando demanda de muitos assuntos, muito tempo e muitas matérias a serem estudadas.
Resolvi criar um sistema, e acabei optando por RichFaces em detrimento ao Play Framework pelo simples fato de eu saber mexer com jQuery e não querer perder muito tempo em css e design. E como é um projeto pessoal, onde dificilmente irá sair do nosso escopo caseiro, então preferi usar essa mesma tecnologia que já conhecia e facilmente consigo adaptar as coisas nela.
Obviamente que sei de suas limitações, sei que JSF é tosco se você quiser forcá-lo a usar um outro padrão de layout, sei que ele é chato de trabalhar com outros frameworks de JavaScript, sei que ele é pesado, mas está me atendendo muito bem para um projeto pessoal.
Mas acredito que jamais iria querer usá-lo num projeto grande que fosse um site, as suas desvantagens iriam pessar muito mais, e poderia tornar o projeto inviável.
Site exige leveza, fácil customização, processamento rápido e objetivo, e isso, o JSF não consegue atender de forma eficiente, e na verdade, esse nunca foi o objetivo dele.
Não quero aqui tirar o mérito de nenhum framework, acho que o próprio JSF (ainda mais na versão 2) tem suas vantagens, a questão é quando saber usá-lo. Não se pode querer que ele atenda a tudo e a qualquer tipo de projeto e especificação, é saber conhecer para que tipo de situação ele demanda e trabalha melhor.