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

Ontem, vi uma apresentação no Java Server Faces 2.0 que parecia realmente impressionante, apesar de atualmente ser um desenvolvedor feliz do ASP.NET MVC / jQuery. O que eu mais gostei no JSF foi a enorme quantidade de componentes de interface do usuário habilitados para AJAX, que parecem tornar o desenvolvimento muito mais rápido do que com o ASP.NET MVC, especialmente em sites pesados ​​com AJAX. O teste de integração também parecia muito bom.

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

Então, minhas perguntas são:

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

Desvantagens do JSF 2.0? Honestamente, além da curva de aprendizado relativamente íngreme, quando você não possui um conhecimento sólido sobre o desenvolvimento básico da Web (HTML / CSS / JS, lado do servidor versus lado do cliente, etc.) e a API básica do Java Servlet (request / response / session , encaminhamento / redirecionamento etc.), não há desvantagens sérias. O JSF em sua versão atual ainda precisa se livrar da imagem negativa obtida durante as primeiras idades, durante as quais houve várias 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 funcionava como você esperaria intuitivamente. Você, como desenvolvedor, se afastava chorando.

JSF 1.1 (maio de 2004)

Esta foi a versão do bugfix. O desempenho ainda não foi muito melhorado. Havia também uma grande desvantagem: você não pode alinhar HTML na página JSF na perfeição. Todo o HTML simples de baunilha é renderizado antes da árvore de componentes JSF. Você precisa agrupar todas as baunilhas comuns em <f:verbatim>tags para que elas sejam incluídas na árvore de componentes JSF. Embora isso tenha sido conforme a especificação, isso recebeu muitas críticas. Veja também ao JSF / Facelets: 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 da vista. Isso não apenas desanexou o JSF totalmente do JSP, para que se pudesse usar uma tecnologia de exibição diferente da JSP, mas também permitiu que os desenvolvedores incorporassem HTML simples de baunilha na página JSF sem se preocupar com as <f:verbatim>tags. Outro foco importante da nova equipe foi melhorar o desempenho. Durante o tempo de vida da Sun JSF Reference Implementation 1.2 (codinome Mojarra desde a compilação 1.2_08, por volta de 2008), praticamente toda compilação foi enviada com (maiores) aprimoramentos de desempenho ao lado das pequenas (usuais) correções de erros.

A única desvantagem séria do JSF 1.x (incluindo 1.2) é a falta de um escopo entre o pedido e o escopo da sessão , o chamado escopo de conversação . Isso forçou os desenvolvedores a lidar 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 do modelo inicial na solicitação subseqüente para processar com êxito validações, conversões, alterações de modelo e invocações de ação nos mais aplicações web complexas. A dor pode ser amenizada com a adoção de uma biblioteca de terceiros que retém os dados necessários na solicitação subsequente, como o componente MyFaces Tomahawk <t:saveState> , a estrutura de conversa do JBoss Seam escopo de conversa do e o MyFaces Orchestra .

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

Além disso, o JSF 1.x não foi enviado com as instalações do Ajax imediatamente. Não é realmente uma desvantagem técnica, mas devido ao hype da Web 2.0 durante esse período, tornou-se uma desvantagem funcional. Exadel chegou cedo para introduzir o Ajax4jsf, que foi completamente desenvolvido durante os anos e se tornou a parte principal da biblioteca de componentes do JBoss RichFaces . Outras bibliotecas de componentes também foram enviadas com recursos Ajax internos, sendo a mais conhecida a ICEfaces .

Cerca da metade da vida útil do JSF 1.2, uma nova tecnologia de exibição baseada em XML foi introduzida: Facelets . Isso ofereceu enormes vantagens acima do JSP, especialmente na área de modelagem.

JSF 2.0 (junho de 2009)

Este foi o segundo grande lançamento, com o Ajax como palavra de ordem. Houve muitas mudanças técnicas e funcionais. O JSP é substituído pelo Facelets como a tecnologia de exibição padrão e o Facelets foi expandido com recursos para criar componentes personalizados usando XML puro (os chamados componentes compostos ). Consulte também Por que o Facelets é preferível ao JSP como a 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 o Ajax4jsf. Anotações e aprimoramentos de convenção sobre configuração foram introduzidos para eliminar o faces-config.xmlarquivo detalhado o máximo possível. Além disso, o caractere padrão do separador de ID do contêiner de nomeação :tornou-se configurável, para que os puristas de HTML / CSS pudessem respirar aliviados. Tudo que você precisa fazer é defini-lo como init-paramna web.xmlcom o nome javax.faces.SEPARATOR_CHARe garantir que você não está usando o personagem-se em qualquer lugar do ID do cliente, tais como -.

Por último, mas não menos importante, um novo escopo foi introduzido, o escopo da visualização . Ele eliminou outra grande desvantagem do JSF 1.x, como descrito anteriormente. Você acabou de declarar o bean @ViewScopedpara ativar o escopo da conversa sem precisar procurar todas as maneiras de reter os dados em solicitações subsequentes (conversacionais). Um @ViewScopedbean permanecerá enquanto você posteriormente enviar e navegar para a mesma exibição (independentemente da guia / janela do navegador aberta!), De forma síncrona ou assíncrona (Ajax). Consulte também Diferença entre o escopo Exibir e Solicitar nos beans gerenciados e Como escolher o escopo direito do bean?

Embora praticamente todas as desvantagens do JSF 1.x tenham sido eliminadas, existem erros específicos do JSF 2.0 que podem se tornar um limitador de exibição. A @ViewScopedfalha em manipuladores de tag devido a um problema galinha-ovo em economia de estado parcial. Isso foi corrigido no JSF 2.2 e suportado no Mojarra 2.1.18. Também não há suporte para a transmissão de atributos personalizados como o HTML5data-xxx . Isso foi corrigido no JSF 2.2 pelos novos elementos / atributos de passagem. Além disso, a implementação do JSF Mojarra tem seu próprio conjunto de problemas . Relativamente, muitos deles estão relacionados ao comportamento às vezes não intuitivo<ui:repeat> , à nova implementação de economia de estado parcial e ao escopo do flash mal implementado . A maioria deles é corrigida na versão Mojarra 2.2.x.

Por volta do tempo do JSF 2.0, o PrimeFaces foi introduzido, com base nas interfaces de usuário jQuery e jQuery. 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-chave, mesmo que isso fosse tecnicamente suportado em todas as versões mais antigas do JSF. Consulte também o suporte ao 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 a atributos de componentes personalizados, abrindo assim um mundo de possibilidades, como grupos de botões de opção sem tabela personalizados .

Além de erros 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á realmente grandes desvantagens na especificação do JSF 2.2.

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

Alguns podem optar por que a principal desvantagem do JSF é que ele permite muito pouco controle refinado sobre o HTML / CSS / JS gerado. Isso não é do JSF, é apenas porque é uma estrutura MVC baseada em componente , não uma estrutura MVC baseada em solicitação (ação) . Se um alto nível de controle de HTML / CSS / JS é seu principal requisito ao considerar uma estrutura MVC, você já não deve estar olhando para uma estrutura MVC baseada em componentes, mas em uma estrutura MVC baseada em solicitação, como o Spring MVC . Você só precisa levar em consideração que precisará escrever todo esse padrão HTML / CSS / JS. Consulte também Diferença entre Request MVC e Component MVC .

Veja também:

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

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

Duas grandes desvantagens do JSF :

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

E pequenas 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 de página incorreta. A tag <ui:remove>precisa de conteúdo sintaticamente correto, que é analisado de qualquer maneira.
3. Componentes de baixa qualidade de terceiros que, por exemplo, não verificam por isRendered()dentroprocessXxx() método antes de continuar.
4. Incorporar LESS & Sencha é difícil.
5. Não joga bem com o 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 interpretem mal. Como uma estrutura de componentes, o JSF na versão 2 é realmente bom, mas ainda é baseado em componentes, e sempre será ...

Dê uma olhada na baixa popularidade do Tapeçaria, no Wicket e no baixo entusiasmo dos desenvolvedores experientes do JSF (o que é ainda mais significativo). E, por outro lado, veja o sucesso do Rails, Grails, Django, Play! Framework - todos eles são baseados em ação e não tentam ocultar o verdadeiro pedido / resposta do programador e a natureza sem estado da Web.

Para mim, é uma grande desvantagem do JSF. O IMHO JSF pode se adequar a algum tipo de aplicativo (intranet, uso intensivo de formulários), mas para aplicativos da Web da vida real não é um bom caminho a percorrer.

Espero que ajude alguém com suas escolhas relacionadas ao front-end.

Algumas desvantagens que vêm à mente:

1. O JSF é uma estrutura baseada em componentes. Isso tem restrições inerentes relacionadas à obediência ao modelo de componente.
2. O AFAIK JSF suporta apenas POST, portanto, se você quiser um GET em algum lugar, precisará executar 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 esteja familiarizado com um domínio específico (por exemplo, JavaScript front-end), mas é muito difícil otimizar o desempenho, pois há várias camadas envolvidas e a maioria das pessoas que as utiliza. tenha pouco entendimento do que está acontecendo sob o capô.
5. Os mecanismos de modelagem que geralmente são usados ​​com o JSF não têm nada a ver com o funcionamento dos web desigers. Os editores WYSIWYG para JSF são primitivos e, em qualquer caso, seu designer fornecerá HTML / CSS que você terá que passar anos convertendo.
6. Coisas como expressões EL não são verificadas estaticamente e o compilador e os IDEs não estão fazendo um bom trabalho em encontrar erros; portanto, você acabará com erros que precisará capturar em tempo de execução. Isso pode ser bom para uma linguagem de tipo dinâmico, como Ruby ou PHP, mas se eu tiver que suportar o grande inchaço do ecossistema Java, exijo digitar meus modelos.

Resumindo: o tempo que você economizará com o JSF, evitando gravar o código JSP / servlet / bean, você gastará x10 para torná-lo escalável e fazer exatamente o que você deseja que ele faça.

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ê lida para realmente ser 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, 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 boas ferramentas.
• XML - JSF provavelmente será o primeiro lugar em que você usa espaços para nome nesse nível.
• Especificação de Servlet. Mais cedo ou mais tarde, você começará a chamar métodos neste pacote. Além disso, você precisa saber como o Facelets se transforma em XHTML ou o que seja.
• JSP (principalmente para você saber por que não precisa dele no JSF)
• JSTL (novamente, principalmente para lidar com a estrutura herdada)
• Expression Language (EL) em suas várias formas.
• ECMAScript, JavaScript ou o que mais você quiser chamar.
• 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 usa. Consulte ECMAScript.
• Eventos DOM - um tópico por si só.
• Java Persistence Architecture (JPA), ou seja, se você deseja que seu aplicativo tenha qualquer 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 com e é usada com o JSF 2.0
• JQuery - Eu gostaria que você se desse bem sem ele.

Agora, depois que você terminar, poderá continuar com as especificações proprietárias, ou seja, as bibliotecas de componentes e bibliotecas de fornecedores que você selecionará ao longo do caminho:

• PrimeFaces (minha biblioteca de componentes de escolha)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (meu provedor JPA)
• Hibernate
• Soldar

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

• GlassFish (2, 3, etc)
• JBoss
• Tomcat

Então - isso está facilitando? Claro, o JSF 2.0 é "fácil", desde que tudo o que você queira fazer seja 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 coladas, como existe hoje no universo do software. E não consigo pensar em nada que prefira usar.

1. Desenvolvedores inexperientes geralmente criarão aplicativos que são dolorosamente lentos e o código será realmente feio e difícil de manter. É enganosamente simples de iniciar, mas na verdade requer algum investimento em aprendizado, se você deseja escrever bons programas.
2. Pelo menos no início, você geralmente "fica preso" em algum problema e passa mais tempo lendo mensagens obscenas 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 era (é?) Bastante problemático, e outra camada de componentes adiciona ainda mais problemas. O Richfaces foi o maior software de merda já escrito :) Não sei como está agora na versão 4. Temos o Primefaces, o que é melhor, mas você ainda 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 seu buggy, mas está melhorando, especialmente após a versão 2.2, corrigimos alguns problemas com as especificações. O framework está ficando mais maduro, mas ainda está longe de ser perfeito (talvez meusfaces 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. Mais uma vez, estou falando da perspectiva média do desenvolvedor - aquela com prazos, tutoriais de leitura rápida e pesquisando o stackoverflow quando fica travada porque não há tempo para aprender como realmente funciona :) Muitas vezes, alguns componentes parecem "quase" o que você precisa, mas não exatamente e, às vezes, você pode gastar muito tempo para fazer o que deseja :) Precisa ter cuidado ao avaliar se é melhor criar seu próprio componente ou torturar. Na verdade, se você estiver criando algo realmente único, eu não recomendaria o JSF.

Então, em resumo, minhas desvantagens seriam: Complexidade, progresso de desenvolvimento não muito suave, buggy, inflexível.

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

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

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

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 da camada de apresentação da 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á para Angularjs e TypeScript. Minha camada de apresentação é executada no navegador. Não importa se é servido pelo Windows IIS executando php ou ASP.NET, ou se é servido por um servidor Web Apache em execução no Linux. Eu só preciso aprender apenas uma estrutura que funcione em qualquer lugar.

Apenas meus dois centavos.

Desenvolvemos um projeto de amostra com o JSF (foram três semanas de pesquisa, para que possamos perder algumas coisas!)

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

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

O site possui 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 de base ajax do lado do servidor (para validações complexas). Qualquer exceção do servidor (da camada de serviço) deve ser exibida na mesma página do assistente sem navegar para a página seguinte.

Nós achamos isso:

1. Você precisa usar alguns hacks do omniFaces para tornar o estado da visualização JSF corrigido. O estado JSF será corrompido quando você incluir páginas através do ajax. Isso parece 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 poderíamos fazê-lo funcionar!) Em vez disso, tentamos usar o componente assistente do primeface, mas a validação do cliente parece não ser suportada e significa que não era o padrão do fluxo JSF padrão.
3. Ao usar alguns componentes jQuery, como jqGird, e você precisar carregar resultados JSON, recomenda-se usar o 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 foi concluído ajaxCompletee descobrimos que o PF 4 implementou seus próprios eventos ajax. Tivemos alguns componentes do jQuery e precisamos alterar o código deles.

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

Resumimos nossa pesquisa como:

O JSF não está funcionando bem em um site de base totalmente ajax.

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

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

Para mim, a maior falha 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 desse caso de uso geralmente não está disponível. Há muitos pontos em que você precisa experimentar e o desenvolvimento é silencioso e lento. Muitas coisas simplesmente não funcionam como você esperaria. Mas geralmente é possível hacká-lo de alguma forma.
O bom é que não há problema em filosofia ou arquitetura do JSF. Simplesmente não é elaborado o suficiente (tanto quanto eu sei).

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

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

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

Comentando meus últimos meses de experiência com o 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, precisamos usar a inicialização do Twitter para o nosso projeto. (Não inicia o bootstrap).
  • Agora, nossas páginas funcionam da seguinte maneira:
    • Página carrega.
    • O usuário interage com um Primefaces que possui funcionalidade ajax
    • Quebra de ligações de javascript do Bootstrap
    • Executamos javascript extra para religar tudo

A promessa do JSF de evitar escrever javascript se transformou em mais javascript do que teríamos se não estivesse usando o Primefaces - e esse javascript corrige o que o Primefaces quebra.

É um sumidouro de tempo - a menos que você use novamente coisas "prontas para uso". Também é muito feio (Primefaces) ao ter que trabalhar com Selenium. Tudo pode ser feito - mas, novamente - há tanto tempo.

Definitivamente, evite isso se você estiver trabalhando com uma equipe de UX / design e precisar iterar rapidamente na interface do usuário - você pode economizar tempo aprendendo jquery / escrevendo HTML direto - ou olhando para react / angular.

O JSF tem muitas vantagens, por estar em desvantagem, deixe-me acrescentar alguns pontos.

Em um cenário prático de implementação de um projeto da web em 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 que pode revisar o
  material JSF produzido pelos desenvolvedores?

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

O JSF possui apenas uma desvantagem: antes de iniciar o desenvolvimento do "JSF", você deve entender claramente o desenvolvimento da web, o java principal e a arquitetura de front-end.

Atualmente, as novas estruturas JavaScript apenas tentam copiar / colar o modelo baseado em componente "JSF".

Entre todas as estruturas "convencionais", como Spring MVC, Wicket, Tapeçaria, etc., o JSF do Java EE com seus componentes compostos é a camada de apresentação e a tecnologia orientada a componentes mais elaboradas fornecidas. É um pouco complicado e incompleto em comparação com as soluções fornecidas pelo HybridJava.