Razones para NO usar JSF [cerrado]

64

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 empresarial se repensarán y volverán a implementar 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 combinación de pseudo-HTML / CSS / JS inválida más desordenada que he visto. Viola todas las reglas que aprendí en el desarrollo web. Además, reúne 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 ampliar esta salida cómodamente, ya sea peinando con CSS, agregando dulces 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 pobre abstracción de las tecnologías web básicas, paralizada e inútil al final. ¿Qué beneficios tengo? Ninguno, si lo piensas. Cientos de componentes? Veo diez mil fragmentos de HTML / CSS, diez miles de fragmentos de JavaScript y miles de complementos de jQuery además. Resuelve muchos problemas, no tendríamos si no usáramos JSF. O el patrón del controlador frontal en absoluto.

Y, por último, creo que tendremos que empezar de nuevo, digamos 2 años. No veo cómo puedo implementar toda nuestra primera maqueta de GUI (Además, no tenemos ningún experto JSF en nuestro equipo). Tal vez podríamos hackearlo de alguna manera. Y luego habrá más. Estoy seguro de que podríamos hackear nuestro hack. Pero en algún momento, estaremos atrapados. Debido a todo lo que está por encima del nivel de servicio, controla 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 MVC del lado del cliente. (o algún sabor de MVC ..) Por cierto; necesitaremos la API REST de todos modos, ya que también estamos desarrollando un front-end parcial de Android.

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

Ahora, ¿qué 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?

java javascript web-applications rest Bruno Schäpper
fuente
24
Esa es una pregunta bien escrita de un nuevo usuario. Considere dejar un comentario cuando haga downvoting.
ThiefMaster
2
Como está reescribiendo todo, no solo consideraría no usar JSF, sino considerar no usar Java en absoluto. Los lenguajes de script modernos (es decir, no PHP o Perl) son bastante agradables y amigables para los desarrolladores.
ThiefMaster
11
No voté en contra, pero esta no es una pregunta, es una queja. Vain ha tomado la decisión de que odia a JSF, ¿ahora pide más razones para no usarlo?
Michael Borgwardt
44
Java es la mejor opción si su aplicación va a ser grande (ya sea compleja y / o escalable) y / o distribuida, utilizando muchos servicios; Si su aplicación no encaja en esta categoría (no es tan compleja y no necesita ser escalable), Python (Django) o Ruby (Rails) serían mejores opciones. La complejidad de JSF tiene los beneficios del poder con el que viene; como alternativas, debería echar un vistazo a otros Web Frameworks como Spring MVC o Struts 2 si Java es obligatorio.
m3th0dman
14
Esta es una diatriba que busca respaldo, no una pregunta como tal.

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 funcionando en TODOS los contenedores de Java EE durante mucho, mucho tiempo. Y mantenido también, sin necesidad de hacerlo si se ha adherido estrictamente a la especificación Java EE.

Si esto le preocupa, entonces debe considerarlo. La mayoría del software vive más de lo que piensan sus diseñadores, especialmente si se toma en consideración al escribir.


fuente
44
No estoy seguro de eso. Para J2EE, las palabras 'estándar' y 'en funcionamiento' no están escritas en piedra, especialmente cuando hablamos de un sistema que será / debería ser compatible durante muchos años, incluidos los cambios en la versión de j2ee utilizada.
magallanes
77
En mi experiencia (limitada) con JSF, este argumento en realidad no es válido. He visto que las aplicaciones se estancan con una versión de JSF y no hay una ruta de migración sensata a una versión más nueva. Seguro que el servidor de la aplicación aún lo ejecutó, pero eso fue todo el soporte que obtendría si no tuviera grandes cantidades de dinero para gastar en contratos de soporte caros.
Jens Schauder
@JensSchauder mi experiencia es que puedes escribir aplicaciones portátiles, migrar y actualizar su versión de jsf. Esto implica conocer la especificación y codificarla, no su implementación. Funciona, como funciona la codificación para JPA en lugar de Hibernate. He estado haciendo eso por años.
ymajoros
14

Ahora, ¿qué 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 sobre los contras, y tengo que saludarme con algunos de ellos (no separa el diseño y la lógica lo suficiente, y el HTML resultante a menudo es atroz), pero no estás de acuerdo con los demás (si usas Facelets, que recomendaría mucho, entonces la salida definitivamente debería ser válida).

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ía usar JSF sobre algún otro marco con el que su equipo ya tenga experiencia.

Michael Borgwardt
fuente
1
No son las ID, son atributos no válidos. Como "rol" y "aria expandido" en la vista de pestaña. ¿Sabes cómo arreglar ésto?
Bruno Schäpper
1
@Vain: no, parece ser un problema diferente, quizás con un componente que no usé o que es nuevo. Es posible cambiar la salida HTML de los componentes JSF especificando un renderizador alternativo (que idealmente anula uno o dos métodos del renderizador predeterminado), pero, por supuesto, esto no es algo que deba hacer solo para obtener un marcado válido.
Michael Borgwardt
1
El atroz HTML se debe a la implementación utilizada. Tengo entendido que el modo de depuración de la implementación JSF de referencia es especialmente malo en esto. ¿Conocería mejores configuraciones para producir un mejor HTML?
1
@ Thorbjørn Ravn Andersen Sí, el problema con HTML no válido es en realidad un problema de PrimeFaces. Lo usamos porque está construido en jQuery-UI. Cual es tu consejo; ¿Debo usar otra biblioteca? Realmente me gusta el HTML válido. Para mí es simplemente una NECESIDAD.
Bruno Schäpper
1
Revisando mi primera pregunta aquí, me gustaría compartir algo de experiencia sobre sus profesionales: estamos trabajando con JSF, y con esa experiencia no la volveríamos a elegir. Casi nada funciona como se esperaba y fuera de la caja. Sí, hay bibliotecas poderosas. Pero terminamos haciendo todos nuestros componentes nosotros mismos, porque no funcionarían exactamente como lo necesitábamos. Es sorprendente lo rápido que tuvimos nuestra propia 'DataTable' con carga lenta mientras nos desplazábamos. Los componentes compuestos no funcionaron para nosotros, no puedo decir por qué, supongo que tienen errores. La representación de AJAX es realmente un dolor para el cliente JS.
Bruno Schäpper
9

JSF es un marco web con estado adecuado para Java que es un estándar, lo que significa que muchos proveedores importantes (incluidos los FOSS) lo admiten de inmediato. Tiene un fuerte soporte de biblioteca de terceros (PrimeFaces, IceFaces, etc.). Sin embargo, fundamentalmente 'rompe la red' debido a su naturaleza con estado (y muchas otras cosas). Vea la comparación de Matt Raible de los marcos web basados ​​en JVM , JSF generalmente se acerca al último.

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

Martijn Verburg
fuente
1
Es 'rompe la red', de hecho ... Y gracias por la comparación de Matt Raible, no lo sabía.
Bruno Schäpper
3
Tenga en cuenta que JSF no es necesariamente con estado. Estoy de acuerdo en que a menudo lo es, pero hay bastante buen soporte para solicitudes basadas en GET sin estado y si no usa un formulario, entonces no hay ningún estado.
Arjan Tijms
Punto justo Arjan, supongo que acabo de ver muchos usos con estado.
Martijn Verburg
Enlace a la presentación de Raible: slideshare.net/mraible/…
zaidaus
6

Teníamos 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. Tiene soporte (y una comunidad activa) para nuestra lista de deseos: Eclipse IDE, MVC y REST. Además, abandonamos nuestro Javascript / ajax de cosecha propia para jquery.

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

jqa
fuente