TechRadar da Throughworks fala para evitar JSF

[Paulo Jr.]

O já conhecido radar de tecnologias da Thoughtworks (tão conhecido por ter a participação direta do Martin Fowler) sai falando para evitar JSF. Veja: http://thoughtworks.fileburst.com/assets/technology-radar-jan-2014-pt.pdf

Segue o trecho sobre os motivos para a recomendação:

Nós continuamos vendo equipes enfrentando problemas com o 
JSF – JavaServer Faces – e recomendamos evitar essa tecnologia. 
As equipes parecem escolher o JSF por ser um padrão J2EE, sem 
realmente avaliar se o modelo de programação é conveniente. 
Achamos que o JSF possui falhas porque tenta abstrair o 
HTML, o CSS e o HTTP, exatamente o oposto do que fazem 
os frameworks web modernos. O JSF, assim como o ASP.NET 
webforms, tenta criar estado persistente em cima do protocolo 
HTTP, que não possui estado, o que acaba gerando uma série 
de problemas envolvendo o estado compartilhado do lado 
do servidor. Nós estamos conscientes das melhorias no JSF 
2.0, mas achamos que o modelo é fundamentalmente falho. 
Recomendamos que as equipes utilizem frameworks simples, 
abracem e compreendam as tecnologias da web, incluindo o 
HTTP, o HTML e o CSS.

Se não olhou o radar, dê uma olhada. Vale a pena ver o que os caras recomendam, bem legal. :)

Abraço,

--

Paulo Alves Junior

Twitter: @paulojribp
Instrutor - Caelum | Ensino e Inovação

JugLeader CEJUG

Hurraa - OpenSource project to resource management

[Stanley Albuquerque]

Acho o JSF bom para casos específicos, eu fico longe de JSF para projetos que você não sabe por quem e pelo que o projeto será acessado.

Ainda acho que o spring mvc uma solução melhor, mas cada caso é um caso.

[Efraim Gentil]

Também acho muito mais construtivo usar um framework action based, não estou dizendo que o JSF sejá ruim,  já usei bastante e ainda hoje uso no trabalho,  mas acredito que ele deva ser usado para soluções bem especificas, com certeza adiciona facilidades fantásticas viewScoped é lindo! mas adicionar N outras complexidades e conhecimentos específicos necessários.

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para cejug+un...@googlegroups.com.
Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--

Atenciosamente,

Efraim Gentil - @efraimgentil

Github

LinkedIn

[Flavio Cysne]

Desde que comecei a trabalhar com testes de desempenho eu tenho me desencantado cada vez mais com os frameworks para gerar interfaces como o JSF ou o .NET.

Muito por culpa de quem os usam, já que por facilitarem a programação das interfaces acabam por fazer o esquema do Next-Next-Next e não se preocupam com as melhores práticas.

Os frameworks JSF (também os .NET e os outros) não são tão responsivos. Querendo ou não eles vão gerar lixo. Alguns mais outros menos, dependendo de como são utilizados.

Na era em que estamos em que cada byte transferido a ser processado pelo dispositivos conta (voltando à época da linha discada) é importante se ater às boas práticas.

HTML5, CSS3 e as melhorias nos motores de Javascript dos novos browsers e até mesmo a melhoria nos frameworks JS acrescentaram uma grande força nesse ponto.

A grande questão desses frameworks, como o JSF e o .NET, são a facilidade agregada ao desenvolvimento rápido. Isso é um ponto positivo, mas em grande parte é a culpada pela falta de conhecimento dos menos afoitos em conhecer a fundo o poder dos HTML5, CCS3, JS e HTTP podem suprir quando usados corretamente (considerando apenas a parte visual).

Outra coisa é o atual cenário no uso de computação em nuvem em aplicações 'parrudas'. A maneira antiga de fazer aplicações com JSF e .NET, por exemplo, não se adequa a isto apenas por rodar em um ambiente de nuvem. Pode até rodar, mas não vai aproveitar o potencial da nuvem. E aqui, usar estes frameworks, já não é só um ponto negativo p/ a interface, mas para a aplicação como um todo.

[helio frota]

Valeu por compartilhar Paulo !

Concordo com esse texto e com os comentários do @Stanley, @Efraim e @Flavio.

--

Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para cejug+un...@googlegroups.com.
Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--

* cejug committer - hurraa
* cejug committer - footprint

[Carlos Mendes]

Ótima leitura. Nunca mais tinha lido o radar da Throughworks. Valeu, Paulo.

Flavio, 

Concordo com você :), mas só uma correção: quando você se refere ao .NET, você quer dizer ASP.NET Web Forms (http://www.asp.net/web-forms), que é algo equivalente ao JSF. 

--
Carlos Mendes

[Hildeberto Mendonca]

Eu sou um usuário feliz de JSF. Esta é uma daquelas tecnologias que foi criada muito antes de todos of frameworks da moda hoje em dia e continua evoluindo para não deixar os seus milhares de usuários na mão. Não se evaporou como o Struts ou deixou de evoluir como o GWT. Nunca se sabe qual dos frameworks da moda vai deixá-lo na mão e forçá-lo a migrar para outras tecnologias. JSF certamente não é um desses.

O irônico disso tudo é que o JSF evolui no sentido da sua auto-destruição. Ou seja, quanto mais o JSF suporta HTML 5, mais ele deixa de ser JSF. Por exemplo, no Java EE 6, eu não poderia imaginar uma aplicação JSF sem usar dezenas de componentes do Primefaces. Hoje em dia, com Java EE 7, já estou encontrando oportunidades de substituir quase todos os componentes.

Por fim, eu gostaria de conhecer alguém que já reuniu um público tão grande em torno de uma aplicação que ela não poderia ser escrita em JSF porque senão não aguentaria. Vocês devem conhecer, mais eu não conheço. A grande maioria dos sistemas não tem essa necessidade. Na verdade, o servidor de banco de dados representa um gargalo muito mais sério do que o estado do JSF. O preço de hardware é ínfimo para suportar milhares de usuários simultaneamente. Como JSF tem foco no mundo corportativo, não creio que seja um problema.

Usar ou não usar JSF é o mesmo estilo de discussão de usar ou não usar banco de dados relacional. Toda tecnologia tem seu posicionamento. Toda tecnologia que evolui deve ser respeitada. Julgar negativamente JSF só porque ele tenta respeitar o legado e evoluir a partir de um modelo que todos aqui respeitavam no passado é injusto.

[helio frota]

O irônico disso tudo é que o JSF evolui no sentido da sua auto-destruição. Ou seja, quanto mais o JSF suporta HTML 5, mais ele deixa de ser JSF. Por exemplo, no Java EE 6, eu não poderia imaginar uma aplicação JSF sem usar dezenas de componentes do Primefaces. Hoje em dia, com Java EE 7, já estou encontrando oportunidades de substituir quase todos os componentes.

+1

Toda tecnologia que evolui deve ser respeitada

+1

Como JSF tem foco no mundo corportativo, não creio que seja um problema.

+1

Resolve problemas onde trabalho inclusive. Não estamos escrevendo mais javascript. Isso significa que não precisamos nos preocupar com uma linguagem de programação a mais para entregar os projetos.

E continuo concordando com o texto e com os demais comentários. Comparar com A, B e C é sem sentido. Conhecer os pontos fracos e fortes é a parte interessante do ponto de vista.

Eu não gosto de JSF mas não é uma tecnologia ruim (na minha opinião particular) exatamente pelos fatores que você citou.

Mais uma vez, texto bacana o seu Hildeberto.

[helio frota]

Analogia meio bruta...

É como o delphi no Cariri ( crato, jua, barbalha )

O feedback que tenho de pessoas é que não tem Java desktop que tire o delphi de lá ou resolva os problemas da forma que o delphi resolve.

Se tiver alguém da região que fale o contrário por favor se pronuncie porque desde 2006, (8 anos atrás) até onde eu sei, é "o que há" na região.

duvido o caba sobreviver por lá só com "Scala desktop" : ]]

[Antonio Armando Couto Bem Filho]

O problema foi que o JSF foi feito para aplicações locais, o grande problema é que inventam de fazer aplicações que não são locais.

JSF é muito pesado, e se não for local fica muito lento e consequentemente pesado.

Att

Antonio Armando Filho Couto Bem

www.armandocouto.com.br

[Carlos Mendes]

Helio,

Lá no Cariri o Delphi ainda tem muita força, mas aqui em Fortaleza também tem empresas, algumas do grupo Fortes, que a usam e são usuários felizes.

--
Carlos Mendes

[Levy Moreira]

Helio, na realidade o que vejo é seguinte, o que rola lá são programas para controle de estoque com emissão de NFe e emissão de Cupom Fiscal.

Logo com o Delphi temos o ACBR, um componente que já tem "pronto" toda a parte de emissão de NFe e cupons fiscais. 

Juntando isso a rapidez com que se desenvolve em delphi (a maioria, não todos, mas a maioria nunca escreveu uma linha de delphi orientado a objetos) com o bom e velho clica arrasta conecta ali e ta pronto, ele se torna uma ferramenta perfeita para esse cenário. 

Com isso realmente não hã como bater o delphi nas duas ou três principais concorrentes de lá.

Contudo se o Java tivesse um framework rico e atualizado como o ACBR , não tenho a menor duvida que ele seria utilizado por todas empresas, visto que as faculdades de lá ensinam java, o que tornaria a mão de obra para essas empresas fácil de se conseguir e mais barata. Não me recordo a quantidade de estagiários que ensinei delphi quando só sabiam o básico do java (swing no netbeans praticamente), alguns nunca ouviram falar em delphi ser OO e todo potencial do datasnap e etc.

Esse cenário se contraria completamente ao que estou agora em Fortaleza por exemplo, seria sem logica criar varios projetos que funcionam com 50 ou mais terminais, com delphi. Tento em vista dar suporte a webservices (tanto produzir como consumir), assinatura digital especifica para o ramo médico, acesso através de tablets,  acesso ao sistema sem necessidade de instalação e por ai vai. 

Contudo mesmo assim alguns projetos piloto são sim desenvolvidos em java,  aumenos nas duas principais concorrentes, um dos quais tive o prazer de participar.

O mesmo caso ocorre na lista de discurção de delphi, mudar ou não pra java, continuar ou não com o firebird... 

Em fim fica aquela questão se Java com JSF, Delphi ou qualquer outra liguagem esta suprindo todas suas necessidades, desde performace a profissionais no mercado, por qual razão iria migrar minhas aplicações? 

Hoje possuo tanto aplicações delphi, quanto java e vejo claramente que a frase "Não existe bala de prata" até agora não deixa de esta certa. 

Desculpe por me prolongar. 

[helio frota]

Lá no Cariri o Delphi ainda tem muita força, mas aqui em Fortaleza também tem empresas, algumas do grupo Fortes, que a usam e são usuários felizes.

Esse cenário se contraria completamente ao que estou agora em Fortaleza por exemplo,

Então consegui passar minha mensagem : ]

Ou seja depende da realidade.

"Nós continuamos vendo equipes enfrentando problemas com o 

JSF – JavaServer Faces – e recomendamos evitar essa tecnologia."

O "nós" são "eles", realidade deles.

O texto é bom mas depende : ]

Por isso concordei com o texto e com os comentários.

Se o texto falasse mal do delphi , isso não poderia ser aplicado ao Cariri que conhecemos e/ou a Fortes como o Carlos citou.

Ou seja, foi uma generalização, é a mesma coisa de dizer "Próximo ano pode ser o fim do mundo".

Vou batizar como "JuscelinoDaLuzPattern"

--

Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para cejug+un...@googlegroups.com.
Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

[Hildeberto Mendonça Filho]

Eu entendo o que o Hélio quis dizer sobre contexto (realidade) quando mencionou o Delphi em comparação com JSF. O Delphi continua evoluindo, assim como o JSF, mas ele sem sido discriminado, assim como JSF. O programador consegue melhores resultados com Delphi se ele pretende desenvolver uma aplicação desktop, que é o caso de muitos produtos de prateleira.

No que tange a sustentabilidade, o Delphi tem dois problemas que o JSF não tem: é proprietário e é gerido por uma única empresa. Se vocês observarem em todos rankings de linguagem e tecnologias, ninguém bate C/C++, Java e Linux em volume de uso. São tecnologias geridas por várias empresas, de forma aberta, por isso nunca caem no desuso. Muitas tecnologias fazem sucesso mas são perecíveis e outras nem fazem tanto sucesso, mas são perenes. É o mesmo que Funk e Bossa Nova.

JSF pode não agradar agora, ao lado de tantos frameworks inovadores que aparecem todo o tempo, mas sua constante evolução vai agradando aos poucos, que é o preço que se paga para se manter uma tecnologia perene.

Uma coisa que achei interessante no TechRadar foi a opinião deles sobre o Play Framework:

"Tivemos sugestões contraditórias para movê-lo tanto
para Adote quanto para Evite. Essas diferenças dependem
principalmente das aplicações onde ele é usado, como é usado
e quais as expectativas que as pessoas têm. Embora nenhuma
dessas questões sejam únicas para o Play, ele tem gerado
muito mais polêmica do que o esperado no debate bibliotecas
versus frameworks."

Na minha opinião o Play Framework é uma das maiores inovações do mercado atualmente. É a solução definitiva para três dos principais problemas que ninguém resolve nos servidores JavaEE: 1) ter que reimplantar a cada mudança no código para ver o resultado no browser; 2) tratamento elegante de erros; e 3) gerenciamento melhor do paralelismo (reactive). Ao resolver esses três problemas, o Play, além de ser moderno, é economicamente mais vantajoso. O Play tem o poder de tornar todos os frameworks baseados em servlets obsoletos. Ele só precisa de mais popularidade para alcançar esse objetivo. Ai vem perguntas como: É essa popularidade que vai convencê-lo a reescrever suas aplicações em Play a partir de agora? E a opinião do TechRadar, que também sugere adotar Node.js mesmo depois de uma briga séria entre os principais committers do projeto por causa de discordâncias sobre o futuro do framework, é realmente indiscutível?

Voltando ao ponto inicial, não acho que é uma questão de contexto  pois JSF é um framework de uso geral. É uma questão econômica, onde se leva em conta um cardápio de tecnologias a serem assimiladas vs. um framework que atende a necessidade com menos tempo de preparação; e também o preço da hora de um único programador que daria para cobrir uma capacidade de processamento considerável na AWS.

[Carlos Barreto]

Olha não posso discordar. Agora Hélio me fez questionar a construção de sistemas Java para desktop. E existe? Cara todo projeto de sistema esta sendo desenvolvido na plataforma web... Falo por experiência, recentemente estou num projeto onde será utilizado dentro da empresa, mas ele não será Desk.

Enviado pelo meu Windows Phone

---

De: helio frota
Enviada em: 18/02/2014 20:13
Para: ce...@googlegroups.com
Assunto: Re: [CEJUG] Re: TechRadar da Throughworks fala para evitar JSF

--

[helio frota]

E existe?

Vários, depende da localidade e/ou realidade.

Na empresa onde trabalho, pela realidade da empresa temos acho que 6 modelos java desktop 3 ainda java swing e 3 Java FX.

A realidade da empresa ainda necessita de clientes desktop.
A idéia é papocar o java swing e ir pro JavaFX.

Mais uma vez, não me sinto feliz editando arquivos FXML.
É um produto e o usuário não tá nem ai se foi feito programaticamente ou arrastando com o Schene Builder.

Usar o javaFX não é apensa pela beleza, o maior ganho é a facilidade mesmo "em dois tempos" a tela está pronta e não precisamos ( e não temos tempo ) para pensar cientificamente em como um helper de GridBagLayout pode ser otimizado para atender uma determinada demanda de usabilidade.

[Rafael Roque]

Creio que existam como iniciativas pontuais,eu por exemplo já precisei fazer um cliente em Swing para impressão de cupom fiscal.

[Hugo Castro Araujo]

Mesmo para impressão de cupom fiscal (ou qualquer tipo de integração com a máquina local), é possível fazer com aplicação web. Para isso você pode trabalhar com o Tomcat/Jetty Embedded, e, e usar Remote EJB se conectando com tua aplicação Web Servidora (ou como sugere o Hildeberto, se sua aplicação não precisar de transação usar WebServices ao invés de Remote EJB).

Quanto ao Swing, ele nasceu como "meio que como projeto de faculdade". Não foi pensado muito em performance, daí vieram SWT ou AWT. De qualquer forma, ainda prefiro usar o Delphi para aplicações Desktop.

[caio colares]

    A obrigação do PAF/ECF é somente que o banco trabalhe offline, nada impede de a aplicação rodar em um browser. 

    Com relação a existência de projetos desktop em java podemos citar SPED, emissor de NFe da sefaz paulista e o programa de IRPF da receita federal.

Caio Colares

[carlos bezerra]

Boa discussão, surge então um dúvida:

Posso então dizer que boa parte do peso gerado pelo JSF pode esta associado as bibliotecas customizadas de tags(Primefaces, RichFaces) de forma que ao utilizar somente Jquery com HTML5 posso der um ganho considerável de desempenho ao esta mais associado ao clico de vida do próprio JSF e a forma como ele trata a visão ? 

[Hildeberto Mendonça Filho]

Oi Carlos,

Não há nada que possa ser feito no JSF agora que possa torná-lo mais rápido do que um framework stateless. A questão é outra: você quer que a aplicação seja rápida (Framework stateless + JQuery + 1.js + 2.js + 3.js + ... + n.js + 1.jar + 2.jar) ou você quer que seu time seja rápido (JSF + Primefaces) ?

[Hildeberto Mendonça Filho]

Le 20/02/2014 12:43, Hugo Castro Araujo a écrit :
> Mesmo para impressão de cupom fiscal (ou qualquer tipo de integração
> com a máquina local), é possível fazer com aplicação web. Para isso
> você pode trabalhar com o Tomcat/Jetty Embedded, e, e usar Remote EJB
> se conectando com tua aplicação Web Servidora (ou como sugere o
> Hildeberto, se sua aplicação não precisar de transação usar
> WebServices ao invés de Remote EJB).

Um EJB local pode ser exposto por um serviço EJB. Ao invocar aquele
serviço você estaria na verdade invocando o EJB. Esse EJB é
transacional. Portanto, eu não disse que se a aplicação não precisar de
transação usar WebServices. Na verdade, a transação existe sempre, mesmo
com Web Service.

[Hugo Castro Araujo]

@Hildeberto, me perdoe não soube me expressar. De qualquer forma a transação vai ocorrer porque se está apenas criando uma camada de acesso remota sobre o HTTP (Web Service) aos EJB locais, ao invés de acessá-los via RMI, uma vez que o HTTP é livre de bloqueios de firewall (a menos que o cara bloquei mesmo o HTTP).

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.

Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para cejug+unsubscribe@googlegroups.com.

[Hugo Castro Araujo]

Bem,

Aproveitando o embalo do questionamento do nobre colega @carlos bezzerra, pergunto:

Os suporte que a maioria dos container web estão fornecendo, e, também o HTML5, uma alternativa mais "digamos" natural, uma vez a api de IO (NIO) agora permite por exemplo conexões assíncronas (p/ IO não bloquentes) ?

[Hugo Castro Araujo]

* Suporte ao WebSockets

[carlos bezerra]

opa Hildeberto obrigado pelo questionamento entendi o seu ponto de vista.

Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para cejug+un...@googlegroups.com.

[Elissandro Mendes]

Bom ao menos em uma das homologações que fiz do PAF/ECF os caras "botaram boneco" quanto a aplicação rodar no browser.

Me "forçaram" a rodar em modo quiosque. Pense!!!

2014-02-20 8:56 GMT-03:00 caio colares <colare...@gmail.com>:

--

Atenciosamente,

Elissandro A. Mendes

elissand...@gmail.com

Oi (85) 8696 1510

Skype: elissandro.mendes

[Hildeberto Mendonca]

On February 20, 2014, Hugo Castro Araujo <hugo...@gmail.com> wrote:

@Hildeberto, me perdoe não soube me expressar. De qualquer forma a transação vai ocorrer porque se está apenas criando uma camada de acesso remota sobre o HTTP (Web Service) aos EJB locais, ao invés de acessá-los via RMI, uma vez que o HTTP é livre de bloqueios de firewall (a menos que o cara bloquei mesmo o HTTP).

Tranquilo. No problem! :-)

[Jocélio Otávio]

Ressucitando o post, resposta do Cagatay sobre o que foi dito sobre JSF no Radar

 

http://blog.primefaces.org/?p=3035

Em 18 de fevereiro de 2014 16:16, Stanley Albuquerque <stanley...@gmail.com> escreveu:

Acho que o JSF é bom para casos bem específicos, eu não acho ele uma boa escolha para projetos que você não sabe quem e nem pelo que ele será acessado.

Em terça-feira, 18 de fevereiro de 2014 15h47min15s UTC-3, Paulo Junior escreveu:

O já conhecido radar de tecnologias da Thoughtworks (tão conhecido por ter a participação direta do Martin Fowler) sai falando para evitar JSF. Veja: http://thoughtworks.fileburst.com/assets/technology-radar-jan-2014-pt.pdf

Segue o trecho sobre os motivos para a recomendação:

Nós continuamos vendo equipes enfrentando problemas com o 
JSF – JavaServer Faces – e recomendamos evitar essa tecnologia. 

As equipes parecem escolher o JSF por ser um padrão J2EE, sem 
realmente avaliar se o modelo de programação é conveniente. 
Achamos que o JSF possui falhas porque tenta abstrair o 
HTML, o CSS e o HTTP, exatamente o oposto do que fazem 
os frameworks web modernos. O JSF, assim como o ASP.NET 
webforms, tenta criar estado persistente em cima do protocolo 
HTTP, que não possui estado, o que acaba gerando uma série 
de problemas envolvendo o estado compartilhado do lado 
do servidor. Nós estamos conscientes das melhorias no JSF 
2.0, mas achamos que o modelo é fundamentalmente falho. 
Recomendamos que as equipes utilizem frameworks simples, 
abracem e compreendam as tecnologias da web, incluindo o 
HTTP, o HTML e o CSS.

Se não olhou o radar, dê uma olhada. Vale a pena ver o que os caras recomendam, bem legal. :)

Abraço,

--

Paulo Alves Junior

Twitter: @paulojribp
Instrutor - Caelum | Ensino e Inovação

JugLeader CEJUG

Hurraa - OpenSource project to resource management

--
Você está recebendo esta mensagem porque se inscreveu no grupo "CEJUG" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para cejug+un...@googlegroups.com.
Para postar neste grupo, envie um e-mail para ce...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/cejug.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--

Atenciosamente,

Jocélio Otávio
UECE - Ciências da Computação
Analista Java - SCJP / SCWCD
COGECT - Prefeitura de Fortaleza

[Jair Domingues]

+1 ...

Já disse isto aqui há algum tempo.

outro link  resssucitando:  https://groups.google.com/forum/#!search/JAVA$207$20$2B$20jair$20domingues/cejug/lhsTEU5w2-U/B-s0wiUGA5sJ

[]s

jair

Jair Domingues

51-82150717

--
Você recebeu essa mensagem porque está inscrito no grupo quot;CEJUG" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para cejug+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para ce...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/cejug.
Para mais opções, acesse https://groups.google.com/d/optout.

[Hildeberto Mendonça]

Interpretando o interpretador:

“The analysis has two major problems, JSF is not what they have been told anymore”

Como foi que o Cagatay chegou a essa conclusão no texto do Radar? O texto não fala muito.

“... and second 'We recommend teams use simple frameworks and embrace and understand web technologies including HTTP, HTML and CSS.' assumes there is a silver bullet in web frameworks where there is none, but there is a silver bullet for each project type.”

Ele cita essa frase ai do Radar mas essa frase não tem nada a ver com framework silver bullet. Interpretação equivocada. O texto apenas enfatiza que é importante dominar bem HTTP, HTML e CSS e não tentar abstrair tudo. Eu acho que em certos projetos é importante o nível de abstração do JSF, mas também é importante dominar bem as três tecnologias.

“Back to the analysis, it is not valid because it mentions improvements in JSF 2.0 without knowing JSF 2.2 is out for sometime with killer features catching up with so called modern web development (the one where you write your own javascript, css, ajax, html).”

Outra frase equivocada. JSF 2.2 foi lançado já há mais de um ano, mas nenhum servidor que o disponibiliza está plenamente pronto para produção em grandes empresas. Essa semana eu apliquei 2 patches no nosso servidor JBoss EAP 6.2 e as melhorias e correções de bugs são impressionantes. Nenhum cliente da Thoughtworks usaria um servidor sem suporte. Então o JSF 2.2 ainda está longe da realidade das empresas.

O Cagatay está apenas vendendo o peixe dele. Mas concordo com ele que JSF é apropriado para certos contextos de uso. Eu, por exemplo, sou fraco em Java Script e JSF me cai muito bem. Pelo menos entrego o que prometo com ele.

[Leonardo]

a parte do heavylifting com binding transparente é muito impressionante, todavia. vou até fazer um laboratório com aquilo lá depois.