Razones para NO usar JSF [cerrado]

Navega tus respuestas
63

Soy nuevo en StackExchange, pero pensé que podrías ayudarme.

Estamos creando una nueva aplicación Java Enterprise, reemplazando una solución JSP heredada. Debido a muchos cambios, la interfaz de usuario y partes de la lógica de negocios se replantearán y reimplementarán por completo.

Nuestro primer pensamiento fue JSF, ya que es el estándar en Java EE. Al principio tuve una buena impresión. Pero ahora estoy tratando de implementar un prototipo funcional y tengo algunas preocupaciones realmente serias sobre su uso.

En primer lugar, crea la peor mezcla pseudo-HTML / CSS / JS inválida y más abarrotada que he visto. Viola todas las reglas que aprendí en el desarrollo web. Además, se junta, lo que nunca debería estar tan estrechamente acoplado: diseño, diseño, lógica y comunicación con el servidor. No veo cómo podría extender esta salida cómodamente, ya sea peinar con CSS, agregar caramelos de UI (como teclas de acceso rápido configurables, widgets de arrastrar y soltar) o lo que sea.

En segundo lugar, es demasiado complicado. Su complejidad es sobresaliente. Si me preguntas, es una mala abstracción de las tecnologías web básicas, paralizadas e inútiles al final. ¿Qué beneficios tengo? Ninguna, si lo piensas. Cientos de componentes? Veo diez mil de fragmentos de HTML / CSS, diez mil de fragmentos de JavaScript y miles de complementos de jQuery además. Resuelve muchos problemas, no tendríamos si no usaríamos JSF. O el patrón del controlador frontal en absoluto.

Y por último, creo que tendremos que empezar de nuevo en, digamos 2 años. No veo cómo puedo implementar toda nuestra primera maqueta de GUI (además, no tenemos un experto en JSF en nuestro equipo). Tal vez podríamos hackearlo juntos de alguna manera. Y luego habrá más. Estoy seguro de que podríamos hackear nuestro hack. Pero en algún momento, estaremos estancados. Debido a que todo lo que está por encima del nivel de servicio está en control de JSF. Y tendremos que empezar de nuevo.

Mi sugerencia sería implementar una API REST, utilizando JAX-RS. Luego cree un cliente HTML5 / Javascript con el lado del cliente MVC. (o algún sabor de MVC ..) Por cierto; De todos modos, necesitaremos la API REST, ya que también estamos desarrollando un front-end parcial de Android.

Dudo que JSF sea la mejor solución en la actualidad. A medida que Internet está evolucionando, realmente no veo por qué deberíamos usar este 'rake'.

Ahora, ¿cuáles son los pros / contras? ¿Cómo puedo enfatizar mi punto de no usar JSF? ¿Cuáles son los puntos fuertes para usar JSF sobre mi sugerencia?

    
pregunta Bruno Schäpper 24.07.2012 - 15:17

4 respuestas

26

Hay al menos una muy buena razón para considerar JSF.

Es una parte estándar de la pila de Java EE, y por lo tanto estará disponible, y trabajando , en TODOS los contenedores de Java EE por un tiempo muy, muy largo. Y mantenido también, sin que tenga que hacerlo si se ha adherido estrictamente a la especificación Java EE.

Si esta es una preocupación para usted, entonces debería considerarla. La mayoría del software vive más tiempo de lo que piensan sus diseñadores, especialmente si se toma en consideración cuando se escribe.

    
respondido por el user1249 25.07.2012 - 14:48
14
  

Ahora, ¿cuáles son los pros / contras? ¿Cómo puedo enfatizar mi punto de no usar JSF? ¿Cuáles son los puntos fuertes para usar JSF sobre mi sugerencia?

Parece que ya has tomado una decisión con respecto a los contras, y estoy de acuerdo con algunos de ellos (no separa el diseño y la lógica lo suficiente, y el HTML resultante es a menudo atroz), pero no estoy de acuerdo con otros ( Si usa Facelets, que recomendaría mucho, entonces la salida definitivamente debería ser válida).

Así que aquí hay algunos pros:

  • Hay algunas bibliotecas de componentes muy potentes como PrimceFaces o RichFaces que ofrecen una gran cantidad de funciones listas para usar. Estos pueden ahorrarle mucho trabajo si cubren sus requisitos (no tanto si tiene requisitos no negociables que no están cubiertos por ellos).
  • Los componentes compuestos ofrecen una forma muy limpia de modularizar sus páginas
  • JSF se integra muy bien con el resto de Java EE
  • AJAX a través de la representación de componentes es realmente fácil y conveniente

Pero ciertamente ninguna de estas ventajas es tan grande que deberías usar JSF sobre algún otro marco en el que tu equipo ya tenga experiencia.

    
respondido por el Michael Borgwardt 24.07.2012 - 16:17
9

JSF es un marco web con estado y adecuado para Java, que es un estándar, lo que significa que está respaldado de forma inmediata por muchos de los principales proveedores (incluidos los de software libre). Tiene un sólido soporte de biblioteca de terceros (PrimeFaces, IceFaces, etc.). Sin embargo, fundamentalmente "rompe la web" debido a su naturaleza de estado (y un montón de otras cosas). Consulte comparación de Matt Raible de marcos web basados en JVM , el JSF por lo general es casi el último.

Editar - con JSF 2.2 - puedes comenzar a argumentar que no rompe la web tanto como antes. De hecho, la integración de HTML5 no es del todo terrible :-).

    
respondido por el Martijn Verburg 24.07.2012 - 16:12
6

Tuvimos una aplicación JSP / Struts 1.0 heredada. Nos saltamos Struts 2, JSF y todo lo demás que ha sucedido desde Struts 1 y saltamos a Spring 3.0. Cuenta con soporte (y una comunidad activa) para nuestra lista de deseos: Eclipse IDE, MVC y REST. Además, abandonamos nuestro Javascript / ajax de cosecha propia de cosecha para jQuery.

YMMV, pero Spring ha sido una migración sin problemas para nosotros.

    
respondido por el jqa 24.07.2012 - 16:10

Lea otras preguntas en las etiquetas

¿Es la agrupación de objetos una técnica en desuso? ¿La notación musical es Turing-Complete?