Razões para NÃO usar o JSF [fechado]

64

Eu sou novo no StackExchange, mas achei que você poderia me ajudar.

Estamos criando um novo aplicativo Java Enterprise, substituindo uma solução JSP herdada. Devido a muitas mudanças, a interface do usuário e partes da lógica de negócios serão completamente repensadas e reimplementadas.

Nosso primeiro pensamento foi o JSF, pois é o padrão no Java EE. No começo, tive uma boa impressão. Mas agora estou tentando implementar um protótipo funcional e tenho algumas preocupações realmente sérias sobre o uso.

Primeiro, ele cria a pior e mais desorganizada mistura de pseudo-HTML / CSS / JS inválida que eu já vi. Ele viola todas as regras que aprendi no desenvolvimento da web. Além disso, ele se une, o que nunca deve ser tão fortemente associado: Layout, Design, Lógica e Comunicação com o servidor. Não vejo como eu seria capaz de estender essa saída confortavelmente, seja estilizando com CSS, adicionando candy de interface do usuário (como teclas de atalho configuráveis, widgets de arrastar e soltar) ou qualquer outra coisa.

Em segundo lugar, é muito complicado. Sua complexidade é notável. Se você me perguntar, é uma abstração pobre de tecnologias básicas da Web, aleijada e inútil no final. Quais benefícios eu tenho? Nenhuma, se você pensar. Centenas de componentes? Vejo dez mil trechos de HTML / CSS, dez mil trechos de JavaScript e milhares de plug-ins do jQuery. Resolve realmente muitos problemas - não teríamos se não usássemos o JSF. Ou o padrão do controlador frontal.

E, finalmente, acho que teremos que começar de novo daqui a 2 anos. Não vejo como posso implementar todo o nosso primeiro modelo de GUI (além disso, não temos nenhum JSF Expert em nossa equipe). Talvez pudéssemos hackear juntos de alguma maneira. E então haverá mais. Tenho certeza de que poderíamos hackear nosso hack. Mas em algum momento, estaremos presos. Devido a tudo acima, a camada de serviço está no controle do JSF. E teremos que começar de novo.

Minha sugestão seria implementar uma API REST, usando JAX-RS. Em seguida, crie um cliente HTML5 / Javascript com o MVC do lado do cliente. (ou algum sabor do MVC ..) A propósito; de qualquer maneira, precisaremos da API REST, pois também estamos desenvolvendo um front-end parcial para Android.

Duvido que o JSF seja a melhor solução hoje em dia. À medida que a Internet está evoluindo, realmente não vejo por que devemos usar esse 'rake'.

Agora, o que são prós / contras? Como posso enfatizar meu argumento de não usar o JSF? Quais são os pontos fortes do uso do JSF em relação à minha sugestão?

— Bruno Schäpper
fonte

24

Essa é uma pergunta bem escrita de um novo usuário. Considere deixar um comentário ao fazer um voto negativo.

— ThiefMaster

2

Como você está reescrevendo tudo, eu consideraria não apenas usar o JSF, mas também não usar o Java. Linguagens de script modernas (por exemplo, não PHP ou Perl) são bastante agradáveis e amigáveis ao desenvolvedor.

— ThiefMaster

11

Não diminuí o voto, mas isso não é uma pergunta, é um discurso retórico. Vain decidiu que odeia o JSF, agora pede mais motivos para não usá-lo?

— 22612 Michael Borgwardt

4

Java é a melhor opção se o seu aplicativo for grande (complexo e / ou escalável) e / ou distribuído, usando muitos serviços; se seu aplicativo não se encaixa nessa categoria (não é tão complexo e não precisa ser escalonável), então Python (Django) ou Ruby (Rails) seriam melhores opções. A complexidade do JSF tem os benefícios do poder que ele traz; Como alternativa, você deve dar uma olhada em outros Web Frameworks, como Spring MVC ou Struts 2, se Java for obrigatório.

— M3th0dman

14

Este é um discurso retórico à procura de backup, não uma pergunta como tal.

26

Há pelo menos uma boa razão para considerar o JSF.

É uma parte padrão da pilha do Java EE e, portanto, estará disponível - e funcionando - em TODOS os contêineres do Java EE por um período muito, muito longo. E mantido também, sem a necessidade de fazê-lo se você aderiu estritamente à especificação Java EE.

Se essa é uma preocupação para você, considere-a. A maioria dos softwares vive mais do que seus designers pensam, especialmente se levados em consideração ao serem escritos.

4

Não tenho certeza sobre isso. Para o J2EE, as palavras 'standard' e 'working' não são escritas em pedra, especialmente quando falamos de um sistema que será / deve ser suportado por muitos anos, incluindo alterações na versão do j2ee usada.

— magallanes

7

Na minha experiência (limitada) com JSF, esse argumento realmente não se aplica. Vi aplicativos ficarem presos com uma versão do JSF e nenhum caminho de migração são para uma versão mais recente. Certamente, o servidor de aplicativos ainda o executou, mas esse foi o suporte que você obteria se não tivesse muito dinheiro para gastar em contratos de suporte muito caros.

— Jens Schauder

@JensSchauder, minha experiência é que você pode escrever aplicativos portáteis, migrar e atualizar sua versão do jsf. Isso envolve conhecer as especificações e codificá-las, não para sua implementação. Funciona, pois a codificação para JPA em vez de Hibernate funciona. Faz isso há anos.

— ymajoros

14

Agora, o que são prós / contras? Como posso enfatizar meu argumento de não usar o JSF? Quais são os pontos fortes do uso do JSF em relação à minha sugestão?

Você já parece ter se decidido sobre os contras, e eu tenho que concordar com alguns deles (ele não separa o layout e a lógica o suficiente, e o HTML resultante é muitas vezes atroz), mas discorda dos outros (se você usar Facelets, que eu recomendaria muito, então a saída deve definitivamente ser válida).

Então, aqui estão alguns profissionais:

Existem algumas bibliotecas de componentes muito poderosas, como PrimceFaces ou RichFaces, que oferecem muitas funcionalidades prontas para uso. Isso pode poupar muito trabalho se eles atenderem aos seus requisitos (nem tanto se você tiver requisitos não negociáveis não cobertos por eles).
Os componentes compostos oferecem uma maneira muito limpa de modularizar suas páginas
O JSF se integra muito bem ao restante do Java EE
AJAX via re-renderização de componentes é realmente fácil e conveniente

Mas certamente nenhuma dessas vantagens é tão grande que você deve usar o JSF sobre alguma outra estrutura com a qual sua equipe já tenha experiência.

— Michael Borgwardt
fonte

11

Não são os IDs, são atributos inválidos. Como "role" e "ária-expandida" na visualização de guia. Você sabe como consertar isso?

— Bruno Schäpper

11

@Vain: não, parece ser uma questão diferente, talvez com um componente que eu não usei ou que seja novo. É possível alterar a saída HTML dos componentes JSF especificando um representante alternativo (que, idealmente, substitui um ou dois métodos do representante padrão), mas é claro que isso não é algo que você deve fazer apenas para obter uma marcação válida.

— 22612 Michael Borgwardt

11

O HTML atroz é devido à implementação usada. Entendo que o modo de depuração da implementação de JSF de referência é especialmente ruim nisso. Você conheceria melhores configurações para produzir HTML melhor?

11

@ Thorbjørn Ravn Andersen Sim, o problema com HTML inválido é realmente um problema do PrimeFaces. Nós o usamos porque é construído em jQuery-UI. Qual é o seu conselho; devo usar outra biblioteca? Eu realmente gosto de HTML válido. Para mim, é simplesmente uma obrigação.

— Bruno Schäpper

11

Revisitando minha primeira pergunta aqui, gostaria de compartilhar alguma experiência sobre seus profissionais: estamos trabalhando com o JSF e, com essa experiência, não a escolheríamos novamente. Quase nada funciona como esperado e pronto para uso. Sim, existem bibliotecas poderosas. Mas acabamos fazendo todos os nossos componentes, porque eles não funcionavam exatamente como precisávamos. É impressionante a rapidez com que tivemos nossa própria 'DataTable' com carregamento lento durante a rolagem. Os componentes compostos não funcionaram para nós, não sei dizer por que, eles são de buggy, eu acho. A re-renderização de AJAX é realmente um problema para o JS do lado do cliente.

— Bruno Schäpper

9

O JSF é uma estrutura da Web adequada e estável para Java, que é um padrão, o que significa que é suportado imediatamente por muitos fornecedores importantes (incluindo os FOSS). Possui forte suporte a bibliotecas de terceiros (PrimeFaces, IceFaces etc.). No entanto, fundamentalmente "quebra a web" devido à sua natureza estável (e várias outras coisas). Veja a comparação de Matt Raible das estruturas da Web baseadas em JVM , o JSF geralmente chega perto do último.

Editar - com o JSF 2.2 - você pode começar a argumentar que ele não quebra a Web tanto quanto antes. Na verdade, a integração com HTML5 não é de todo terrível :-).

— Martijn Verburg
fonte

11

Isso 'quebra a web', de fato. E obrigado pela comparação de Matt Raible, não sabia disso.

— Bruno Schäpper

3

Observe que o JSF não é necessariamente com estado. Concordo que sim, mas existe um suporte muito bom para solicitações baseadas em GET sem estado e, se você não usar um formulário, não haverá nenhum estado.

— Arjan Tijms

Bom ponto Arjan, acho que acabei de ver muitos usos com estado.

— Martijn Verburg

Link para a apresentação de Raible: slideshare.net/mraible/…

— zaidaus

6

Tínhamos um aplicativo JSP / Struts 1.0 herdado. Nós pulamos o Struts 2, o JSF e tudo o mais que aconteceu desde o Struts 1 e pulamos para o Spring 3.0. Possui suporte (e uma comunidade ativa) para a nossa lista de desejos - IDE Eclipse, MVC e REST. Além disso, descartamos nosso Javascript / ajax caseiro vintage para jquery.

YMMV, mas a primavera tem sido uma migração suave para nós.

— jqa
fonte