Quais são as principais desvantagens do Java Server Faces 2.0?

Question

Ontem vi uma apresentação sobre Java Server Faces 2.0 que pareceu realmente impressionante, embora eu seja atualmente um feliz desenvolvedor ASP.NET MVC/jQuery.O que mais gostei no JSF foi a enorme quantidade de componentes de UI habilitados para AJAX que parecem tornar o desenvolvimento muito mais rápido do que com ASP.NET MVC, especialmente em sites com uso pesado de AJAX.Os testes de integração também pareciam muito bons.

Como a apresentação enfatizou apenas as vantagens do JSF, gostaria de ouvir também sobre o outro lado.

Então minhas perguntas são:

• Quais são as principais desvantagens do Java Server Faces 2.0?
• O que pode fazer um desenvolvedor JSF considerar usar ASP.NET MVC em vez de JSF?

Answer 1

Desvantagens do JSF 2.0?Honestamente, além da curva de aprendizado relativamente íngreme quando você não tem um conhecimento sólido sobre Desenvolvimento Web básico (HTML/CSS/JS, lado do servidor versus lado do cliente, etc.) e o API Java Servlet básica (solicitação/resposta/sessão, encaminhamento/redirecionamento, etc.), nenhuma desvantagem séria vem à mente.O JSF em sua versão atual ainda precisa se livrar da imagem negativa que ganhou durante os primeiros anos, durante os quais havia diversas desvantagens sérias.

JSF 1.0 (março de 2004)

Este foi o lançamento inicial.Estava cheio de bugs nas áreas principais e de desempenho que você não quer saber.Seu aplicativo da web nem sempre funcionou como você esperava intuitivamente.Você, como desenvolvedor, fugiria chorando.

JSF 1.1 (maio de 2004)

Esta foi a versão do bugfix.O desempenho ainda não melhorou muito.Havia também uma grande desvantagem:você não pode incorporar HTML na página JSF perfeitamente.Todo HTML simples é renderizado antes a árvore de componentes JSF.Você precisa embrulhar toda a baunilha pura <f:verbatim> tags para que sejam incluídas na árvore de componentes JSF.Embora isso estivesse de acordo com as especificações, recebeu muitas críticas.Veja também a.o. JSF/facetas:por que não é uma boa ideia misturar JSF/Facelets com tags HTML?

JSF 1.2 (maio de 2006)

Este foi o primeiro lançamento da nova equipe de desenvolvimento JSF liderada por Ryan Lubke.A nova equipe fez um ótimo trabalho.Também houve mudanças nas especificações.A principal mudança foi a melhoria do tratamento de visualizações.Isso não apenas separou totalmente o JSF do JSP, para que se pudesse usar uma tecnologia de visualização diferente da JSP, mas também permitiu que os desenvolvedores incorporassem HTML simples na página JSF sem se preocupar com <f:verbatim> Tag.Outro grande foco da nova equipe foi melhorar o desempenho.Durante a vida útil da Implementação de Referência Sun JSF 1.2 (que recebeu o codinome Mojarra desde a compilação 1.2_08, por volta de 2008), praticamente todas as compilações foram enviadas com (grandes) melhorias de desempenho além das habituais (menores) correções de bugs.

A única desvantagem séria do JSF 1.x (incluindo 1.2) é a falta de um escopo entre o solicitar e sessão âmbito, o chamado conversação escopo.Isso forçou os desenvolvedores a se preocupar com elementos de entrada ocultos, consultas desnecessárias ao banco de dados e/ou abusar do escopo da sessão sempre que se deseja reter os dados iniciais do modelo na solicitação subsequente, a fim de processar com êxito validações, conversões, alterações de modelo e invocações de ação no mais aplicações web complexas.A dor poderia ser amenizada com a adoção de uma biblioteca de terceiros que retenha os dados necessários na solicitação subsequente, como MyFaces Tomahawk <t:saveState> componente, Costura JBoss escopo da conversa e Orquestra MyFaces estrutura de conversação.

Outra desvantagem para os puristas de HTML/CSS é que o JSF usa dois pontos : como caractere separador de ID para garantir a exclusividade do elemento HTML id na saída HTML gerada, especialmente quando um componente é reutilizado mais de uma vez na visualização (modelagem, iteração de componentes, etc.).Como este é um caractere ilegal em identificadores CSS, você precisaria usar o \ para escapar dos dois pontos em seletores CSS, resultando em seletores feios e de aparência estranha como #formId\:fieldId {} ou mesmo #formId\3A fieldId {}.Veja também Como usar o ID do elemento HTML gerado pelo JSF com dois pontos ":" nos seletores CSS? No entanto, se você não é purista, leia também Por padrão, o JSF gera ids inutilizáveis, que são incompatíveis com parte css dos padrões da web.

Além disso, o JSF 1.x não foi fornecido com recursos do Ajax prontos para uso.Não é realmente uma desvantagem técnica, mas devido ao entusiasmo da Web 2.0 durante esse período, tornou-se uma desvantagem funcional. Exadel foi cedo para introduzir o Ajax4jsf, que foi completamente desenvolvido ao longo dos anos e se tornou a parte central do JBoss RichFaces biblioteca de componentes.Outras bibliotecas de componentes também foram enviadas com poderes Ajax integrados, sendo a mais conhecida ICEfaces.

Na metade da vida útil do JSF 1.2, uma nova tecnologia de visualização baseada em XML foi introduzida: Facetas.Isto ofereceu enormes vantagens em relação ao JSP, especialmente na área de templates.

JSF 2.0 (junho de 2009)

Este foi o segundo grande lançamento, com Ajax como palavra de ordem.Houve muitas mudanças técnicas e funcionais.JSP foi substituído por Facelets como tecnologia de visualização padrão e Facelets foi expandido com recursos para criar componentes personalizados usando XML puro (o chamado componentes compostos).Veja também Por que o Facelets é preferido ao JSP como linguagem de definição de visualização do JSF2.0 em diante?

Os poderes do Ajax foram introduzidos no sabor do <f:ajax> componente que tem muitas semelhanças com Ajax4jsf.Anotações e aprimoramentos de convenção sobre configuração foram introduzidos para matar o detalhado faces-config.xml arquivar o máximo possível.Além disso, o caractere separador de ID do contêiner de nomenclatura padrão : tornou-se configurável, para que os puristas de HTML/CSS pudessem respirar aliviados.Tudo que você precisa fazer é defini-lo como init-param em web.xml com o nome javax.faces.SEPARATOR_CHAR e garantir que você não esteja usando o personagem em nenhum lugar dos IDs do cliente, como -.

Por último, mas não menos importante, foi introduzido um novo âmbito, o visualizar escopo.Ele eliminou outra grande desvantagem do JSF 1.x, conforme descrito anteriormente.Você acabou de declarar o feijão @ViewScoped para ativar o escopo da conversa sem atrapalhar todas as maneiras de reter os dados em solicitações (conversacionais) subsequentes.A @ViewScoped bean permanecerá ativo enquanto você enviar e navegar posteriormente para a mesma visualização (independentemente da guia/janela aberta do navegador!), seja de forma síncrona ou assíncrona (Ajax).Veja também Diferença entre o escopo View e Request em beans gerenciados e Como escolher o escopo de feijão certo?

Embora praticamente todas as desvantagens do JSF 1.x tenham sido eliminadas, existem bugs específicos do JSF 2.0 que podem se tornar um empecilho.O @ViewScoped falha em manipuladores de tags devido a uma questão do ovo de galinha na poupança parcial do Estado.Isso foi corrigido no JSF 2.2 e portado no Mojarra 2.1.18.Também passando atributos personalizados como o HTML5 data-xxx não é suportado.Isso foi corrigido no JSF 2.2 pelo novo recurso de elementos/atributos de passagem.Além disso, a implementação do JSF, Mojarra seu próprio conjunto de questões.Relativamente muitos deles estão relacionados com o comportamento às vezes não intuitivo de <ui:repeat>, o nova implementação de economia parcial de estado e a escopo flash mal implementado.A maioria deles foi corrigida na versão Mojarra 2.2.x.

Na época do JSF 2.0, PrimeFaces foi introduzido, baseado em jQuery e jQuery UI.Tornou-se a biblioteca de componentes JSF mais popular.

JSF 2.2 (maio de 2013)

Com a introdução do JSF 2.2, o HTML5 foi usado como palavra da moda, embora fosse tecnicamente suportado apenas em todas as versões mais antigas do JSF.Veja também Suporte JavaServer Faces 2.2 e HTML5, por que o XHTML ainda está sendo usado.O novo recurso mais importante do JSF 2.2 é o suporte para atributos de componentes personalizados, abrindo assim um mundo de possibilidades, como grupos de botões de opção sem tabela personalizados.

Além de bugs específicos de implementação e algumas "coisinhas irritantes", como a incapacidade de injetar um EJB em um validador/conversor (já corrigido no JSF 2.3), não há grandes desvantagens na especificação JSF 2.2.

MVC baseado em componente vs MVC baseado em solicitação

Alguns podem optar que a principal desvantagem do JSF é que ele permite muito pouco controle refinado sobre o HTML/CSS/JS gerado.Isso não é do próprio JSF, é só porque é um baseado em componentes Estrutura MVC, não uma solicitação (ação) baseada Estrutura MVC.Se um alto grau de controle de HTML/CSS/JS é seu principal requisito ao considerar uma estrutura MVC, então você já não deveria estar olhando para uma estrutura MVC baseada em componentes, mas sim uma estrutura MVC baseada em solicitações como Primavera MVC.Você só precisa levar em conta que você mesmo terá que escrever todo esse padrão HTML/CSS/JS.Veja também Diferença entre Solicitação MVC e Componente MVC.

Veja também:

• Qual é a diferença entre JSF, Servlet e JSP? (só para entender o básico)
• Usando JSF para desenvolver layouts CSS sem tabelas (outro mito sobre JSF)
• JSF versus HTML/CSS/JS/jQuery simples (quando JSF é a escolha errada)
• Padrões de design em aplicações web (ilustra a ideologia por trás do MVC)

Answer 2

Após 5 anos trabalhando com JSF, acho que posso acrescentar meus 2 centavos.

Dois principal JSF desvantagens:

1. Grande curva de aprendizado.JSF é complexo, isso é verdade.
2. Isso é componente natureza.A estrutura baseada em componentes tenta esconder a verdadeira natureza da Web, que traz consigo uma enorme quantidade de complicações e desastres (como não suportar GET em JSF em quase 5 anos).
   IMHO ocultar solicitação/resposta HTTP do desenvolvedor é um erro enorme.Pela minha experiência, cada estrutura baseada em componentes adiciona abstração ao desenvolvimento Web, e essa abstração resulta em sobrecarga desnecessária e maior complexidade.

E menor desvantagens que me vêm à mente:

1. Por padrão, o ID do objeto é composto pelos ids de seus pais, por exemplo form1:button1.
2. Não é uma maneira fácil de comentar o fragmento incorreto da página.Marcação <ui:remove> precisa de conteúdo sintaticamente correto que é analisado de qualquer maneira.
3. Componentes de terceiros de baixa qualidade que, por ex.não verifique isRendered() dentro processXxx() método antes de continuar.
4. Incorporar LESS & Sencha é difícil.
5. Não funciona bem com REST.
6. Não é tão fácil para designers de UX, porque os componentes prontos para uso têm seus próprios estilos CSS, que precisam ser substituídos.

Não me entenda mal.Como framework de componentes o JSF na versão 2 é muito bom, mas ainda é baseado em componentes, e sempre será...

Por favor, dê uma olhada na baixa popularidade do Tapestry, Wicket e no baixo entusiasmo dos desenvolvedores JSF experientes (o que é ainda mais significativo).E para contrastar, dê uma olhada no sucesso de Rails, Grails, Django, Play!Framework - todos eles são baseados em ações e não tentam se esconder do programador solicitação/resposta verdadeira e natureza apátrida da web.

Para mim, é uma grande desvantagem do JSF.IMHO JSF pode ser adequado para alguns tipos de aplicativos (intranet, uso intensivo de formulários), mas para a vida real rede aplicação, não é um bom caminho a percorrer.

Espero que ajude alguém com suas escolhas em relação ao front-end.

Answer 3

Algumas desvantagens que vêm à mente:

1. JSF é uma estrutura baseada em componentes.Isso tem restrições inerentes que têm a ver com obedecer ao modelo de componente.
2. O AFAIK JSF suporta apenas a postagem, por isso, se você quiser um Get A um lugar, precisará fazer um servlet/jsp simples.
3. A maioria dos componentes tenta fornecer abstrações sobre domínios, como bancos de dados relacionais e JavaScript front-end, e muitas vezes essas abstrações são "vazadas" e muito difíceis de depurar.
4. Essas abstrações podem ser um bom ponto de partida para um desenvolvedor júnior ou para alguém que não se sente confortável com um domínio específico (por exemplo,JavaScript front-end), mas são muito difíceis de otimizar o desempenho, pois há diversas camadas envolvidas e a maioria das pessoas que as utilizam tem pouca compreensão do que está acontecendo nos bastidores.
5. Os mecanismos de modelagem que normalmente são usados ​​com JSF não têm nada a ver com o funcionamento dos web designers.Os editores WYSIWYG para JSF são primitivos e, em qualquer caso, seu designer fornecerá HTML/CSS que você terá que gastar muito tempo convertendo.
6. Coisas como expressões EL não são verificadas estaticamente e tanto o compilador quanto os IDEs não estão fazendo um bom trabalho na localização de erros, então você acabará com erros que terá que detectar em tempo de execução.Isso pode ser bom para linguagens de tipo dinâmico como Ruby ou PHP, mas se eu tiver que suportar o inchaço do ecossistema Java, exijo digitação para meus modelos.

Resumindo: O tempo que você economizará com JSF, evitando escrever o código padrão JSP/servlet/bean, você gastará x10 para escalá-lo e fazer exatamente o que deseja.

Answer 4

Para mim, a maior desvantagem do JSF 2.0 é a curva de aprendizado não apenas do JSF, mas também das bibliotecas de componentes que você precisa usar para fazer com que ele faça um trabalho útil.Considere o número impressionante de especificações e padrões com os quais você precisa lidar para ser realmente proficiente:

• HTML nas várias encarnações.Não finja que não precisa saber disso.
• HTTP - quando você não consegue descobrir o que está acontecendo, você precisa abrir o Firebug e ver.Para isso você precisa saber disso.
• CSS – Goste ou não.Na verdade, não é tão ruim e existem pelo menos algumas ferramentas interessantes por aí.
• XML – JSF provavelmente será o primeiro lugar onde você usará namespaces nesse nível.
• Especificação de Servlets.Mais cedo ou mais tarde você começará a chamar métodos neste pacote.Além disso, você precisa saber como seus Facelets são transformados em XHTML ou algo assim.
• JSP (principalmente para que você saiba por que não precisa dele no JSF)
• JSTL (novamente, principalmente para lidar com a estrutura legada)
• Linguagem de Expressão (EL) em suas diversas formas.
• ECMAScript, JavaScript ou como você quiser chamá-lo.
• JSON – você deve saber disso mesmo que não o use.
• AJAX.Eu diria que o JSF 2.0 faz um trabalho decente em esconder isso de você, mas você ainda precisa saber o que está acontecendo.
• O DOM.E como um navegador o utiliza.Consulte ECMAScript.
• Eventos DOM – um tópico por si só.
• Java Persistence Architecture (JPA), isto é, se você deseja que seu aplicativo tenha algum banco de dados de back-end.
• próprio Java.
• JSEE enquanto você está nisso.
• A especificação de injeção de dependência de contexto (CDI) e como ela entra em conflito e é usada com o JSF 2.0
• JQuery - gostaria de ver você viver sem ele.

Agora, quando terminar isso, você poderá prosseguir com as especificações proprietárias, ou seja, as bibliotecas de componentes e as bibliotecas de provedores que você aprenderá ao longo do caminho:

• PrimeFaces (minha biblioteca de componentes preferida)
• RichFaces
• Meus rostos
• ICEFaces
• EclipseLink (meu provedor JPA)
• Hibernar
• Soldar

E não se esqueça do recipiente!E todos esses arquivos de configuração:

• Peixe de vidro (2, 3, etc)
• JBoss
• gato

Então - ISSO ESTÁ FACILITANDO?Claro, o JSF 2.0 é "fácil", desde que tudo o que você queira fazer sejam as páginas da Web mais básicas com as interações mais simples.

Simplificando, o JSF 2.0 é a mistura mais complicada e complicada de tecnologias interligadas que existe hoje no universo do software.E não consigo pensar em nada que preferiria usar.

Answer 5

1. Desenvolvedores inexperientes geralmente criarão aplicativos dolorosamente lentos e o código será realmente feio e difícil de manter.É aparentemente simples de começar, mas na verdade requer algum investimento em aprendizado se você quiser escrever bons programas.
2. Pelo menos no início você muitas vezes ficará "preso" em algum problema e gastará mais tempo lendo posts balusc na internet do que realmente trabalhando :) Depois de um tempo será cada vez menos isso, mas ainda pode ser irritante.
3. Ainda mais irritante quando você descobre que o problema não é devido à sua falta de conhecimento/erro, mas na verdade um bug.Mojarra tinha (é?) bastante bugs e outra camada de componentes adiciona ainda mais problemas.Richfaces foi o maior software de merda já escrito :) Não sei como está agora na versão 4.Temos Primefaces que é melhor, mas ainda assim você encontrará bugs ou falta de recursos, especialmente com componentes mais exóticos.E agora você precisará pagar pelas atualizações do Primefaces.Então, eu diria que está com bugs, mas está melhorando, especialmente depois que a versão 2.2 corrigiu alguns problemas com as especificações.Framework ficando mais maduro, mas ainda longe de ser perfeito (talvez o myfaces seja melhor?).
4. Não acho isso especialmente flexível.Muitas vezes, se você precisar de algo muito personalizado e não houver componentes que façam isso, será um pouco doloroso.Novamente estou falando da perspectiva média do desenvolvedor - aquele com prazos, tutoriais de leitura rápida e pesquisa de stackoverflow quando fica preso porque não há tempo para aprender como realmente funciona :) Muitas vezes alguns componentes parecem ter "quase" o que você precisa, mas não exatamente e às vezes você pode gastar muito tempo para fazê-lo fazer o que deseja :) É preciso ter cuidado ao avaliar se é melhor criar o seu próprio ou torturar um componente existente.Na verdade, se você estiver criando algo realmente único, eu não recomendaria o JSF.

Resumindo, minhas desvantagens seriam:Complexidade, progresso de desenvolvimento não muito suave, bugs, inflexível.

Claro que também existem vantagens, mas não foi isso que você perguntou.De qualquer forma, essa é minha experiência com framework, outros podem ter opiniões diferentes, então a melhor maneira é experimentá-lo por um tempo para ver se é para você (apenas algo mais complexo - não exemplos ingênuos - JSF realmente brilha aí :) IMHO melhor caso de uso para JSF são aplicativos de negócios, como CRMs etc.

Answer 6

"O JSF produzirá HTML e JavaScript da camada de visualização que você não pode controlar ou alterar sem entrar no código do controlador."

Na verdade, o JSF oferece flexibilidade: você pode usar componentes padrão/de terceiros ou criar os seus próprios, com controle total sobre o que é renderizado.É apenas um xhtml que você precisa para criar seus componentes personalizados com JSF 2.0.

Answer 7

Desenvolvemos um projeto de amostra com JSF (foi uma pesquisa de três semanas, então podemos ter perdido algumas coisas!)

Tentamos usar core jsf, se for necessário um componente usamos PrimeFaces.

O projeto era um site com navegação.Cada página deve ser carregada via ajax quando o menu é clicado.

O site tem dois casos de uso:

1. Uma página com uma grade.A grade é carregada via ajax e deve suportar classificação e paginação
2. Uma página do assistente de três etapas.Cada página possui validação do lado do cliente (para validações simples) e validação base ajax do lado do servidor (para validações complexas).Qualquer exceção de servidor (da camada de serviço) deve ser exibida na mesma página do assistente sem navegar para a próxima página.

Nós achamos isso:

1. Você precisa usar alguns hacks do omniFaces para corrigir o estado de visualização do JSF.O estado JSF será corrompido quando você incluir páginas via ajax umas nas outras.Isto parece ser um bug no JSF e pode ser corrigido nas próximas versões (não na 2.3).
2. O fluxo JSF não está funcionando corretamente com ajax (ou não conseguimos fazê-lo funcionar!) Tentamos usar o componente assistente primeface, mas a validação do cliente parece não ser suportada e significa que não era o padrão de fluxo JSF padrão.
3. Ao usar alguns componentes jQuery, como jqGird, e você precisar carregar resultados JSON, é recomendável usar servlet puro. O JSF não fará nada por você.Portanto, se você usar esse tipo de componente, seu design não caberá no JSF.
4. Tentamos fazer alguns scripts de cliente quando o ajax é concluído ajaxComplete e descobrimos que o PF 4 implementou seus próprios eventos ajax.Tínhamos alguns componentes jQuery e precisamos alterar seu código.

Se você alterar a amostra acima para um não Ajax projeto (ou pelo menos menos projeto ajax), você não enfrentará muitos dos problemas acima.

Resumimos nossa pesquisa como:

JSF não está funcionando bem em um site totalmente baseado em ajax.

É claro que encontramos muitos recursos interessantes no JSF que podem ser muito úteis em alguns projetos, portanto, considere as necessidades do seu projeto.

Consulte os documentos técnicos do JSF para revisar as vantagens do JSF e, na minha opinião, a maior vantagem do JSF é o suporte COMPLETO E ENORME do @BalusC ;-)

Answer 8

Não sou especialista em Java Server Faces.Mas IMHO a principal desvantagem é que é do lado do servidor.Estou cansado de aprender e usar estruturas de camada de apresentação web do lado do servidor, como ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, estruturas php e estruturas Ruby on Rails.Eu disse adeus a todos eles e disse olá ao Angularjs e ao TypeScript.Minha camada de apresentação é executada no navegador.Não importa se é servido pelo Windows IIS rodando php ou ASP.NET, ou se é servido por um servidor web Apache rodando em Linux.Eu só preciso aprender uma estrutura que funcione em qualquer lugar.

Apenas meus dois centavos.

Answer 9

Para mim, a maior deficiência do JSF é o suporte deficiente para páginas geradas programaticamente (dinamicamente).
Se você deseja construir sua página (criar modelo de componente de página) dinamicamente a partir do código Java.Por exemplo, se você estiver trabalhando no construtor de páginas da web WYSIWYG.A documentação adequada deste caso de uso geralmente não está disponível.Há muitos pontos em que você precisa experimentar e o desenvolvimento é bastante lento.Muitas coisas simplesmente não funcionam como você esperaria.Mas geralmente é possível hackear de alguma forma.
O bom é que isso não é problema de filosofia ou arquitetura do JSF.Simplesmente não é elaborado o suficiente (até onde eu sei).

O JSF 2 trouxe Componentes Compostos que deveriam facilitar o desenvolvimento de componentes, mas seu suporte para construção dinâmica (programática) é muito fraco.Se você superar o processo silencioso, complicado e quase não documentado de construção dinâmica de componentes compostos, descobrirá que se você aninhar alguns componentes compostos um pouco mais profundamente, eles param de funcionar, gerando algumas exceções.

Mas parece que a comunidade JSF está ciente destas deficiências.Eles estão trabalhando nisso, como você pode ver nesses dois bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

A situação deveria ser melhor com o JSF 2.2, pelo menos se estivermos falando de especificação.

Answer 10

Comentando sobre meus últimos meses de experiência em Primefaces/JSF:

• Se você pode usar componentes "prontos para uso", acho que não é terrível.
• No entanto, ele não funciona bem assim que você sai e precisa de UIs personalizadas.- Por exemplo, precisávamos usar o bootstrap do Twitter para o nosso projeto.(Não é bootstrap do primefaces).
  • Agora nossas páginas funcionam da seguinte maneira:
    • A página carrega.
    • O usuário interage com um Primefaces que possui funcionalidade ajax
    • As ligações javascript do Bootstrap quebram
    • Executamos javascript extra para religar tudo

A promessa do JSF de evitar escrever javascript se transformou em escrever mais javascript do que teríamos se não usássemos o Primefaces - e esse javascript é para consertar o que o Primefaces quebra.

É uma perda de tempo - a menos que você use novamente coisas "prontas para uso".Também é muito feio (Primefaces) quando se tem que trabalhar com Selenium.Tudo pode ser feito - mas, novamente - há muito tempo.

Definitivamente, evite isso se você estiver trabalhando com uma equipe de UX/design e precisar iterar rapidamente na UI - você pode economizar tempo aprendendo jquery/escrevendo HTML direto - ou observando react/angular.

Answer 11

O JSF tem muitas vantagens. A questão de estar em desvantagem, deixe-me acrescentar alguns pontos.

Em um cenário prático de implementação de um projeto web dentro de um prazo você precisa ficar de olho nos seguintes fatores.

• Você tem membros seniores suficientes em sua equipe que podem sugerir os melhores controles adequados para cada cenário?

• Você tem largura de banda para acomodar a curva de aprendizado inicial?

• Você tem experiência suficiente em sua equipe para revisar o JSF?
  coisas produzidas pelos desenvolvedores?

Se sua resposta for 'Não' para as perguntas, você poderá acabar em uma base de código não sustentável.

Answer 12

JSF tem apenas uma desvantagem:antes de iniciar o desenvolvimento "JSF", você deve entender claramente o desenvolvimento web, o núcleo java e a arquitetura front-end.

Hoje em dia, os "novos" frameworks JavaScript apenas tentam copiar/colar o modelo baseado em componentes "JSF".

Answer 13

Entre todos os frameworks "mainstream", como Spring MVC, Wicket, Tapestry, etc., o JSF do Java EE com seus componentes compostos é a camada de apresentação mais elaborada e a tecnologia orientada a componentes fornecida.É um pouco complicado e incompleto em comparação com as soluções fornecidas pelo HybridJava.