Prós e contras de várias tecnologias de camada de apresentação da Web Java

Question

Atualmente, estou trabalhando em um aplicativo da Web que faz uso pesado de JSF e Icefaces. Tivemos algumas discussões sobre como mudar para outra camada de apresentação, e pensei em levar a discussão e ver o que os especialistas pensam.

Estou curioso para saber se alguém puder avaliar os prós e contras das várias tecnologias de camada de apresentação Java. Se você só trabalhou com um, diga por que você o ama ou odeia. Se você trabalhou com vários, dê suas impressões de como elas se comparam.

Nossas tecnologias em consideração são:

• Faces de gelo
• JSF (sem faces de gelo)
• GWT (Google Web Toolkit)
• Postigo
• Tapeçaria

E se estou perdendo alguma coisa da minha lista, me avise.

Obrigado!

Answer 1

Minhas opiniões são bastante tendenciosas para o wicket, porque eu a uso há um tempo depois de tropeçar nas minas JSP muitas vezes.

PROS PROSSTRADOS:

• Verdadeira separação de layout e código.
• Baseado em componentes, o que significa alta reutilização dos elementos do local; Por exemplo, você pode criar um formulário bonito com estilos automáticos de rotulagem e CSS e tudo mais, e apenas alterando seu objeto DAO no construtor do componente, é completamente reutilizável em outro projeto.
• Excelente suporte para coisas como Ajax, portlets e várias estruturas em geral diretamente para a caixa e, mais importante, não depende de nada além do SLF4J/LOG4J para funcionar, tudo é opcional!

Contras de wicket:

• O desenvolvimento tem alguma confusão sobre as coisas em geral e os genéricos do wicket estão uma bagunça agora, embora tenham sido muito limpos em 1.4
• Alguns componentes (como Form.onSubmit()) requerem subclasse extensa ou método anônimo, substituindo facilmente o comportamento de injeção. Isso se deve em parte ao poderoso design baseado em eventos do Wicket, mas infelizmente também significa que é fácil fazer uma bagunça de código com Wicket.

Contras aleatórios: (isto é, eu não usei, mas essas são minhas opionões e/ou coisas que ouvi)

• O GWT é baseado em JavaScript, que me parece estúpido. A questão principal é que ela me lembra muito do JSP: se suas classes autogeneradas que são horríveis.
• A tapeçaria não separa a marcação e o código corretamente de maneira que possa ser facilmente validada entre os dois, o que causará problemas no futuro.

Answer 2

Eu usei o GWT para alguns pequenos projetos. Aqui estão algumas coisas que eu gosto nisso:

1. É Ajax por padrão, então eu não precisava faço Ele faz Ajax, apenas veio com o uso do GWT.
2. Tem uma boa separação do código do cliente versus o código do servidor.
3. Eu posso testar unidade meu código de cliente usando Junit
4. Ele permite que você construiu aplicativos nítidos e rápidos, principalmente porque é Ajax.

Coisas que eu não gosto:

1. Algumas coisas não funcionam como esperado. Por exemplo, vi casos em que os eventos de cliques não dispararam como esperado, então tive que fazer uma solução alternativa.
2. O implantação automática do Tomcat em Eclipse às vezes apenas para de funcionar, e eu nunca conseguia descobrir o porquê.

Answer 3

The biggest question I'd ask is why are you changing presentation layer? That's a very expensive cost and I can see the benefits of one technology outweighing the others by as much as the cost to change...

Answer 4

In short:

= JSF =

PROS:

• component architecture;
• many libraries & tools;
• somewhat good IDE support

CONS:

• heavy weight, both in CPU/memory and learning curve;
• when something doesn't work as expected, it's difficult to debug

= WICKET =

PROS:

• lightweight;
• sensible templating system;
• good tutorials;

CONS:

• reference documentation is not so well organized and deep as are the tutorials;
• development team had some serious difficulties, especially when becoming and incubated project. This lead to confusion on important aspects of the framework, at that time I had to switch to another framework because of this...

Answer 5

What about Stripes?

Answer 6

My pick would be Wicket. Have used it and is gives excellent re-usability. It has one of the most vibrant forum/mailing list. As a question and its gonna be answered in minutes. It has excellent support for AJAX. One of the usual cons attributed to Wicket is the steep learning curve. Well those were one of the old age cons which hold no value anymore now.

JSF: Better stay away from it. Another team which developed a project on JSF is now thinking to shift to Wicket after our success with it.

@Megadix: Like you said the documentation was poor in the beginning, but not any more. There is an excellent book called Wicket in Action written by the developers of Wicket. The sample code provided on the site is also a good place to start and learn

Answer 7

I'd wonder if you a have a service layer that's distinct from the web client, something that the web controllers simply invoke to get their work done.

If you do, the choice of web UI technology can be decoupled from the back end. If it's exposed as a contract first web service, you can have different apps share it. As long as your clients can send and receive XML they can interact with your services. Want to switch to Flex? No worries - point it at the service and render the XML response.

Answer 8

See my comparison of Wicket and Tapestry 5: Difference between Apache Tapestry and Apache Wicket.