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

JSF 2.0 desventajas? Honestamente, aparte de la curva de aprendizaje relativa empinada cuando no tienes un sólido conocimiento básico sobre desarrollo web básico (HTML / CSS / JS, lado del servidor frente al cliente, etc.) y la API Java Servlet básica (solicitud / respuesta / sesión , reenvío / redireccionamiento, etc.), no vienen a la mente inconvenientes serios. JSF en su versión actual todavía necesita deshacerse de la imagen negativa que obtuvo durante las edades tempranas, durante la cual hubo varias desventajas serias.

JSF 1.0 (marzo de 2004)

Esta fue la versión inicial. Estaba lleno de errores tanto en el núcleo como en las áreas de rendimiento que no querías saber. Su aplicación web no siempre funcionó como lo esperaría intuitivamente. Usted como desarrollador correría lejos llorando.

JSF 1.1 (mayo de 2004)

Esta fue la versión de corrección de errores. El rendimiento aún no mejoró mucho. También hubo una gran desventaja: no se puede en línea HTML en la página JSF sin problemas. Todo el HTML sencillo y plano se procesa antes del árbol de componentes JSF. Debe envolver todos los vainilla simple en tags para que se incluyan en el árbol de componentes JSF. Aunque esto fue según la especificación, esto ha recibido muchas críticas. Ver también ao JSF / Facelets: ¿por qué no es una buena idea mezclar JSF / Facelets con tags HTML?

JSF 1.2 (mayo de 2006)

Este fue el primer lanzamiento del nuevo equipo de desarrollo JSF liderado por Ryan Lubke. El nuevo equipo hizo un gran trabajo. También hubo cambios en la especificación. El cambio principal fue la mejora del manejo de vistas. Esto no solo desconectó por completo JSF de JSP, por lo que se podría utilizar una tecnología de visualización diferente a JSP, sino que también permitió a los desarrolladores alinear HTML sin formato en la página JSF sin molestar con tags . Otro enfoque importante del nuevo equipo fue mejorar el rendimiento. Durante la vida de Sun JSF Reference Implementation 1.2 (cuyo nombre en clave fue Mojarra desde la versión 1.2_08, alrededor de 2008), prácticamente todas las construcciones se enviaron con mejoras de rendimiento (mayores) junto a las correcciones de errores habituales (menores).

La única desventaja seria de JSF 1.x (incluido 1.2) es la falta de un scope entre la solicitud y el scope de la sesión , el llamado ámbito de conversación . Esto obligó a los desarrolladores a molestar con elementos de entrada ocultos, consultas DB innecesarias y / o abusando del scope de la sesión cuando uno desea retener los datos del modelo inicial en la solicitud posterior para procesar con éxito validaciones, conversiones, cambios de modelo e invocaciones de acción en el aplicaciones complejas. El dolor podría atenuarse adoptando una biblioteca de terceros que conserve los datos necesarios en la solicitud posterior, como el componente MyFaces Tomahawk , el ámbito de conversación de JBoss Seam y el marco de conversación de MyFaces Orchestra .

Otra desventaja para los puristas HTML / CSS es que JSF usa los dos puntos : como carácter separador de ID para garantizar la singularidad del id elemento HTML en la salida HTML generada, especialmente cuando un componente se reutiliza más de una vez en la vista (creación de plantillas, iteración de componentes, etc.) Debido a que este es un carácter ilegal en los identificadores de CSS, necesitarás usar \ para escapar de los dos puntos en los selectores de CSS, lo que da como resultado selectores feos y de aspecto extraño como #formId\:fieldId {} o incluso #formId\3A fieldId {} . Consulte también Cómo usar la ID del elemento HTML generado por JSF con dos puntos “:” en los selectores de CSS. Sin embargo, si no eres un purista, lee también. De forma predeterminada, JSF genera identificadores inutilizables, que son incompatibles con css parte de los estándares web .

Además, JSF 1.x no se envió con las instalaciones de Ajax fuera de la caja. No es realmente una desventaja técnica, pero debido a la exageración de la Web 2.0 durante ese período, se convirtió en una desventaja funcional. Exadel fue pronto para presentar Ajax4jsf, que se desarrolló a fondo durante los años y se convirtió en la parte central de la biblioteca de componentes de JBoss RichFaces . También se enviaron otras bibliotecas componentes con poderes Ajax incorporados, siendo el conocido ICEfaces .

Aproximadamente a la mitad de la vida útil de JSF 1.2, se introdujo una nueva tecnología de visualización basada en XML: Facelets . Esto ofreció enormes ventajas sobre JSP, especialmente en el área de plantillas.

JSF 2.0 (junio de 2009)

Este fue el segundo lanzamiento importante, con Ajax como palabra de moda. Hubo muchos cambios técnicos y funcionales. JSP es reemplazado por Facelets como la tecnología de vista predeterminada y Facelets se expandió con capacidades para crear componentes personalizados usando XML puro (los denominados componentes compuestos ). Consulte también ¿Por qué se prefiere Facelets sobre JSP como el lenguaje de definición de vista desde JSF2.0 en adelante?

Los poderes de Ajax se introdujeron en el sabor del componente que tiene muchas similitudes con Ajax4jsf. Las anotaciones y las mejoras de la convención sobre la configuración se introdujeron para matar el archivo de faces-config.xml lo más posible. Además, el carácter predeterminado separador ID identificador de contenedor : volvió configurable, por lo que los puristas de HTML / CSS podían respirar aliviados. Todo lo que necesita hacer es definirlo como init-param en web.xml con el nombre javax.faces.SEPARATOR_CHAR y asegurarse de que no está utilizando el caracter usted mismo en ninguna parte de los ID del cliente, como - .

Por último, pero no menos importante, se introdujo un nuevo scope, el scope de la vista . Eliminó otra desventaja importante de JSF 1.x como se describió anteriormente. Simplemente declara el bean @ViewScoped para habilitar el scope de la conversación sin molestar todas las formas de retener los datos en las solicitudes posteriores (conversacionales). Un bean @ViewScoped vivirá siempre y cuando posteriormente envíe y navegue a la misma vista (¡independientemente de la pestaña / pestaña del navegador abierta!), De forma síncrona o asíncrona (Ajax). Consulte también Diferencia entre la vista y el scope de la solicitud en beans gestionados y ¿Cómo elegir el ámbito de beans correcto?

Aunque prácticamente todas las desventajas de JSF 1.x se eliminaron, existen errores específicos de JSF 2.0 que podrían convertirse en un inconveniente. El @ViewScoped falla en los controladores de tags debido a un problema de huevo de gallina en el ahorro de estado parcial. Esto se soluciona en JSF 2.2 y se transfiere a Mojarra 2.1.18. Además, no se admiten los atributos personalizados, como HTML5 data-xxx . Esto se soluciona en JSF 2.2 mediante una nueva característica de elementos / atributos de paso a través. Además, la implementación JSF Mojarra tiene su propio conjunto de problemas . Relativamente, muchos de ellos están relacionados con el comportamiento a veces poco intuitivo de , la nueva implementación de ahorro de estado parcial y el scope del flash mal implementado . La mayoría de ellos se arreglan en una versión de Mojarra 2.2.x.

Alrededor del tiempo JSF 2.0, se introdujo PrimeFaces , basado en jQuery y jQuery UI. Se convirtió en la biblioteca de componentes JSF más popular.

JSF 2.2 (mayo de 2013)

Con la introducción de JSF 2.2, HTML5 se usó como palabra de moda aunque técnicamente solo era compatible con todas las versiones anteriores de JSF. Consulte también el soporte de JavaServer Faces 2.2 y HTML5, por qué XHTML todavía se está utilizando . La característica más importante de JSF 2.2 es la compatibilidad con atributos de componentes personalizados, por lo que se abre un mundo de posibilidades, como grupos de botones de opción sin botones personalizados .

Además de errores específicos de implementación y algunas “pequeñas cosas molestas”, como la imposibilidad de inyectar un EJB en un validador / convertidor (ya corregido en JSF 2.3), no existen desventajas importantes en la especificación JSF 2.2.

MVC basado en componentes vs MVC basado en solicitudes

Algunos pueden optar por que la principal desventaja de JSF es que permite muy poco control fino sobre el HTML / CSS / JS generado. Eso no es propio de JSF, es solo porque es un marco MVC basado en componentes , no un marco MVC basado en solicitud (acción) . Si un alto grado de control de HTML / CSS / JS es su requisito principal al considerar un marco MVC, entonces ya no debería estar mirando un marco MVC basado en componentes, sino en un marco MVC basado en solicitudes como Spring MVC . Solo debe tener en cuenta que tendrá que escribir todo el texto de HTML / CSS / JS. Ver también Diferencia entre Request MVC y Component MVC .

Ver también:

• ¿Cuál es la diferencia entre JSF, Servlet y JSP? (solo para entender lo básico)
• Usando JSF para desarrollar diseños CSS sin tablas (otro mito sobre JSF)
• JSF vs HTML / CSS / JS / jQuery (cuando JSF es la opción incorrecta)
• Patrones de diseño en aplicaciones web (ilustra la ideología detrás de MVC)

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

Dos inconvenientes principales de JSF :

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

Y pequeños inconvenientes que vienen a mi mente:

1. Por defecto, el ID del objeto está compuesto por los identificadores de sus padres, por ejemplo form1: button1.
2. No es una forma fácil de comentar el fragmento de la página incorrecta. Tag necesita contenido sintácticamente correcto que se analiza de todos modos.
3. Componentes de terceros de baja calidad que, por ejemplo, no comprueban, están isRendered() dentro del método processXxx() antes de continuar.
4. Incorporar LESS y Sencha es difícil.
5. No funciona bien con REST.
6. No es tan fácil para los diseñadores de UX, porque los componentes listos para usar tienen sus propios estilos de CSS, que deben sobrescribirse.

No me malinterpretes Como un marco de componentes JSF en la versión 2 es realmente bueno, pero todavía 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 desarrolladores con experiencia JSF (lo que es aún más significativo). Y, por el contrario, eche un vistazo al éxito de Rails, Grails, Django, Play! Marco: todos están basados ​​en la acción y no intentan ocultar la verdadera solicitud / respuesta del progtwigdor y la naturaleza sin estado de la web.

Para mí, es una gran desventaja de JSF. En mi humilde opinión, JSF puede adaptarse a algún tipo de aplicación (intranet, formularios intensivos), pero para la aplicación web de la vida real no es una buena forma de hacerlo.

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

Algunas desventajas que me 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 un GET en algún lugar, debe hacer un servlet / JSP sin formato.
3. La mayoría de los componentes intentan proporcionar abstracciones sobre dominios como bases de datos relacionales y JavaScript front-end, y muchas veces estas abstracciones son “permeables” y muy difíciles de depurar.
4. Estas abstracciones pueden 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 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 tiene poco conocimiento de lo que está pasando debajo del capó.
5. Los mecanismos de plantillas que generalmente se utilizan con JSF no tienen nada que ver con la forma en que funcionan los diseñadores web. Los editores WYSIWYG para JSF son primitivos y, en cualquier caso, su diseñador le dará HTML / CSS que deberá pasar convirtiendo años.
6. Cosas como las expresiones EL no están comprobadas estáticamente y tanto el comstackdor como los IDE no están haciendo un buen trabajo al encontrar errores, por lo que terminarás cometiendo errores que tendrás que atrapar en el tiempo de ejecución. Esto podría estar bien para el lenguaje tipado dinámicamente como Ruby o PHP, pero si tengo que soportar la abrumadora enormidad del ecosistema de Java, exijo tipear para mis plantillas.

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

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

• HTML en las diversas encarnaciones. No pretendas que no necesitas saberlo.
• HTTP: cuando no puede descubrir qué está pasando, debe abrir Firebug y ver. Para eso necesitas saber esto.
• CSS – Me gusta o no. No es tan malo en realidad, y al menos hay algunas buenas herramientas.
• XML – JSF probablemente sea el primer lugar en el que use espacios de nombres hasta este grado.
• Especificación del servlet. Tarde o temprano entrarás en los métodos de llamada en este paquete. Aparte de eso, debes saber cómo tus Facelets se convierten en XHTML o lo que sea.
• JSP (principalmente para que sepa por qué no lo necesita en JSF)
• JSTL (nuevamente, principalmente para hacer frente al marco heredado)
• Lenguaje de Expresión (EL) en sus diversas formas.
• ECMAScript, JavaScript o lo que sea que quieras llamarlo.
• JSON: debes saber esto incluso si no lo usas.
• AJAX. Yo diría que JSF 2.0 hace un buen trabajo ocultando esto, pero aún necesita saber qué está pasando.
• El DOM. Y cómo lo usa un navegador. Ver ECMAScript.
• Eventos DOM: un tema en sí mismo.
• Java Persistence Architecture (JPA) eso es si quieres que tu aplicación tenga cualquier base de datos de back-end.
• Java en sí.
• JSEE mientras estás en eso.
• La especificación de Inyección de Dependencia de Contexto (CDI) y cómo se opone y se usa con JSF 2.0
• JQuery: me gustaría ver que te lleves bien sin eso.

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

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

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

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

Entonces, ¿ESTO ES HACIENDO FÁCIL? Claro, JSF 2.0 es “fácil” siempre que lo único que quiera hacer es encontrar las páginas web más básicas con las interacciones más simples.

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

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

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

1. Los desarrolladores sin experiencia generalmente 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 el aprendizaje si desea escribir buenos progtwigs.
2. Al menos al principio, a menudo te “quedarás atrapado” en algún problema y pasarás más tiempo leyendo mensajes de balusc en Internet que trabajando realmente 🙂 Después de un tiempo será cada vez menos, pero aún así puede ser molesto.
3. Aún más molesto cuando descubres que el problema no se debe a tu falta de conocimiento / error, sino a un error. Mojarra estaba (¿es?) Bastante problemático, y otra capa de componentes agrega aún más problemas. Richfaces fue la mayor pieza de software malicioso 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 la falta de características, especialmente con componentes más exóticos. Y ahora deberá pagar por las actualizaciones de Primefaces. Así que diría que su buggy pero está mejorando especialmente después de que la versión 2.2 solucionó algunos problemas con las especificaciones. Marco cada vez más maduro, pero aún lejos de ser perfecto (¿quizás 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. De nuevo estoy hablando de la perspectiva promedio del desarrollador: la que tiene plazos, tutoriales de lectura rápida y búsqueda de stackoverflow cuando se estanca porque no hay tiempo para aprender cómo funciona realmente. A menudo, algunos componentes parecen tener “casi” lo que necesita, pero no exactamente, y algunas veces puede pasar demasiado tiempo para que haga lo que quiera 🙂 Debe tener cuidado al evaluar si es mejor crear su propio componente o torturarlo. En realidad, si estás creando algo realmente único, no recomendaría JSF.

Así que, en resumen, mis inconvenientes serían: Complejidad, Progreso de desarrollo no muy fluido, con errores, inflexible.

Por supuesto, también hay ventajas, pero eso no es lo que preguntaste. De todos modos esa es mi experiencia con el framework, otros pueden tener opiniones diferentes, así que la mejor manera es probarlo por un tiempo para ver si es para ti (algo más complejo, ejemplos no ingenuos, JSF realmente brilla allí 🙂 En mi opinión, el mejor caso de uso JSF es aplicaciones comerciales, como CRM, etc.

Desarrollamos un proyecto de muestra con JSF (¡Fue una investigación de tres semanas por lo que es posible 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 usos:

1. Una página con una grilla La cuadrícula se carga a través de ajax y debe admitir ordenació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 de la base del servidor ajax (para validaciones complejas). Cualquier excepción de servidor (desde la capa de servicio) se debe mostrar en la misma página del asistente sin navegar a la página siguiente.

Encontramos eso:

1. Necesitará usar algunos hacks de omniFaces para arreglar el estado de la vista JSF. El estado de JSF se dañará cuando incluya páginas a través de ajax entre sí. Esto parece un error en JSF y puede corregirse en próximas versiones (no en 2.3).
2. JSF Flow no funciona correctamente con ajax (¡o no podríamos hacerlo funcionar!) Intentamos utilizar el componente de asistente de la interfaz en su lugar, pero la validación del cliente parece no ser compatible y mala mientras que no era el estándar estándar de flujo de JSF.
3. Cuando utilice algunos componentes de jQuery como jqGird, y necesite cargar los resultados de JSON, se le aconseja utilizar servlet puro. El JSF no hará nada por usted. Entonces, si usa este tipo de componentes, su diseño no cabrá en JSF.
4. Intentamos hacer algunos scripts de cliente cuando ajax se completa con ajaxComplete y encontramos que el PF 4 ha implementado sus propios eventos ajax. Teníamos algunos componentes jQuery y tenemos que cambiar su código.

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

Resumimos nuestra investigación como:

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

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.

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 😉

No soy un experto en Java Server Faces en absoluto. Pero en mi humilde opinión la principal desventaja es que es del lado del servidor. Estoy cansado de aprender y usar frameworks de capa de presentación web del lado del servidor como ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, frameworks php y ruby ​​on rails frameworks. Me despedí de todos ellos y les dije hola 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 es servido por un servidor web Apache que se ejecuta en Linux. Solo necesito aprender un solo marco que funcione en todas partes.

Solo mis dos centavos.

Para mí, la mayor deficiencia de JSF es un soporte deficiente para páginas generadas de forma programática (dinámica).
Si desea construir su página (crear un modelo de componente de página) dinámicamente desde el código java. Por ejemplo, si está trabajando en el constructor de página web WYSIWYG. La documentación adecuada de este caso de uso no está generalmente disponible. Hay muchos puntos donde tienes que experimentar y el desarrollo es lento y silencioso. Muchas cosas simplemente no funcionan como esperarías. Pero en general es posible piratearlo de alguna manera.
Lo bueno es que no es un problema en filosofía o architecture de JSF. Simplemente no está lo suficientemente elaborado (hasta donde yo sé).

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 el proceso silencioso, complicado y casi indocumentado de la construcción dinámica del componente compuesto, 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. 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 especificación.

Al comentar sobre mis últimos meses de experiencia Primefaces / JSF:

• Si puede usar componentes “de fábrica”, supongo que no es terrible.
• Sin embargo, no funciona bien tan pronto como sales y necesitas IU personalizadas. – Por ejemplo, necesitábamos usar el bootstrap de Twitter para nuestro proyecto. (No es primordial bootstrap).
  • Ahora nuestras páginas funcionan de la siguiente manera:
    • Cargas de página.
    • El usuario interactúa con Primefaces que tiene la funcionalidad ajax
    • Las encuadernaciones javascript de Bootstrap se rompen
    • Ejecutamos javascript extra 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 usamos Primefaces, y ese javascript es para arreglar lo que Primefaces rompe.

Es un sumidero de tiempo, a menos que vuelva a usar cosas “de fábrica”. También realmente feo (Primefaces) cuando se tiene que trabajar con Selenium. Todo se puede hacer, pero de nuevo, 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, puede ahorrar tiempo aprendiendo jquery / escribiendo HTML directamente o mirando reactjsr / angular.

JSF tiene muchas ventajas, la cuestión de estar en desventaja, déjame agregarle algunos puntos.

En un escenario práctico de implementación de un proyecto web dentro de un marco de tiempo, debe vigilar los siguientes factores.

• ¿Tiene suficientes miembros sénior en su equipo que puedan sugerir los mejores 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 que no se puede mantener.

JSF solo tiene una desventaja: antes de comenzar el desarrollo de “JSF”, debe comprender claramente el desarrollo web, el núcleo Java y la architecture front-end.

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

Among all the “mainstream” frameworks such as Spring MVC, Wicket, Tapestry, etc., the JSF of Java EE with its composite components is the most elaborated presentation-layer and component-oriented technology provided. It is a bit cumbersome and incomplete compared to solutions provided by HybridJava.