Quais são os prós e os contras dos diversos frameworks Java da web? [fechadas]

Estou pensando em criar meu próprio site usando Java e estou tentando decidir qual estrutura usar. No entanto, fazer uma pesquisa rápida por estruturas Java retorna mais de 50 para escolher!

Meu site vai ser apenas para o meu próprio prazer de construí-lo no começo, mas se ele se tornar popular, seria bom que ele tivesse alguma escalabilidade, ou pelo menos ser capaz de redesenhar para isso.

Quais são as principais diferenças entre os frameworks mais populares? Existem casos em que um supera significativamente os outros? Por exemplo, aplicativos corporativos de alto tráfego versus aplicativos pequenos de baixo tráfego. Também estou me perguntando se alguns são muito mais fáceis de aprender e usar do que outros.

Há alguém que tenha experiência com algumas dessas estruturas e possa fazer uma recomendação? O grande número de opções serve apenas como um aviso antecipado para evitar o desenvolvimento da Web baseado em Java, sempre que possível?

Usei Tapestry 3 , Wicket , Echo e JSF bastante extensivamente. Eu realmente recomendo que você dê uma olhada neles e escolha aquele que parece mais fácil para você e que se encaixa melhor na maneira como você prefere trabalhar.

Deles, o mais confortável para eu trabalhar foi o Wicket , devido à natureza leve da construção de componentes e à simplicidade da modelagem de páginas. Isso acontece duplamente se você estiver usando seu próprio código db em vez do Hibernate ou alguma outra estrutura (eu nunca fiquei completamente feliz com o Wicket Hibernate ou Spring Integration).

O Echo é ótimo se você não se importa em escrever todo o seu layout em Java. Sei que agora é diferente, mas ainda acho que esse produto atende a um nicho bastante restrito. Eles mudam o modelo de desenvolvimento a cada lançamento importante, assim parece.

Tapeçaria é um ótimo produto, mas é obviamente muito diferente dos outros em termos de modelo de desenvolvimento, pois é liderado principalmente por um cara. Howard Lewis Ship é sem dúvida muito inteligente, mas estou desapontado com a decisão deles de basicamente esquecer a compatibilidade com versões anteriores a cada lançamento. Mais uma vez, porém, para suas necessidades isso pode não importar, e sempre achei os produtos Tapestry agradáveis ​​de se trabalhar.

JSF já existe há anos e ainda parece algo que um cara do Struts construiu para consertar todos os problemas do Struts. Sem realmente entender todos os problemas com o Struts. Ainda tem uma sensação inacabada, embora o produto seja obviamente muito flexível. Eu o uso e tenho algum carinho por ele, com grandes esperanças para o seu futuro. Eu acho que o próximo lançamento (2.0) a ser entregue em JEE6 realmente o trará em seu próprio, com uma nova sintaxe de template (semelhante ao Facelets) e um modelo de componente simplificado (componentes customizados em apenas 1 arquivo ... finalmente).

E, claro, há um milhão de frameworks e ferramentas menores que obtêm seus próprios seguidores ( Velocity para necessidades básicas, JSPs brutos , Struts, etc). No entanto, geralmente prefiro frameworks orientados a componentes.

No final, eu recomendo apenas dar uma olhada em Tapestry, Wicket e JSF e escolher apenas aquele que parecer melhor para você. Provavelmente, você encontrará um que se encaixa na maneira como gosta de trabalhar muito rapidamente.

Meu favorito é o Spring Framework. Com 2.5 Spring MVC é tããão chutão, com novas anotações, convenções sobre recursos de configuração, etc.

Se você está fazendo algo super simples, você também pode tentar usar a API Servlet regular e não se preocupar com uma estrutura.

Eu recomendo a estrutura Wicket orientada a componentes . Ele permite que você escreva seu aplicativo da web em código Java simples e antigo, você pode usar POJOs como o modelo para todos os componentes e não precisa mexer com enormes arquivos de configuração XML.

Eu tinha desenvolvido com sucesso um aplicativo de banco online com Struts quando descobri o Wicket e vi como o desenvolvimento de aplicativos da web pode ser fácil!

Recentemente, comecei a usar o Stripes Framework . Se você está procurando uma estrutura baseada em solicitação que seja realmente fácil de usar, mas não impõe nenhum limite ao que você está fazendo, eu a recomendo.

É semelhante a struts, mas vai muito além disso. Existem até alguns projetos de plugins que permitem que você use o hibernate ou jpa com muito pouca configuração.

Existem muitos frameworks bons por aí, embora eu tenha ouvido falar que o wicket também é um bom, mas não o usei.

Ainda não experimentei, mas acho

http://www.playframework.org/

tem muito potencial ...

vindo do php e do asp clássico, é o primeiro framework web java que parece promissor para mim ....

ATUALIZAÇÃO: Tapestry 5.2 foi lançado, então não foi abandonado, como parecia estar. Minha experiência é com Tapestry 4, não 5, então sua milhagem pode variar. Minha opinião sobre a Tapeçaria mudou ao longo dos anos; Eu modifiquei esta postagem para refletir isso.

Não posso mais recomendar Tapestry como fazia anteriormente. O Tapestry 5 parece ser uma melhoria significativa, mas meu principal problema com o Tapestry não é a plataforma em si; está com as pessoas por trás disso.

Historicamente, cada atualização de versão principal do Tapestry quebrou a compatibilidade com versões anteriores com extremo prejuízo, muito mais do que se poderia esperar. Isso parece ser devido à incorporação de novas técnicas ou tecnologias de codificação que requerem reescritas significativas.

Howard Lewis Ship (o autor principal de Tapestry) é certamente um desenvolvedor brilhante, mas não posso dizer que me importo com o gerenciamento do projeto Tapestry. O desenvolvimento do Tapestry 5 começou quase imediatamente após o lançamento do Tapestry 4. Pelo que posso dizer, Ship se dedicou muito a isso, deixando o Tapestry 4 nas mãos de outros colaboradores, que eu sinto que não são tão capazes quanto Ship. Depois de ter feito a dolorosa mudança de Tapestry 3 para Tapestry 4, senti que havia sido abandonado quase imediatamente.

Claro, com o lançamento do Tapestry 5, o Tapestry 4 se tornou um produto legado. Eu não teria problemas com isso se o caminho de atualização não fosse tão brutal novamente . Portanto, agora nossa equipe de desenvolvimento está em uma posição nada invejável: poderíamos continuar a usar uma plataforma da web essencialmente abandonada (Tapestry 4), fazer a atualização hedionda para Tapestry 5 ou desistir inteiramente de Tapestry e reescrever nosso aplicativo usando outra plataforma. Nenhuma dessas opções é muito atraente.

O Tapestry 5 é supostamente escrito de forma a reduzir a probabilidade de quebra da atualização a partir deste ponto. Um bom exemplo está nas classes de página: em encarnações anteriores, as classes de página descendiam de uma classe base fornecida pela Tapestry; alterações de API incompatíveis nesta classe foram a causa de um grande número de problemas de compatibilidade com versões anteriores. No Tapestry 5, as páginas são POJOs que são aprimoradas em tempo de execução com o "pó mágico da tapeçaria mágica" por meio de anotações. Portanto, desde que o contrato para as anotações seja mantido, as alterações em Tapestry não afetarão suas classes de página.

Se isso estiver certo, escrever um novo aplicativo usando o Tapestry 5 pode dar certo. Mas, pessoalmente, não estou com vontade de colocar minha mão no queimador de novo.

Disclamer: Eu trabalho na Vaadin (anteriormente IT Mill)

Se você está fazendo algo RIAish, pode dar uma olhada em Vaadin . É uma estrutura AJAX orientada para a IU de código aberto que, para mim, é agradável de usar (eu venho de uma experiência em PHP).

Há um estudo de caso que compara fazer o mesmo aplicativo (ou seja, dois aplicativos com o mesmo conjunto de recursos) no Icefaces e no Vaadin. Resumindo, ele afirma que o desenvolvimento da IU foi consideravelmente mais rápido.

Mesmo que o estudo esteja hospedado na wiki da empresa, posso garantir que é objetivo, genuíno e verdadeiro, embora não possa forçá-lo a acreditar em mim.

Depois de um longo tempo testando várias soluções, para mim acabou sendo:

• Spring MVC para a apresentação e camada de controlador (NO Spring Webflow, porque meus fluxos são baseados em ajax)

• jQuery para todas as coisas do lado do cliente

• Spring Security para o, bem, aspecto de segurança

• Hibernate / JPA2

• Jetty por uma questão de continuações (cometa)

Um mês de uma curva de aprendizado extraordinariamente acentuada, mas agora estou feliz.

Eu também gostaria de mencionar que eu estava apenas um passo longe de pular todo aquele material Java e aprender Scala / LIFT. No que me diz respeito, tudo em Java que está relacionado com desenvolvimento web de ponta (cometa, comunicação assíncrona, segurança (sim, mesmo com Spring Security!)) Ainda é um pouco hack (prove que estou errado por evidência, por favor !). Para mim, Scala / LIFT parece ser uma solução mais out-of-the-box e all-in-one.

A razão pela qual finalmente decidi não ir com Scala é

• como líder de projeto, devo considerar os recursos humanos e os desenvolvedores Java são muito mais fáceis de encontrar do que os desenvolvedores Scala

• para a maioria dos desenvolvedores da minha equipe, o conceito funcional do Scala, por mais excelente que seja, é difícil de entender

Cheers Er

Também ouvi coisas boas sobre o Spring Framework. Em geral, porém, não estou impressionado com a maioria dos frameworks Java da web que examinei (esp Struts).

Para um aplicativo simples, eu definitivamente consideraria usar servlets e JSPs "brutos" e não me preocuparia em adotar uma estrutura. Se os servlets forem bem escritos, deve ser simples no futuro portar para uma estrutura, se necessário, quando o aplicativo aumentar em complexidade.

Minha escolha é Wicket !!

Todos eles - esse é o problema ;-)

Eu acho que para seus requisitos modestos, você só precisa codificar servlets ou páginas jsp simples que podem servir a partir do servidor Tomcat. Eu não acho que você precisa de qualquer tipo de estrutura da web (como struts) para dados pessoais do site

Dizer "usar JSF" é um pouco simples. Ao decidir usar o JSF, você deve escolher uma biblioteca de componentes em cima dele. Você usará o MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ )? Ou talvez ICEfaces ( http://www.icefaces.org/ )? Ah, e se você usar ICEfaces, usará JSPs ou Facelets para suas visualizações?

Na minha opinião, é difícil dizer. Ninguém tem tempo para avaliar todas as alternativas promissoras, pelo menos nos projetos em que trabalho, porque não são grandes o suficiente para fazer fases de avaliação de três meses. No entanto, você deve procurar por algum que tenha uma comunidade grande e ativa e não vá embora por um ano. O JSF já existe há algum tempo e, como é empurrado pelo sol, ainda existirá por mais algum tempo. Não posso dizer se é a melhor escolha, mas será uma boa escolha.

http://zkoss.org - o bom

Para sites de alto tráfego, eu usaria uma estrutura que não gerencia o estado do cliente no servidor - Wicket, JSF e Tapestry estão gerenciando o estado do cliente no servidor. Eu só usaria essas estruturas (Wicket é meu favorito) se o aplicativo fosse mais parecido com um aplicativo de desktop. Mas eu tentaria usar uma abordagem REST + AJAX mais escalonável e simples.

Spring MVC seria um candidato, mas desde Spring MVC 3 ele tem um modelo de programação sobrecarregado de anotações estranho que não usa os benefícios da tipagem estática. Existem outras coisas desagradáveis, como parâmetros de saída em métodos combinados com um retorno normal, portanto, existem dois canais de saída para um método. Spring MVC também tende a reinventar a roda e você terá mais para configurar em comparação com outros frameworks. Eu realmente não posso recomendar o Spring MVC, embora ele tenha algumas boas idéias.

Grails é uma maneira conveniente de usar Spring MVC e outros frameworks estabelecidos como o Hibernate. Codificar é divertido e você verá resultados rapidamente.

E não se esqueça que a API Servlet com alguns ajudantes como o FreeMarker para modelagem é muito poderosa.

Eu avaliei alguns frameworks e Vaadin ( http://vaadin.com/home ) percolou todo o caminho até o topo.

Você deve pelo menos dar uma breve avaliação.

Felicidades!

Minha escolha seria Wicket (para grandes projetos e uma base de usuários previsível), GWT (para grandes projetos que são voltados principalmente para o público) ou apenas uma estrutura de serviço (como Jersey / JAXRS) junto com um kit de ferramentas JavaScript (para projetos pequenos e médios) .

Eu recomendo Seam, especialmente se você precisar de persistência.

Veja alguns comentários sobre alguns frameworks de aplicativos Java (segundo parágrafo):

http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html

Para uma interface gráfica rápida e sofisticada, você pode usar a biblioteca JSF com Richfaces . Os componentes da IU do Richfaces são fáceis de usar e referências úteis disponíveis com demonstração de código no site de demonstração. Provavelmente mais tarde, quando seu site tiver mais dados para lidar e muitas informações precisarem ser transacionadas no banco de dados, você poderá conectar qualquer estrutura de acesso ao banco de dados (ORM) com ele.

Não posso acreditar que ninguém mencionou GWT

Minha maneira favorita de usar aplicativos realmente simples é Apache VelocityTools (VelocityLayoutServlet) com Velosurf ( http://velosurf.sourceforge.net ).

Para aplicativos mais complexos, Spring MVC ou Struts 2.

Experimente HybridJava - isso é muito mais simples do que qualquer outra coisa.

Eu diria vaadin ou wicket