asp.net mvc - ¿Cuáles son las principales desventajas de Java Server Faces 2.0?




asp.net-mvc jsf (9)

Ayer vi una presentación en Java Server Faces 2.0 que se veía realmente impresionante, aunque actualmente soy un feliz desarrollador de ASP.NET MVC / jQuery. Lo que más me gustó de JSF fue la enorme cantidad de componentes de interfaz de usuario habilitados para AJAX que parecen hacer que el desarrollo sea mucho más rápido que con ASP.NET MVC, especialmente en sitios pesados ​​de AJAX. Las pruebas de integración también se vieron muy bien.

Ya que la presentación solo enfatizó las ventajas de JSF, me gustaría escuchar acerca del otro lado también.

Así que mis preguntas son:

  • ¿Cuáles son las principales desventajas de Java Server Faces 2.0?
  • ¿Qué podría hacer que un desarrollador de JSF considere usar ASP.NET MVC en lugar de JSF?

  1. Los desarrolladores sin experiencia por lo general crearán aplicaciones que son extremadamente lentas y el código será realmente feo y difícil de mantener. Es engañosamente simple de comenzar, pero en realidad requiere una cierta inversión en aprendizaje si desea escribir buenos programas.
  2. Al menos al principio, a menudo se "atascará" en algún problema y pasará más tiempo leyendo publicaciones de balusc en Internet que trabajando realmente :) Después de un tiempo, cada vez será menos, pero aún así puede ser molesto.
  3. Aún más molesto cuando descubre que el problema no se debe a su falta de conocimiento / error, sino a un error. Mojarra estaba (¿está?) Bastante buggy, y otra capa de componentes agrega aún más problemas. Richfaces fue el software de basura más grande que se haya escrito :) No sé cómo está ahora en la versión 4. Tenemos Primefaces que es mejor, pero aún así se encontrará con errores o falta de características, especialmente con componentes más exóticos. Y ahora tendrá que pagar por las actualizaciones de Primefaces. Así que diría que tiene errores, pero está mejorando, especialmente después de la versión 2.2 que solucionó algunos problemas con las especificaciones. Marco cada vez más maduro pero aún lejos de ser perfecto (quizás myfaces mejor?).
  4. No lo encuentro especialmente flexible. A menudo, si necesita algo muy personalizado y no hay componentes que lo hagan, será un poco doloroso. Nuevamente, estoy hablando desde la perspectiva del desarrollador promedio: el que tiene fechas límite, tutoriales de lectura rápida y búsqueda de cuando se atasca porque no hay tiempo para aprender cómo funciona realmente :) A menudo, algunos componentes parecen tener "casi" lo que necesita, pero no exactamente y, a veces, puede pasar demasiado tiempo para hacer que haga lo que quiere :) Debe ser cuidadoso al evaluar si es mejor crear su propio componente o torturarlo. En realidad, si está creando algo realmente único, no recomendaría JSF.

Entonces, en resumen, mis inconvenientes serían: Complejidad, progreso de desarrollo no muy suave, buggy, inflexible.

Por supuesto, también hay ventajas, pero eso no es lo que pediste. De todos modos, esa es mi experiencia con el marco. Otros pueden tener diferentes opiniones, por lo que la mejor manera es probarlo por un tiempo para ver si es para ti (solo algo más complejo, no ejemplos ingenuos, JSF realmente brilla ahí). JSF es aplicaciones de negocios, como CRMs, etc ...


Algunos inconvenientes que vienen a la mente:

  1. JSF es un marco basado en componentes. Esto tiene restricciones inherentes que tienen que ver con obedecer el modelo de componente.
  2. AFAIK JSF solo admite POST, por lo que si desea obtener un GET en algún lugar, tiene que hacer un servlet simple / JSP.
  3. La mayoría de los componentes intentan proporcionar abstracciones sobre dominios como bases de datos relacionales y JavaScript de front-end, y muchas veces estas abstracciones son "fugaces" y son muy difíciles de depurar.
  4. Estas abstracciones pueden ser un buen punto de partida para un desarrollador junior o alguien que no se sienta cómodo con un dominio en particular (por ejemplo, JavaScript de front-end), pero son muy difíciles de optimizar para el rendimiento, ya que hay varias capas involucradas, y la mayoría de las personas las utilizan. Tengo poca comprensión de lo que está pasando bajo el capó.
  5. Los mecanismos de plantilla que normalmente se utilizan con JSF no tienen nada que ver con cómo funcionan los desigers web. Los editores WYSIWYG para JSF son primitivos y, en cualquier caso, su diseñador le dará HTML / CSS que tendrá que pasar las edades convirtiendo.
  6. Cosas como las expresiones EL no se verifican de forma estática y tanto el compilador como los IDE no están haciendo un buen trabajo para encontrar errores, por lo que terminará con errores que tendrá que detectar en tiempo de ejecución. Esto podría estar bien para un lenguaje de tipo dinámico como Ruby o PHP, pero si tengo que soportar la gran cantidad de ecosistemas de Java, exijo escribir para mis plantillas.

En resumen: el tiempo que ahorrará con JSF, evitando escribir el código de repetición de JSP / servlet / bean, lo gastará x10 para hacerlo escalar y hacer exactamente lo que quiere que haga.


Desarrollamos un proyecto de muestra con JSF (fue una investigación de tres semanas, ¡es posible que hayamos perdido algunas cosas!)

Intentamos usar core jsf, si se necesita un componente usamos PrimeFaces.

El proyecto fue un sitio web con navegación. Cada página debe cargarse a través de ajax cuando se hace clic en el menú.

El sitio tiene dos casos de uso:

  1. Una página con una cuadrícula. La cuadrícula se carga a través de ajax y debe admitir clasificación y paginación
  2. Una página de asistente de tres pasos. Cada página tiene la validación del lado del cliente (para validaciones simples) y la validación de la base ajax del lado del servidor (para validaciones complejas). Cualquier excepción del servidor (desde la capa de servicio) debe mostrarse en la misma página del asistente sin navegar a la página siguiente.

Encontramos eso:

  1. Necesita usar algunos hacks de omniFaces para hacer que el estado de la vista JSF sea fijo. El estado JSF se corromperá cuando incluyas páginas a través de ajax entre sí. Esto parece ser un error en JSF y puede solucionarse en las próximas versiones (no en 2.3).
  2. El flujo de JSF no funciona correctamente con ajax (¡o no podríamos hacerlo funcionar!) Intentamos utilizar el componente de asistente de interfaz principal en su lugar, pero la validación del cliente parece no ser compatible y significa que no fue un estándar de flujo JSF estándar.
  3. Cuando use algunos componentes de jQuery como jqGird, y necesita cargar los resultados de JSON, se le recomienda usar el servlet puro, el JSF no hará nada por usted. Por lo tanto, si utiliza este tipo de componentes, su diseño no se ajustará a JSF.
  4. Intentamos hacer algunos scripts de cliente cuando ajax complete con ajaxComplete y encontramos que el PF 4 ha implementado sus propios eventos ajax. Tuvimos algunos componentes de jQuery y necesitamos cambiar su código.

Si cambia la muestra anterior a un proyecto que no sea Ajax (o al menos menos un proyecto ajax) no enfrentará muchos de los problemas anteriores.

Resumimos nuestra investigación como:

JSF no está funcionando bien en un sitio web de base totalmente ajax.

Por supuesto, encontramos muchas características interesantes en JSF que pueden ser muy útiles en algunos proyectos, así que considere las necesidades de su proyecto.

Consulte los documentos técnicos de JSF para revisar las ventajas de JSF, y en mi opinión, la mayor ventaja de JSF es el soporte COMPLETO Y ENORME de @BalusC ;-)


Después de 5 años de trabajar con JSF, creo que puedo agregar mis 2 centavos.

Dos grandes inconvenientes JSF :

  1. Gran curva de aprendizaje. JSF es complejo, eso es cierto.
  2. Su naturaleza componente . El marco basado en componentes intenta ocultar la verdadera naturaleza de la Web, que conlleva una gran cantidad de complicaciones y desastres (como no admitir GET en JSF en casi 5 años).
    En mi humilde opinión, ocultar la solicitud / respuesta HTTP del desarrollador es un enorme error. Desde mi experiencia, cada marco basado en componentes agrega abstracción al desarrollo web, y esa abstracción resulta en una sobrecarga innecesaria y una mayor complejidad.

Y pequeños inconvenientes que me vienen a la mente:

  1. Por defecto, el ID del objeto se compone de los ID de sus padres, por ejemplo, form1: button1.
  2. No hay una manera fácil de comentar el fragmento de la página incorrecta. La etiqueta <ui:remove> necesita contenido sintácticamente correcto que se analiza de todos modos.
  3. Componentes de terceros de baja calidad que, por ejemplo, no comprueban isRendered() dentro del método processXxx() antes de continuar.
  4. Incorporar LESS y Sencha es difícil.
  5. No juega bien con REST.
  6. No es tan fácil para los diseñadores de UX, ya que los componentes listos para usar tienen sus propios estilos CSS, que deben ser sobrescritos.

No me malinterpretes Como un framework de componentes, JSF en la versión 2 es realmente bueno, pero aún está basado en componentes, y siempre será ...

Por favor, eche un vistazo a la baja popularidad de Tapestry, Wicket y el bajo entusiasmo de los experimentados desarrolladores de JSF (lo que es aún más significativo). Y para el contraste, eche un vistazo al éxito de Rails, Grails, Django, Play! Marco: todos están basados ​​en acciones y no intentan esconderse de la verdadera solicitud / respuesta del programador y la naturaleza sin estado de la web.

Para mí es la mayor desventaja de JSF. IMHO JSF puede adaptarse a algún tipo de aplicaciones (intranet, uso intensivo de formularios), pero para aplicaciones web de la vida real no es una buena manera de hacerlo.

Espero que ayude a alguien con sus elecciones en cuanto a front-end.


JSF solo tiene una desventaja: antes de iniciar el desarrollo "JSF", debe comprender claramente el desarrollo web, el núcleo java y la arquitectura de front-end.

En la actualidad, los "nuevos" marcos de JavaScript solo intentan copiar / pegar el modelo basado en componentes "JSF".


JSF tiene muchas ventajas, ya que las preguntas están en desventaja, permítanme agregar un par de puntos.

En un escenario práctico de implementación de un proyecto web con un marco de tiempo, debe estar atento a los siguientes factores.

  • ¿Tiene suficientes miembros senior en su equipo que puedan sugerir los mejores controles adecuados para cada escenario?
  • ¿Tiene el ancho de banda para adaptarse a la curva de aprendizaje inicial?

  • ¿Tiene suficiente experiencia en su equipo que puede revisar el JSF?
    ¿Qué cosas producen los desarrolladores?

Si su respuesta es 'No' para las preguntas, puede terminar en un código base no mantenible.


Para mí, el mayor defecto de JSF es la falta de soporte para las páginas generadas programáticamente (dinámicamente).
Si desea construir su página (crear un modelo de componente de página) dinámicamente a partir de código java. Por ejemplo, si está trabajando en el constructor de páginas web WYSIWYG. La documentación adecuada de este caso de uso no está disponible en general. Hay muchos puntos en los que hay que experimentar y el desarrollo es lento y lento. Muchas cosas simplemente no funcionan como esperarías. Pero en general es posible hackearlo de alguna manera.
Lo bueno es que no hay problema en la filosofía o arquitectura de JSF. Simplemente no está lo suficientemente elaborado (que yo sepa).

JSF 2 trajo componentes compuestos que deberían facilitar el desarrollo de componentes, pero su soporte para la construcción dinámica (programática) es muy deficiente. Si superas el proceso de construcción dinámica de componentes compuestos, complicado y casi no documentado, descubrirás que si anidas algunos componentes compuestos un poco más profundos, dejan de funcionar, lo que genera algunas excepciones.

Pero parece que la comunidad JSF es consciente de estas deficiencias. Están trabajando en esto como se puede ver en estos dos errores
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

La situación debería ser mejor con JSF 2.2 al menos si estamos hablando de especificaciones.


Para mí, la mayor desventaja de JSF 2.0 es la curva de aprendizaje no solo de JSF, sino también de las bibliotecas de componentes que tiene que usar para lograr que haga un trabajo útil. Considere la asombrosa cantidad de especificaciones y estándares con los que ha tratado para ser realmente competente:

  • HTML en las diversas encarnaciones. No finjas que no necesitas saberlo.
  • HTTP: cuando no puedes entender lo que está pasando, tienes que abrir Firebug y ver. Para eso necesitas saber esto.
  • CSS - Te guste o no. Realmente no es tan malo y al menos hay algunas herramientas bonitas por ahí.
  • XML: JSF será probablemente el primer lugar en el que uses espacios de nombres en este grado.
  • Especificación Servlet. Tarde o temprano entrará en los métodos de llamada de este paquete. Aparte de eso, tienes que saber cómo tus Facelets se convierten en XHTML o lo que sea.
  • JSP (principalmente para saber por qué no lo necesita en JSF)
  • JSTL (una vez más, principalmente para hacer frente a un marco heredado)
  • El lenguaje de expresión (EL) en sus diversas formas.
  • ECMAScript, JavaScript, o como quieras llamarlo.
  • JSON: deberías saber esto incluso si no lo usas.
  • AJAX. Yo diría que JSF 2.0 hace un buen trabajo ocultándote esto, pero aún necesitas saber qué está pasando.
  • El DOM. Y como un navegador lo usa. Ver ECMAScript.
  • Eventos DOM - un tema por sí mismo.
  • Java Persistence Architecture (JPA), es decir, si desea que su aplicación tenga una base de datos de back-end.
  • Java en sí.
  • JSEE mientras estás en ello.
  • La especificación de inyección de dependencia de contexto (CDI) y cómo se choca con y se utiliza con JSF 2.0
  • JQuery: me gustaría verte llevarte bien sin eso.

Ahora, una vez que haya terminado con eso, puede continuar con las especificaciones de propiedad, a saber, las bibliotecas de componentes y las bibliotecas de proveedores que recogerá en el camino:

  • PrimeFaces (mi biblioteca de componentes de elección)
  • RichFaces
  • MyFaces
  • ICEFaces
  • EclipseLink (mi proveedor JPA)
  • Hibernar
  • Soldar

¡Y no te olvides del contenedor! Y todos esos archivos de configuración:

  • GlassFish (2, 3, etc)
  • JBoss
  • Gato

Entonces, ¿ESTO LO HACE FÁCIL? Claro, JSF 2.0 es "fácil" siempre que lo único que quieras hacer sean las páginas web más básicas con las interacciones más simples.

En pocas palabras, JSF 2.0 es la mezcla más complicada y engorrosa de tecnologías encoladas como existe en el universo del software actual. Y no puedo pensar en nada de lo que preferiría usar.


Entre todos los marcos "principales" como Spring MVC, Wicket, Tapestry, etc., el JSF de Java EE con sus componentes compuestos es la capa de presentación más elaborada y la tecnología orientada a componentes. Es un poco engorroso e incompleto en comparación con las soluciones provistas por HybridJava.





jsf-2