¿Cuáles son las principales desventajas de Java Server Faces 2.0?

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

Dos principales inconvenientes JSF :

1. Gran curva de aprendizaje. JSF es complejo, eso es verdad.
2. Su componente naturaleza. El framework basado en componentes intenta ocultar la verdadera naturaleza de la Web, que viene con una gran cantidad de complicaciones y desastres (como no apoyar GET en JSF dentro de casi 5 años).
   IMHO ocultar Solicitud/Respuesta HTTP del desarrollador es un un error enorme. 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 inconvenientes menores que vienen a mi mente:

1. Por defecto el ID del objeto está compuesto por los id de sus padres, por ejemplo form1:button1.
2. No es fácil comentar un fragmento de página incorrecto. Tag <ui:remove> necesita contenido sintácticamente correcto que se analiza Por cierto.
3. Componentes de tercera parte de baja calidad que, por ejemplo, no comprueban isRendered() dentro del método processXxx() antes de continuar.
4. Incorporar LESS & Sencha es difícil.
5. No juega bien con el DESCANSO.
6. No es tan fácil para los diseñadores de UX, porque los componentes listos para usar tienen sus propios estilos CSS, que deben sobrescribirse.

No me malinterpretes. Como marco de componentes JSF en la versión 2 es realmente bueno, pero sigue siendo basado en componentes, y siempre lo será...

Por favor, eche un vistazo a la baja popularidad de Tapestry, Wicket y el bajo entusiasmo de los desarrolladores experimentados de JSF (lo que es aún más significativo). Y para contrastar, echa un vistazo al éxito de Rails, Grails, Django, Play! Framework-todos están basados en acciones y no tratan de ocultarse del programador true request/response y stateless nature de la web.

Para mí es una gran desventaja de JSF. IMHO JSF puede adaptarse a algún tipo de aplicaciones (intranet, formularios intensivos), pero para la vida real web aplicación no es un buen camino a seguir.

Espero que ayude a alguien con sus opciones que se refiere a front-end.

Algunos inconvenientes que me vienen a la mente:

1. JSF es un framework basado en componentes. Esto tiene restricciones inherentes que tienen que ver con obedecer la componente-modelo.
2. AFAIK JSF solo soporta POST, así que si quieres un GET somewhere tienes para hacer un servlet/JSP simple.
3. La mayoría de los componentes intentan proporcionar abstracciones sobre dominios como bases de datos relacionales y front-end JavaScript, y muchas veces estos las abstracciones son "filtrantes" y muy difíciles de depurar.
4. Estas abstracciones podría ser un buen punto de partida para un desarrollador junior o alguien que no se siente cómodo con un dominio en particular (por ejemplo, JavaScript 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 que las usan tienen poca comprensión de lo que está pasando bajo el capó.
5. Los mecanismos de plantillas que normalmente se usan 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 designer te dará HTML / CSS que tendrás que pasar años convirtiendo.
6. Cosas como las expresiones EL no se comprueban estáticamente y tanto el compilador como los IDE no están haciendo un buen trabajo para encontrar errores, por lo que terminarás con errores que tendrás que detectar en tiempo de ejecución. Esto podría estar bien para lenguajes dinámicamente tipeados como Ruby o PHP, pero si tengo que soportar la gran hinchazón del ecosistema Java, exijo escribir para mis plantillas.

Para resumir: El tiempo guardará con JSF, de evitar escribir el código JSP/servlet / bean boilerplate, lo gastará x10 para hacerlo escalar y hacer exactamente lo que quiera que haga.

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

• HTML en las diversas encarnaciones. No finjas que no necesitas saberlo.
• HTTP when cuando no puedes averiguar lo que está pasando tienes que abrir Firebug y ver. Para eso necesitas saber este.
• CSS Like Nos guste o no. No es tan malo realmente y hay algunas herramientas agradables por ahí al menos.
• XML probably JSF probablemente será el primer lugar en el que utilice espacios de nombres en este grado.
• Especificación de Servlet. Tarde o temprano entrarás en métodos de llamada en este paquete. Aparte de eso, usted tiene que saber cómo sus Facelets se convierte en XHTML o lo que sea.
• JSP (sobre todo para que sepas por qué no lo necesitas en JSF)
• JSTL (de nuevo, principalmente para hacer frente a marco heredado)
• Lenguaje de expresión (EL) en sus diversas formas.
• ECMAScript, JavaScript, o como quieras llamarlo.
• JSON should deberías saber esto incluso si no lo usas.
• AJAX. Yo diría que JSF 2.0 hace un trabajo decente de ocultar esto de usted, pero todavía necesita saber lo que está pasando.
• El DOM. Y cómo lo usa un navegador. Consulte ECMAScript.
• Eventos DOM a un tema por sí mismo.
• Arquitectura de persistencia de Java (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 Dependencias de Contexto (CDI) y cómo choca y se usa con JSF 2.0
• jQuery I Me gustaría ver que te llevas bien sin ella.

Ahora, una vez que haya terminado con eso, puede continuar con las especificaciones propietarias, es decir, las bibliotecas de componentes y las bibliotecas de proveedores que recogerá a lo largo del camino:

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

Y no olvides el contenedor! Y todos esos archivos de configuración:

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

Entonces THIS ¿ESTO LO HACE FÁCIL? Claro, JSF 2.0 es "fácil" siempre y cuando todo lo que quieres hacer es las páginas web más básicas con el interacciones más simples.

En pocas palabras, JSF 2.0 es la mezcla más complicada y engorrosa de tecnologías pegadas entre sí como existe en el universo del software hoy en día. Y no se me ocurre nada que preferiría usar.

1. Los desarrolladores inexpertos generalmente crearán aplicaciones que son dolorosamente lentas y el código será realmente feo y difícil de mantener. Es engañosamente fácil de comenzar, pero en realidad requiere algo de inversión en el 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 será cada vez menos de eso, pero todavía 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 era(es?) bastante buggy, y otra capa de componentes añade aún más problemas. Richfaces fue la pieza más grande de software de mierda jamás escrito:) No sé cómo es 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 Primefaces actualizar. Así que diría que es buggy, pero está mejorando, especialmente después de la versión 2.2 se corrigieron algunos problemas con las especificaciones. Marco de trabajo cada vez más maduro, pero todavía lejos de ser perfecto (tal vez myfaces mejor?).
4. No lo encuentro especialmente flexible. A menudo, si necesita algo muy, muy personalizado y no hay componentes que lo haga, será un poco doloroso. Una vez más, estoy hablando desde la perspectiva del desarrollador promedio: el que tiene plazos, tutoriales de lectura rápida y busca stackoverflow al quedarse atascado porque no hay tiempo para aprender cómo funciona realmente:) A menudo algunos componentes parece tener "casi" lo que necesita, pero no exactamente y a veces puede pasar demasiado tiempo para hacer que haga algo que desea :) Necesidad de tener cuidado en la evaluación si es mejor crear su propio componente existente o tortura. En realidad, si está creando algo realmente único, no recomendaría JSF.

Así que, en resumen, mis inconvenientes serían: Complejidad, Desarrollo no muy suave progreso, buggy, inflexible.

Por supuesto que también hay ventajas, pero eso no es lo que preguntaste. De todos modos esa es mi experiencia con el marco de otros podrían tener opiniones diferentes, así que la mejor manera es simplemente probarlo por un tiempo para ver si es para usted (solo algo más complejo - no ejemplos ingenuos - JSF realmente brilla allí:) IMHO mejor caso de uso para JSF es aplicaciones de negocios, como CRMs, etc...

"JSF generará HTML y JavaScript de la capa de vista que no puede controlar o cambiar sin entrar en el código del controlador."

En realidad, JSF le da la flexibilidad, puede usar componentes estándar/de terceros o crear los suyos propios, que tiene control total sobre lo que se renderiza. Es solo un xhtml que necesita para crear sus componentes personalizados con JSF 2.0.

Desarrollamos un proyecto de muestra con JSF (Fue una investigación de tres semanas, así que puede que hayamos perdido algunas cosas!)

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

El proyecto era 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 debería admitir la clasificación y paginación
2. Una página de asistente de tres pasos. Cada página tiene validación del lado del cliente (para validaciones simples) y validación base ajax del lado del servidor (para validaciones complejas). Cualquier excepción de servidor ( de la capa de servicio) debe mostrarse en la misma página del asistente sin navegar a la página siguiente.

Encontramos que:

1. Necesita usar algunos hacks de OmniFaces para arreglar el estado de la vista JSF. El estado JSF se dañará cuando incluya páginas a través de ajax entre sí. Esto parece un error en JSF y puede ser corregido en el siguiente versiones (no en 2.3).
2. El flujo de JSF no funciona correctamente con ajax (o no podríamos hacerlo funcionar!) Intentamos usar el componente primeface wizard en su lugar, pero la validación del cliente parece no ser compatible y significa que no era estándar JSF flow standard.
3. Cuando se utilizan algunos componentes de jQuery como jqGird, y necesita cargar los resultados JSON, entonces se le aconseja utilizar servlet puro, El JSF no hará nada por usted. Así que si usted utiliza este tipo de componentes, su diseño no encaja en JSF.
4. Tratamos de hacer algunos scripts de cliente cuando ajax completa por ajaxComplete y encontramos que el PF 4 ha implementado sus propios eventos ajax. Teníamos algunos componentes de jQuery y necesitamos cambiar su código.

Si cambia el ejemplo anterior a un proyecto no Ajax (o al menos un proyecto menos ajax) no se enfrentará a muchos de los problemas anteriores.

Resumimos nuestra investigación como:

JSF no está funcionando bien en una base totalmente ajax sitio.

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

Por favor, 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 apoyo COMPLETO Y ENORME de @BalusC; -)

No soy un experto en Caras de Servidor Java en absoluto. Pero en mi humilde opinión la principal desventaja es que es del lado del servidor. Estoy cansado de aprender y usar marcos de capa de presentación web del lado del servidor como ASP.NET Formularios Web, ASP.NET MVC, Java Server Faces, Struts, frameworks php y frameworks ruby on rails. Me despedí de todos ellos, y saludé a Angularjs y TypeScript. Mi capa de presentación se ejecuta en el navegador. No importa si es servido por Windows IIS ejecutando php o ASP.NET, o si lo es servido por un servidor web Apache que se ejecuta en Linux. Solo necesito aprender un marco que funcione en todas partes.

Para mí, el mayor defecto de JSF es el pobre soporte para páginas generadas mediante programación (dinámicamente).
Si desea construir su página (crear modelo de componente de página) dinámicamente a partir de código java. Por ejemplo, si está trabajando en WYSIWYG web page constructor. La documentación adecuada de este caso de uso no está generalmente disponible. Hay muchos puntos en los que tienes que experimentar y el desarrollo es tranquilo y lento. Muchas cosas simplemente no funcionan como esperarías. Pero en general su posible hackearlo de alguna manera.
Lo bueno es que no es problema en 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 pobre. Si supera un proceso tranquilo, complicado y casi indocumentado de construcción de componentes Compuestos dinámicos, descubrirá que Si anida pocos componentes compuestos un poco más profundo, dejan de funcionar, lanzando algunas excepciones.

Pero parece que la comunidad JSF es consciente de estas deficiencias. Ellos están trabajando en esto, como se puede ver en estas dos bugs
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 especificación.

Comentando mis últimos meses de experiencia en Primefaces / JSF:

• Si puedes usar componentes "listos para usar", supongo que no es terrible.
• Sin embargo, no funciona bien tan pronto como sales y necesitas UIs personalizadas. - Por ejemplo, necesitábamos usar bootstrap de Twitter para nuestro proyecto. (No primefaces bootstrap).
  • Ahora nuestras páginas funcionan de la siguiente manera:
    • Carga la página.
    • El usuario interactúa con un Primefaces que tiene funcionalidad ajax
    • Los enlaces javascript de Bootstrap se rompen
    • Ejecutamos javascript adicional para volver a enlazar todo

La promesa de JSF de evitar escribir javascript se convirtió en escribir más javascript de lo que tendríamos si no usáramos Primefaces to y ese javascript es arreglar lo que Primefaces rompe.

Es un sumidero de tiempo unless a menos que vuelvas a usar cosas "fuera del estante". También muy feo (Primefaces) cuando se tiene que trabajar con Selenio. Todo se puede hacer ... pero de nuevo's no hay mucho tiempo.

Definitivamente evite esto si está trabajando con un equipo de UX/diseño y necesita iterar rápidamente en la interfaz de usuario can puede ahorrar tiempo aprendiendo jquery/escribiendo HTML directo.o mirando react/angular.

JSF tiene muchas ventajas, siendo la pregunta en desventaja permítanme añadir un par de puntos sobre ella.

En un escenario práctico de implementación de un proyecto web con un marco de tiempo que necesita para mantener un ojo en los siguientes factores.

• ¿Tiene suficientes miembros senior en su equipo que puedan sugerir lo mejor controles adecuados para cada escenario?

• ¿Tiene el ancho de banda para acomodar la curva de aprendizaje inicial?

• ¿tiene suficiente experiencia en su equipo que puede revisar el JSF
  cosas producidas por los desarrolladores?

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

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

Hoy en día, los "nuevos" marcos de JavaScript solo intentan copiar/pegar el modelo basado en componentes "JSF".

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