ti-enxame.com

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

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

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

Então minhas perguntas são:

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

Desvantagens do JSF 2.0? Honestamente, além da relativa curva de aprendizado, quando você não tem um conhecimento sólido sobre Desenvolvimento básico da Web (HTML/CSS/JS, lado do servidor versus lado do cliente, etc) e o basic Java API do Servlet (request/response/session, forwarding/redirecting, etc), nenhuma desvantagem séria vem à mente. JSF em seu lançamento atual ainda precisa se livrar da imagem negativa que ganhou durante as primeiras idades, durante o qual houve várias desvantagens sérias.

JSF 1.0 (março de 2004)

Este foi o lançamento inicial. Ele estava cheio de bugs nas áreas centrais e de desempenho que você não quer conhecer. Seu aplicativo da Web nem sempre funcionava como você esperava intuitivamente. Você como desenvolvedor iria correr muito longe chorando.

JSF 1.1 (maio de 2004)

Esta foi a versão do bugfix. O desempenho ainda não foi muito melhorado. Houve também uma grande desvantagem: você não pode alinhar HTML na página JSF sem falhas. Todos os HTML simples e baunilha são renderizados before a árvore de componentes do JSF. Você precisa colocar todas as tags Vanilla simples em <f:verbatim> para que elas sejam incluídas na árvore de componentes do JSF. Embora isso fosse conforme a especificação, isso recebeu muitas críticas. Veja também um.o. JSF/Facelets: por que não é uma boa idéia misturar JSF/Facelets com tags HTML?

JSF 1.2 (maio de 2006)

Este foi o primeiro lançamento da nova equipe de desenvolvimento do JSF liderada por Ryan Lubke. A nova equipe fez um ótimo trabalho. Houve também mudanças na especificação. A principal mudança foi a melhoria do tratamento de visualizações. Isso não apenas desvinculou completamente o JSF do JSP, portanto, era possível usar uma tecnologia de visualização diferente do JSP, mas também permitia que os desenvolvedores incluíssem o HTML simples do Vanilla na página JSF sem incomodar com as tags <f:verbatim>. Outro grande foco da nova equipe foi melhorar o desempenho. Durante o tempo de vida da Implementação de Referência JSF da Sun 1.2 (que recebeu o codinome Mojarra desde a compilação 1.2_08, por volta de 2008), praticamente todas as construções foram fornecidas com melhorias de desempenho (principais) ao lado correções de bugs usuais (menores).

A única desvantagem séria do JSF 1.x (incluindo 1.2) é a falta de um escopo entre o escopo request and session , o chamado escopo conversation . Isso forçou os desenvolvedores a lidar com elementos de entrada ocultos, consultas de banco de dados desnecessárias e/ou abusar do escopo de sessão sempre que alguém quiser manter 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 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 MyFaces Tomahawk<t:saveState> component, JBoss Seam escopo de conversação e MyFaces Orquestra quadro de conversação.

Outra desvantagem para os puristas de HTML/CSS é que o JSF usa o cólon : 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 (modelando, iterando componentes, 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 até #formId\3A fieldId {}. Veja também Como usar o ID do elemento HTML gerado pelo JSF com dois pontos ":" em 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 era fornecido com os recursos do Ajax fora da caixa. 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 foi cedo para introduzir o Ajax4jsf, que foi completamente desenvolvido durante os anos e se tornou parte essencial da biblioteca de componentes JBoss RichFaces . Outras bibliotecas de componentes foram distribuídas com poderes Ajax embutidos também, sendo a mais conhecida ICEfaces .

Mais ou menos na metade do tempo de vida do JSF 1.2, uma nova tecnologia de visã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 ). Veja também Por que os Facelets são preferidos sobre JSP como a linguagem de definição de visualização do JSF2.0 em diante?

Poderes Ajax foram introduzidos no sabor do componente <f:ajax> que tem muitas semelhanças com o Ajax4jsf. Anotações e aprimoramentos de convenção sobre configuração foram introduzidos para kill o arquivo faces-config.xml detalhado o máximo possível. Além disso, o caractere separador de ID do contêiner de nomenclatura padrão : tornou-se configurável, portanto os puristas de HTML/CSS poderiam respirar aliviados. Tudo o 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 caracter em qualquer lugar nos IDs do cliente, como -.

Por último, mas não menos importante, um novo escopo foi introduzido, o escopo view . Eliminou outra importante desvantagem do JSF 1.x, conforme descrito anteriormente. Você acabou de declarar o bean @ViewScoped para habilitar o escopo de conversação sem incomodar todas as maneiras de reter os dados em solicitações subseqüentes (conversacionais). Um @ViewScoped bean viverá enquanto você estiver subseqüentemente enviando e navegando para a mesma visualização (independentemente da guia/janela do navegador aberta!), De forma síncrona ou assíncrona (Ajax). Veja também Diferença entre o escopo View e Request nos beans gerenciados e Como escolher o escopo correto 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 obstáculo. O @ViewScoped falha em manipuladores de tag devido a um problema de ovo de galinha em economia de estado parcial. Isso é corrigido no JSF 2.2 e backported em Mojarra 2.1.18. Também a passagem de atributos personalizados como o HTML5 data-xxx não é suportada. Isso é corrigido no JSF 2.2 pelo novo recurso de elementos/atributos de repasse. Além disso, a implementação do JSF Mojarra possui seu próprio conjunto de problemas . Relativamente, muitos deles estão relacionados com o comportamento às vezes não intuitivo de <ui:repeat> , o nova implementação de economia de estado parcial e o escopo flash mal implementado . A maioria deles é corrigida em uma versão Mojarra 2.2.x.

Em torno do tempo 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-chave, apesar de tecnicamente apenas ter suporte em todas as versões mais antigas do JSF. Veja também Suporte ao JavaServer Faces 2.2 e HTML5, por que o XHTML ainda está sendo usado . O novo recurso JSF 2.2 mais importante é o suporte para atributos de componentes personalizados, abrindo assim um mundo de possibilidades, como grupos de botões de opções tableless personalizados .

Além de erros específicos de implementação e algumas "pequenas coisas 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 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 sobre o HTML/CSS/JS gerado. Isso não é do próprio JSF, só porque é um framework based component MVC, não um framework = request (action) based MVC. Se um alto grau de controle do HTML/CSS/JS for o seu principal requisito ao considerar um framework MVC, então você já não deveria estar olhando para um framework MVC baseado em componente, mas em um framework MVC baseado em solicitação como Spring MVC . Você só precisa levar em conta que você terá que escrever todo esse clichê HTML/CSS/JS. Veja também Diferença entre o Pedido MVC e o Componente MVC .

Veja também:

456
BalusC

Depois de 5 anos trabalhando com o JSF, acho que posso adicionar meus 2 centavos.

Dois principais JSF desvantagens:

  1. Grande curva de aprendizado. O JSF é complexo, isso é verdade.
  2. Sua componente natureza. A estrutura baseada em componentes tenta esconder a verdadeira natureza da Web, que vem com uma enorme quantidade de complicações e desastres (como não suportar o GET no JSF em quase 5 anos).
    IMHO escondendo HTTP Request/Response do desenvolvedor é um enorme erro. Pela minha experiência, toda estrutura baseada em componente adiciona abstração ao desenvolvimento da 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 dos pais, por exemplo form1: button1.
  2. Não há maneira fácil de comentar o fragmento da página incorreta. A tag <ui:remove> precisa de conteúdo sintaticamente correto que seja analisado de qualquer maneira.
  3. Componentes de terceiros de baixa qualidade que, e. não marque isRendered() dentro do método processXxx() 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 os designers de UX, porque os componentes prontos para uso têm seus próprios estilos CSS, que precisam ser sobrescritos.

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

Por favor, dê uma olhada na baixa popularidade da Tapeçaria, Wicket e baixo entusiasmo de desenvolvedores JSF experientes (o que é ainda mais significativo). E, para contraste, dê uma olhada no sucesso do Rails, Grails, Django, Play! Framework - todos eles são baseados em ações e não tentam se esconder do programador verdadeiro pedido/resposta e natureza sem estado da web.

Para mim é uma grande desvantagem do JSF. IMHO O JSF pode atender a alguns tipos de aplicativos (intranet, formulários intensivos), mas para aplicativos da vida real web não é um bom caminho a percorrer.

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

53
G. Demecki

Algumas desvantagens que me vêm à mente:

  1. O JSF é um framework baseado em componentes. Isto tem restrições inerentes que têm a ver com obedecer ao modelo de componente.
  2. O AFAIK JSF suporta apenas o POST, portanto, se você quiser um GET em algum lugar, terá que executar um servlet simples/JSP.
  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 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 para desempenho, pois há várias camadas envolvidas e a maioria das pessoas que as usam tem pouca compreensão do que está acontecendo sob o capô.
  5. Os mecanismos de modelagem que são geralmente usados ​​com o JSF não têm nada a ver com o funcionamento dos desigers da web. Os editores WYSIWYG para o JSF são primitivos e, em qualquer caso, o designer lhe dará HTML/CSS que você terá que gastar com a conversão de anos.
  6. Coisas como EL expressões não são estaticamente verificadas e tanto o compilador e IDEs não estão fazendo um bom trabalho em encontrar erros, então você vai acabar com erros que você terá que pegar em tempo de execução. Isso pode ser bom para linguagem tipada dinamicamente como Ruby ou PHP, mas se eu tiver que suportar o inchaço do ecossistema Java, eu exijo digitando para meus templates.

Para resumir: A hora que você irá salvar com o JSF, evitando escrever o código JSP/servlet/bean, você vai gastar x10 para fazer a escala e fazer exatamente o que você quer Faz.

24
Kay Pale

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 você não precisa saber disso.
  • HTTP - quando você não consegue descobrir o que está acontecendo, você tem que abrir o Firebug e ver. Para isso você precisa saber disso.
  • CSS - Goste ou não. Não é tão ruim assim e existem algumas boas ferramentas lá fora, pelo menos.
  • XML - O JSF provavelmente será o primeiro lugar a usar namespaces nesse grau.
  • Especificação de servlet. Mais cedo ou mais tarde você vai entrar em métodos de chamada neste pacote. Além disso, você precisa saber como seus Facelets são transformados em XHTML ou qualquer outra coisa.
  • JSP (principalmente para você saber por que você não precisa disso no JSF)
  • JSTL (novamente, principalmente para lidar com o framework legado)
  • Expression Language (EL) em suas várias formas.
  • ECMAScript, JavaScript, ou qualquer outro nome que você queira chamar.
  • JSON - você deve saber disso mesmo que não use.
  • AJAX. Eu diria que o JSF 2.0 faz um trabalho decente de esconder isso de você, mas você ainda precisa saber o que está acontecendo.
  • O DOM. E como um navegador usa isso. Veja ECMAScript.
  • Eventos DOM - um tópico por si só.
  • Java Persistence Architecture (JPA), ou seja, se você quiser que seu aplicativo tenha uma base de dados de back-end.
  • Java em si.
  • JSEE enquanto você está nisso.
  • A especificação Context Injection Dependency Injection (CDI) e como ela se choca e é usada com o JSF 2.0
  • JQuery - Eu gostaria de ver você se dando bem sem isso.

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

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

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

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

Então - ESTE IS FAZENDO FÁCIL? 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 incômoda de tecnologias coladas como existe hoje no universo do software. E não consigo pensar em nada que prefira usar.

18
AlanObject
  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 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 "preso" em algum problema e vai gastar mais tempo lendo posts Balcul na internet do que realmente trabalhando :) Depois de um tempo, será cada vez menos, mas ainda pode ser irritante.
  3. Ainda mais irritante quando você descobre que o problema não é devido a sua falta de conhecimento/erro, mas na verdade um bug. Mojarra foi (é?) Bastante buggy, e outra camada de componentes adiciona ainda mais problemas. Richfaces foi o maior software de porcaria já escrito :) Não sei como é agora na versão 4. Temos Primefaces, que é melhor, mas ainda assim você vai 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á ficando melhor, especialmente após a versão 2.2 corrigiu alguns problemas com spec. Framework ficando mais maduro, mas ainda longe de ser perfeito (talvez myfaces melhor?).
  4. Eu 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 - aquele com prazos, tutoriais de leitura rápida e pesquisando stackoverflow quando ficar preso porque não há tempo para aprender como ele 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 algo que você quer :) Precisa ter cuidado ao avaliar se é melhor criar seu próprio componente ou torturar o existente. Na verdade, se você está criando algo realmente único, eu não recomendaria o JSF.

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

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

12
Koks Skirtumas

"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 dá a você a flexibilidade, você pode usar componentes padrão/de terceiros ou criar seus próprios que você tem controle total sobre o que é renderizado. É apenas um xhtml que você precisa para criar seus componentes personalizados com o JSF 2.0.

11
Cagatay Civici

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

Nós tentamos usar o core jsf, se um componente é 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 tem dois casos:

  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 tem 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 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 tornar o estado de visualização do JSF fixo. O estado do JSF será corrompido quando você incluir páginas via ajax umas nas outras. Isso parece um bug no JSF e pode ser corrigido nas próximas versões (não em 2.3).
  2. O Fluxo do JSF não está funcionando corretamente com o ajax (ou nós não poderíamos fazê-lo funcionar!) Tentamos usar o componente wizard do primeface em seu lugar, mas a validação do cliente não é suportada e significa que não é padrão JSF.
  3. Ao usar alguns componentes do jQuery, como o jqGird, e você precisa carregar os resultados do JSON, é aconselhável usar o servlet puro. O JSF não fará nada por você. Então, se você usar esse tipo de componente, seu design não se encaixará no JSF.
  4. Tentamos fazer alguns scripts de cliente quando o ajax é completado por ajaxComplete e descobrimos que o PF 4 implementou seus próprios eventos de ajax. Nós tivemos alguns componentes do jQuery e precisamos mudar o código deles.

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

Nós 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 de projeto.

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

9
Alireza Fattahi

Eu não sou um 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 da Web do servidor como ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, frameworks php e Ruby em Rails frameworks. 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 ele é servido pelo Windows IIS executando o php ou o ASP.NET, ou se ele é servido por um servidor da Web Apache em execução no Linux. Eu só preciso aprender apenas uma estrutura que funcione em todos os lugares.

Apenas meus dois centavos.

9
Jesús López

Comentando nos meus últimos meses da experiência Primefaces/JSF:

  • Se você pode usar componentes "na prateleira", eu acho que não é terrível.
  • No entanto, ele não funciona bem assim que você sai e precisa de interfaces de usuário personalizadas. - Por exemplo, precisávamos usar o bootstrapdo Twitter para o nosso projeto. (Não primefaces bootstrap).
    • Agora nossas páginas funcionam da seguinte maneira:
      • Carregamentos de página.
      • O usuário interage com um Primefaces que possui a funcionalidade ajax
      • As ligações de javascript de Bootstrap quebram
      • Nós corremos javascript extra para revincular tudo

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

É um coletor de tempo - a menos que você use de novo coisas "fora da prateleira". Também realmente feio (Primefaces) ao ter 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 interface do usuário - você pode economizar tempo aprendendo jquery/escrevendo HTML direto - ou observando a reação/angular.

6
rprasad

Para mim, a maior falha do JSF é o fraco suporte para páginas geradas programaticamente (dinamicamente).
Se você quiser construir sua página (criar modelo de componente de página) dinamicamente a partir de Java código. Por exemplo, se você estiver trabalhando no construtor de páginas da Web WYSIWYG. Documentação adequada deste caso de uso em geral não disponível. Há muitos pontos em que você tem que experimentar e o desenvolvimento é lento e lento. Muitas coisas simplesmente não funcionam como você esperaria. Mas geralmente é possível hackear de alguma forma.
Boa coisa é que não é problema na filosofia ou arquitetura do JSF. Simplesmente não é elaborado o suficiente (tanto quanto eu sei).

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

Mas parece que a comunidade do JSF está ciente dessas 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 deve ser melhor com o JSF 2.2, pelo menos, se estamos falando de especificação.

5
Ondrej Bozek

JSF tem muitas vantagens, pergunta estar em desvantagem, deixe-me adicionar alguns pontos sobre ele.

Em um cenário prático de implementação de um projeto web em um período de tempo, 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 a largura de banda para acomodar a curva de aprendizado inicial?

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

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

1
Sam

Entre todas as estruturas "mainstream", como Spring MVC, Wicket, Tapestry, etc., o JSF de 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.

0
Dima

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

Atualmente, os "novos" frameworks JavaScript tentam copiar/colar o modelo baseado em componente "JSF".

0
Armen Arzumanyan