Quais são os prós e contras dos diversos frameworks web Java?

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

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

Quais são as principais diferenças entre os frameworks mais populares? Há 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.

Existe 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?

Eu usei Tapestry 3 , Wicket , Echo e JSF bastante extensivamente. Eu realmente recomendo que você olhe mais e escolha aquele que parece mais fácil para você, e para se encheckboxr mais na maneira que você prefere trabalhar.

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

Echo é ótimo se você não se importa de escrever todo o seu layout em Java. Eu sei que isso é diferente agora, mas eu ainda acho que o produto serve um nicho bastante estreito. Eles mudam o modelo de desenvolvimento com todos os lançamentos principais, bem como parece.

Tapeçaria é um ótimo produto, mas é obviamente muito diferente dos outros em termos de modelo de desenvolvimento, uma vez que é liderado principalmente por um cara. Howard Lewis Ship é, sem dúvida, bastante inteligente, mas estou decepcionado com a decisão deles de basicamente esquecer a compatibilidade retroativa com cada lançamento. Novamente, porém, para as suas necessidades isso pode não importar, e eu sempre achei os produtos da Tapestry prazerosos de se trabalhar.

O JSF está fora 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 uso e tenho um pouco de carinho por isso, com grandes esperanças para o futuro. Eu acho que a próxima versão (2.0) a ser entregue no JEE6 realmente trará isso para si, com uma nova syntax de template (semelhante a Facelets) e um modelo de componente simplificado (componentes customizados em apenas 1 arquivo … enfim).

E, é claro, existem milhões de estruturas e ferramentas menores que obtêm seus próprios seguidores ( velocidade para necessidades básicas, JSPs brutos, Struts, etc). Eu geralmente prefiro frameworks orientados a componente, no entanto.

No final, eu recomendo apenas dar uma olhada em Tapeçaria, Wicket e JSF e apenas escolher aquele que parece o melhor para você. Você provavelmente encontrará um que só se encheckbox do jeito que você gosta de trabalhar muito rapidamente.

Meu favorito é o Spring Framework. Com 2.5 Spring, o MVC é muito fácil, com novas annotations, convenções sobre resources de configuração, etc.

Se você está apenas fazendo algo super simples, você também pode tentar usar a API de Servlet normal e não se preocupar com um framework.

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

Eu desenvolvi com sucesso um aplicativo bancário on-line com o Struts quando descobri o Wicket e vi como o desenvolvimento de aplicativos da Web pode ser fácil.

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

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

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

Não tentei eu mesmo, mas eu acho

http://www.playframework.org/

tem muito potencial …

vindo de php e asp clássico, é o primeiro framework web java que som promissor para mim ….

ATUALIZAÇÃO: Tapeçaria 5.2 está fora, por isso não é abandonado, como parecia ser. Minha experiência é com Tapeçaria 4, não 5, assim sua milhagem pode variar. Minha opinião sobre a Tapeçaria mudou ao longo dos anos; Eu modifiquei este post para refletir isso.

Eu não posso mais recomendar Tapeçaria como fiz anteriormente. Tapeçaria 5 parece ser uma melhoria significativa, mas o meu principal problema com a Tapeçaria não é com a plataforma em si; é com as pessoas por trás disso.

Historicamente, todas as principais atualizações de versão da Tapeçaria quebraram a compatibilidade com o preconceito extremo, muito mais do que se poderia esperar. Isso parece ser devido à incorporação de novas técnicas de codificação ou tecnologias que exigem reescritas significativas.

Howard Lewis Ship (o principal autor de Tapeçaria) é certamente um desenvolvedor shiny, mas eu não posso dizer que me importo com sua gestão do projeto Tapeçaria. O desenvolvimento da tapeçaria 5 começou quase imediatamente após o envio da tapeçaria 4. Pelo que posso dizer, Ship praticamente se dedicou a isso, deixando 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 da Tapeçaria 3 para a Tapeçaria 4, senti que tinha sido abandonada quase que imediatamente.

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

Tapeçaria 5 é supostamente escrita de modo a reduzir a probabilidade de quebra de atualização deste ponto em diante. Um bom exemplo está nas classs de página: em encarnações anteriores, as classs de páginas descendiam de uma class base fornecida pela Tapestry; As alterações de API incompatíveis nessa class foram a causa de um grande número de problemas de compatibilidade com versões anteriores. Na Tapestry 5, as páginas são POJOs que são aprimoradas em tempo de execução com a “poeira de fada da tapeçaria mágica” por meio de annotations. Assim, enquanto o contrato para as annotations for mantido, as alterações na Tapeçaria não afetarão suas classs de página.

Se isso estiver certo, então escrever um novo aplicativo usando Tapestry 5 pode dar certo. Mas pessoalmente, não sinto vontade de colocar a mão no gravador novamente.

Disclamer: Eu trabalho na Vaadin (anteriormente IT Mill)

Se você está fazendo algo RIAish, você pode querer dar uma olhada em Vaadin . É um framework AJAX orientado a UI de código aberto que, para mim, é bom de usar (eu mesmo venho de um background em PHP).

Há um estudo de caso que compara fazer o mesmo aplicativo (ou seja, dois aplicativos com o mesmo conjunto de resources) em Icefaces e Vaadin. Em suma, afirma que o desenvolvimento da interface do usuário foi consideravelmente mais rápido.

Embora o estudo esteja hospedado no wiki da empresa, posso garantir que ele é objective, genuíno e verdadeiro, embora eu 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 camada de apresentação e controlador (NO Spring Webflow, porque meus streams são baseados em ajax)

  • jQuery para todas as coisas do lado do cliente

  • Spring Security para o aspecto de segurança

  • Hibernate / JPA2

  • Molhe por causa de continuações (cometa)

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

Eu também gostaria de mencionar que eu estava a um passo de pular todas as coisas de Java e criar Scala / LIFT. Tanto quanto eu estou preocupado, tudo em Java que está relacionado com o desenvolvimento web de ponta (cometa, comunicação assíncrona, segurança (sim, mesmo com Spring Security!)) Ainda é um pouco hack (provove me errado por evidências, por favor !) Para mim, o Scala / LIFT parece ser uma solução mais pronta e multifuncional.

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

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

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

Felicidades Er

Eu também ouvi coisas boas sobre o Spring Framework. Em geral, no entanto, tenho ficado desapontado com a maioria dos frameworks web Java que eu já vi (esp Struts).

Para um aplicativo simples, eu definitivamente consideraria usar servlets e JSPs “brutos” e não me preocupar em adotar um framework. Se os servlets estiverem bem escritos, deve ser fácil, no futuro, portar para uma estrutura, se necessário, quando o aplicativo crescer em complexidade.

Minha escolha é Wicket !!

Todos eles – esse é o problema 😉

Eu acho que para os seus requisitos modestos, você só precisa codificar servlets ou páginas jsp simples que você pode servir do servidor Tomcat. Eu não acho que você precisa de qualquer tipo de framework web (como struts) para dados pessoais de sites

Dizer “use JSF” é um pouco simples. Quando você decide usar o JSF, você deve escolher uma biblioteca de componentes sobre ela. Você usará MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ )? Ou talvez o ICEfaces ( http://www.icefaces.org/ )? Ah, e se você usar o ICEfaces, você 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 eles não são grandes o suficiente para fazer as fases de avaliação de três meses. No entanto, você deve procurar alguns que tenham uma comunidade grande e ativa e que não tenham desaparecido em um ano. JSF está por aí há algum tempo, e desde que é empurrado pelo sol, ele estará por perto um pouco mais. Não posso dizer se é a melhor escolha, mas será boa.

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 Tapeçaria estão gerenciando o estado do cliente no servidor. Eu só usaria essas estruturas (o Wicket é o meu favorito) se o aplicativo fosse mais parecido com um aplicativo de desktop. Mas eu tentaria usar uma abordagem REST + AJAX mais escalável e simples.

O Spring MVC seria um candidato, mas desde o Spring MVC 3 tem um modelo de programação sobrecarregado de annotations estranhas que não usa os benefícios da tipagem estática. Há outras coisas feias, como parâmetros de saída em methods combinados com um retorno usual, portanto, há dois canais de saída de um método. O Spring MVC também tende a reinventar a roda e você terá mais para configurar em comparação com outras estruturas. Eu não posso realmente recomendar Spring MVC embora tenha algumas boas idéias.

O Grails é uma maneira conveniente de usar o Spring MVC e outras estruturas estabelecidas, como o Hibernate. A codificação é divertida e você verá rapidamente os resultados.

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

Eu avaliei bastante alguns frameworks e o 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 projetos grandes e uma base de usuários previsível), GWT (para grandes projetos que são principalmente públicos) 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 GUI rápida e sofisticada, você pode usar o JSF com a biblioteca Richfaces . Os componentes Richfaces UI são fáceis de usar e referências úteis estão disponíveis com demonstração de código no site demo. Provavelmente mais tarde, quando seu site tiver mais dados para manipular e muitas informações tiverem que ser transacionadas no database, você poderá conectar qualquer estrutura de access a database (ORM) a ele.

Não posso acreditar que ninguém mencionou o GWT

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

Para aplicativos mais complexos, o Spring MVC ou o Struts 2.

Tente o HybridJava – isso é muito mais simples do que qualquer outra coisa.

Eu diria vaadin ou wicket