Eu sou novo no StackExchange, mas imaginei que você seria capaz de me ajudar.
Estamos criando um novo aplicativo Java Enterprise, substituindo uma solução JSP legada. Devido a muitas alterações, a interface do usuário e partes da lógica de negócios serão completamente repensadas e reimplementadas.
Nosso primeiro pensamento foi JSF, como é o padrão no Java EE. No começo eu tive uma boa impressão. Mas agora estou tentando implementar um protótipo funcional e tenho algumas preocupações realmente sérias sobre usá-lo.
Primeiro, ele cria o pior pseudo-HTML / CSS / JS inválido que já vi. Viola todas as regras que aprendi no desenvolvimento da web. Além disso, ele joga junto, o que nunca deve ser tão strongmente acoplado: Layout, Design, Logic e Comunicação com o servidor. Eu não vejo como eu seria capaz de estender essa saída confortavelmente, seja estilo com CSS, adicionando doces de interface do usuário (como teclas de atalho configuráveis, arrastar e soltar widgets) ou qualquer outra coisa.
Em segundo lugar, é muito complicado. Sua complexidade é excelente. Se você me perguntar, é uma má abstração de tecnologias web básicas, aleijadas e inúteis no final. Quais benefícios eu tenho? Nenhum, se você pensar. Centenas de componentes? Eu vejo dezenas de milhares de snippets HTML / CSS, dez mil snippets de JavaScript e milhares de plug-ins do jQuery. Resolve muitos problemas - não teríamos se não usássemos o JSF. Ou o padrão do controlador frontal em tudo.
E, finalmente, acho que teremos que começar de novo, digamos, dois anos. Não vejo como posso implementar todo o nosso primeiro mock-up de GUI (além disso, não temos JSF Expert em nossa equipe). Talvez pudéssemos hackear tudo de alguma forma. E então haverá mais. Tenho certeza 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 o JAX-RS. Em seguida, crie um cliente HTML5 / Javascript com o MVC do lado do cliente. (ou algum sabor de MVC ..) By the way; nós precisaremos da API REST, já que estamos desenvolvendo um front-end Android parcial também.
Eu duvido que o JSF seja a melhor solução hoje em dia. Como a Internet está evoluindo, eu realmente não vejo por que devemos usar esse 'rake'.
Agora, quais são as vantagens / desvantagens? Como posso enfatizar meu ponto de não usar o JSF? Quais são os pontos strongs para usar o JSF sobre minha sugestão?
Há pelo menos uma boa razão para considerar o JSF.
É uma parte padrão da pilha Java EE e, portanto, estará disponível - e trabalhando - em TODOS os contêineres Java EE por muito, muito tempo. E mantido também, sem que você precise fazer isso se tiver aderido estritamente à especificação Java EE.
Se isso é uma preocupação para você, então você deve considerar isso. A maioria dos softwares vive mais do que seus designers pensam, especialmente se levados em consideração ao serem gravados.
Now, what are pros/cons? How can I emphasize my point to not use JSF? What are strong points to use JSF over my suggestion?
Você já parece ter feito a sua mente sobre os contras, e eu tenho que lidar com alguns deles (ele não separa layout e lógica o suficiente, e o HTML resultante é freqüentemente atroz), mas discordo de outros ( se você usar o Facelets, o que eu recomendo, então a saída deve ser válida).
Então, aqui estão algumas vantagens:
Mas certamente nenhuma dessas vantagens é tão grande que você deve usar o JSF em algum outro framework que sua equipe já tenha experiência.
O JSF é uma estrutura da Web com status adequado para Java, que é um padrão, o que significa que é suportado por muitos fornecedores principais (incluindo os FOSS). Tem strong suporte de biblioteca de terceiros (PrimeFaces, IceFaces etc). No entanto, ele basicamente "quebra a web" devido à sua natureza de estado (e um monte de outras coisas). Veja A comparação de Matt Raible de frameworks web baseados em JVM , JSF geralmente chega perto do último.
Editar - com o JSF 2.2 - você pode começar a argumentar que não quebra a Web tanto quanto antes. Na verdade, a integração do HTML5 não é tão terrível: -).
Tivemos um aplicativo legado JSP / Struts 1.0. Nós pulamos o Struts 2, JSF e tudo mais que aconteceu desde o Struts 1 e pulamos para o Spring 3.0. Ele tem suporte (e uma comunidade ativa) para nossa lista de desejos - Eclipse IDE, MVC e REST. Além disso, nós abandonamos nosso JavaScript / ajax caseiro vintage para jquery.
O YMMV, mas o Spring tem sido uma migração tranquila para nós.