¿JSF y Jakarta EE? .Todos hemos trabajado alguna vez en unos u otros proyectos con JSF (Java Server Faces) y su tecnología orientada a controles. Una pregunta que cada día mas gente se hace es : ¿Cual es el futuro de JSF?. Para muchas personas la respuesta tiende a ser sencilla . JSF es el estandar de Java EE a nivel de capa de presentación por lo tanto tiene futuro. Sin embargo ya hemos tenido en otras ocasiones standards de la plataforma Java que han pasado a mejor vida o han tenido que reinventarse de forma significativa. Vamos a ver un diagrama que en 2015 hablaba sobre cuanto se usaba JSF y cual había sido su evolución usando Google Trends:
En ese momento se veía la tecnología en franco retroceso . Han pasado 7 años desde aquel momento y si volvemos a solicitar la gráfica la situación puede ser mucho más escandalosa.
Vista la gráfica nos encontramos un una situación de muerte cerebral de la tecnología o por lo menos eso es lo que parece a tenor de la curva en franco descenso que se muestra. Sin embargo nos guste o nos guste sigue siendo parte de los standares de Java EE . Durante muchos años esta tecnología se ha usado y hay muchas aplicaciones construidas con ella. Si preguntamos a Google Trends por el framework de JSF que más se usa en el mercado hoy en día (PrimeFaces) que engloba no solo la solución de JSF que fue su primer producto sino soluciones adicionales para Vue ,React y Angular basadas todas en un framework de componentes.
PrimeFaces
Si añadimos a la búsqueda PrimeFaces y comparamos la gráfica nos daremos cuenta que hoy por hoy una solución como PrimeFaces que es un producto supera con creces a un standard como en su momento fue JSF. Es evidente que el interés por JSF ha decrecido de forma absoluta y otras tecnologías han ocupado su lugar a la hora de diseñar soluciones de FrontEnd.
Si miramos la gráfica de Google Trends incluyendo React , Angular y Vue como frameworks de JavaScript . Las cosas se clarifican mucho. JSF e incluso PrimeFaces prácticamente desaparecen de la gráfica. ¿ A que se ha debido esto? .
JSF y Servidor
JSF siempre ha gestionado su ciclo de vida a través del servidor construyendo los distintos tipos de controles que necesitamos usar. Dejando al cliente unas responsabilidades bastante reducidas
Hoy por hoy muchas aplicaciones han optado por delegar una gran parte de las responsabilidades al cliente Ejemplos claros son las plataformas móviles con HTML5 ,Arquitecturas SPA y librerías como React , Vue o Angular que se ejecutan en el cliente y que usan el servidor para obtener información de datos e hidratar a los controles de los que disponen.
Apartándonos una gran flexibilidad ya que al publicar la información como datos puros otras aplicaciones se pueden acceder a ellos de una forma transparente. Las arquitecturas REST son mucho más flexibles que estas arquitecturas MVC de Servidor.
¿Entonces JSF ha muerto o esta vivo?
Después de ver las gráficas todos deberíamos entender que JSF ha muerto . Es mucho más interesante desarrollar aplicaciones con Angular o React o Vue a la hora de la plasticidad que ofrecen. Sin embargo sorpresa sorpresa el standard de Jakarta EE que es el nuevo standard de Java anuncia un soporte para JSF 4.0 . Recordemos que hasta hace poco estábamos en la versión 2.3 .
Java Server Faces 4.0
¿Qué sentido tiene esto? . Bueno primero hay que puntualizar que JSF no era una tecnología horrible y que en muchas ocasiones para soluciones complejas en una intranet aportaba una solución razonable muy integrada con los estándares .y la sigue aportando . Segundo y lo más importante JSF es el standard y al ser el standard muchas empresas apostaron por ello por su “longevidad”, porque es algo que en el tiempo perdura y nos permite estar mas tranquilos sobre la evolución tecnológica de nuestra plataforma .
La versión 4
El hecho de que JSF tenga una versión 4.0 dentro de Jakarta . Es una apuesta fuerte de la comunidad Java por la longevidad de la tecnología . Por las miles de aplicaciones internas que muchas empresas tienen desarrolladas sobre Java Server Faces y que necesitan mantener durante un futuro. No todo el mundo se puede permitir inversiones gigantes para actualizar el stack tecnológico por completo. JSF seguirá muy vivo en nuestros servidores durante mucho tiempo ya que los estándares la apoyan y los estandares mandan.
Yo diría que hay que analizar el problema a resolver y luego elegir el stack y/o tecnología que calculan será mas eficiente de usar y durará mas en el tiempo porque luego será muy difícil que se invierta mucho dinero en cambiarla a la tecnología de moda que surgirá mas adelante.
La clave es no elegir stacks por moda
Aguantarse, tranquilizarse dar un paso atrás y pensar.
Hay que hacer un balance entre lo que uno desea y cree que pasará y la realidad del problema a resolver y su calidad de equipo.
Por ultimo les diría que una gran cantidad de proyectos fracasan por creer que son lo que no son
La realidad es que
NO SON NETFLIX,
NO SON MERCADOLIBRE,
NO SON FACEBOOK.
muy buena tu reflexion 😉
gracias
Me parece interesante la descripcion que se realiza, sin embargo las aplicaciones empresariales que por lo menos me ha tocado realizar en el ultimo tiempo utilizan los framework como Boostrap o Angular solo en presentacion, la logica generalmente es desarrollada para que se ejecute en el server, el concepto de RIA para aplicaciones HTML5 no existe completamente, primero por que funciona mal por las distintas implementaciones de los browsers, lo unico que genera intentar realizar ese trabajo es tener programas llenos de if si el browser es mozilla-edge-chrome, adicionalmente uno siempre intenta tener un sistema que sea facil de mantener, operar, modificar y todas las nuevas tecnologias que ofrecen los framework como Spring son lentas y expurias (si se ha dado el trabajo de leer el codigo interno). Como por ejemplo al utilizar Boostrap el trafico que genera es casi incomprensible, ver todo lo que se traslada al cliente. Por lo cual a mi opinion si bien el concepto de MVC es necesario y absolutamente correcto, creo que falta por optimizar y modularizar. ADF es una excelente opcion, sobre todo para los que trabajan con JSF y quieren migrar a algo con muy poco esfuerzo.
JSF es una opción más pero hoy por hoy cada día los frameworks MVC que publican información en JSON tienen mucho futuro
Métanse a ADF ¿por qué pierden el tiempo?, ADF es JSF, brinda mayores satisfacciones que PrimeFaces que también es JSF.
Gracias por el aporte 🙂
Buena opción, si se deciden por usar JSF mejor es usar ADF de Oracle y es libre. Puede ser implementado en Glassfish, JBoss, Wildfly.
Nunca habia escuchado de ADF.
JSF, Spring, Hibernate los tiene NetBeans como frameworks.
Podrias explicar un poco mas, donde obtengo informacion, gracias.
Uff no sabría decirte igual aquí
PrimeFaces no es JSF , es una extension de JSF.
Muy buen post. Estoy de acuerdo en lo que has publicado, yo agregaría un punto adicional: “Licenciamiento”. Ya vimos la guerra que Oracle le ha declarado a Google, y creo que esto también debe ser un punto importante si no quieres gastar dinero en el futuro con abogados.
Hola
Escribo desde Chile, quisiera saber si aún está vigente JSF en el 2017 ya que estoy por desarrollar un proyecto para una Clinica Intranet, me preocupa el impacto que puede tener el sistema en el futuro o que pueda tener tropiezos o problemas durante el desarrollo del proyecto.
Muchas gracias.
Es parte de los standares y sigue totalmente vigente. De hecho es una tecnología que tendrá futuro ya que la soporta Oracle. Otra cosa es que existan otras opciones de cliente más interesantes
Cecelio, yo soy desarollador java en Brasil.
Los parabenos el articulo!
Buenas 🙂 , gracias /thanks
Hola, creo que la tecnología jsf se mantendrá pero irá “migrando” la lógica de cliente hacia el lado del cliente.
Me explico?. Hoy por hoy toda la iteraccion y eventos se produce realmente en el browser pero se ejecuta en el server.
Los bakend beans pasaran a ser una especie de “restservices” y la vista hablara con ellos de forma transparente y nosotros ni nos daremos cuenta porque se seguira programando como antes.
Incluso me atrevería a decir que esta funcionalidad podría ser configurable.
El proyecto de primefaces y angular tiene un aire así
Muy buen post, sin duda java al ser compilado lo hace mas rapido que los demas lenguajes interpretados.
Y en cuanto a las estadisticas en google trends, puede deberse a que hay una gran cantidad de desarrollo pequeños (paginas web, blogs, paginas personales) con poco recursos para pagar un hosting en java, o servidor dedicado, etc. y usan tecnologias de menor costo, integrados con jquery, angular, boostraps.
Algo asi, usar JSF para mi pagina personal, para un blog, sin duda noo
Entonces JSF lo dedicas mas que todo a aplicaciones empresariales, intranets,
Gracias , cada tecnología tiene su hueco 🙂
Java es semicompilado. Saludos
Así es, para ello tiene la JVM.Saludos
Buenisimo el post, en este momento estoy desarrollando una web app para ofrecer un servicio de estadisticas, de momento llevo gran parte pero sin usar frmaworks, he estado realizando el mvc puro a mano, los servlets y el modelo todo a mano, no he tenido problemas, que diferencia tendria en usar spring mvc ya que leo que es puro mvc?, y por cierto seria muy trabajoso migrar mi trabajo a spring o es sencillo? o mejor sigo a mano con el mvc y no es problema?
Gracias si me pueden solventar estas dudas, saludos.
En principio sencillo sencillo no te será , pero pienso que que si tienes servicios y vistas tipo JSTL es algo abordable. Spring te facilitará las cosas y te aportará muchas cosas adicionales que te serán útiles en el futuro
ADF es JSF, arrastras lo ya programado (tablas, etc) y lo que ya se supone está enlazado a base de datos, y listo!, y por dentro tiene ajax, etc…o sea, tiene bastante futuro. ¿por qué no picas código? para qué, si donde tienes que invertir tiempo es en diseñar la database, luego, la herramienta, Oracle JDeveloper, te permite utilizar este RAD. Cualquier cambio, automáticamente se actualiza. Mejora la productividad.
Sin ADF, picas código, repites el código, no pones tiempo en la database, demuestras que picas código, el resultado, falta la hoja de estilo, aplicas html5 para border redondeados, sorpresa! no funciona en todos lso exploradores, sigues picando código para arreglarlo, sorpresa! el analista pensó en cambiar una tabla, picas código para acomodar este DAO, después de meses deciden cambiar la apariencia, sorpresa! a cambiar los estilos, y así picando código para algo que puedes resolver simplemente con drag & drop y con ADF,
La competencia que existe hoy es muy fuerte , JSF es una de muchas tecnologías y soluciones como Angular y React están haciendo que se use menos. Simplemente echa un vistazo a google trends y veras que la tendencia de JSF esta en declive. Eso no quiere decir que no se pueda usar . Simplemente que ahora mismo hay mas opciones y dependiendo de la situacion , opciones mejores.
Un saludo
Llevo poco con JSF y estoy probando la versión 2.2, donde según leo, se puede configurar en el descriptor de despliegue de los JSF, si queremos que se ejecute en el cliente o en el servidor. Desconozco si esto es una característica nueva, pero entonces no debería verse a JSF como inferior frente a otros framework que se citan aquí que tienen esa posibilidad de ejecutarse en el cliente.
No es exactamente eso , lo que pueden hacer es salvar el estado en el cliente que es diferente , eso permite reducir memoria en el servidor pero aumenta el consumo de trafico http
Saludos expertos, que me aconsejan como arquitectura de backend para capturar unos datos de un videojuego en unity y luego mostrar una metricas de uso y frecuencia del juego mas otros datos que google analitics no me entrega?
mil gracias.
Muy buen artículo. Yo he pasado recientemente de trabajar con frameworks javascript modernos y la verdad, no hay color.
Es terrible cuán acoplado está el código backend con el frontend, la lentitud que supone tener que compilar la mayoría de las veces para ver cambios en front, es tedioso.
Por no mencionar que si quieres renovar alguna parte de tu arquitectura ¡Ya no puedes! estás atado a ella de por vida, y mas si es un proyecto grande.
Un backend estilo API rest da mucha mas flexibilidad y tiene mucho mas sentido hoy en día, con clientes cada vez mas potentes, tanto web como nativos.
La plataforma de JavaScript tiene un futuro brillante 🙂
Todo lo que dices es falso, se nota que JSF no lo has tocado ni en media semana, para ver cambios en el front no necesitas compilar… , utilizando JSF siempre vas a estar tocando JavaScript o CSS si quieres hacer una web en condiciones y tocando lo último no estás atado… JSF renderiza por componentes puedes utilizar reglas de estilo sobre esos componentes o crear los propios, o directamente hacerlos en HTML 5 con passthrought, JSF es el futuro, JavaScript es bueno en el cliente pero no para la lógica de negocio, es un lenguaje horrible y a años luz para mantener y depurar cómo en Java, por no decir que Java es más rápido en el servidor que JavaScript y para la parte cliente y no tener que recargar la página al completo ya tienes ajax integrado.
Y eso de utilizar REST para la web me parece prehistórico, una cosa es para utilizarlo en plataformas nativas como Android o iOS, pero cuando existen plataformas que ya te lo dan todo mascado es una forma muy absurda de reiventar la rueda y perder enormes horas de tiempo y dinero, ah y no se dice “frameworks modernos” se dice código inmaduro que es muy diferente, el software no va por modas, no al menos si quieres hacer software serio.
Bueno todas las opiniones son respetables
Las opiniones pueden ser respetables pero si son falsas alguien debería decirles algo, está muy de moda utilizar javascript en el servidor, pero cualquier ingeniero de software sabe que Javascript no es precisamente un lenguaje bien diseñado hace agua por todas partes y sin software mantenible y fácil de testear o con posibilidad de realizar TDD, estamos retrocediendo 20 años.
El único lenguaje que puede ser una alternativa es Python, la misma Google suele utilizarlo en situaciones donde no utiliza Java, pero estámos en las mismas es un lenguaje dinámico por tanto complicado hacer TDD y depurarlo, otro puede ser C# pero está muy enfocado en Window, pero si es un lenguaje a la altura de Java y por cierto PHP,JavaScript o Python en el servidor son muy muy lentos en comparación a la velocidad que alcanza Java con un programador que sabe patrones de diseño y entiende de manejadores de memoria como pools y como funciona el recolector de basura.
También recuerdo que en cualquier proyecto software el coste del 80% será su mantenimiento de hay que a nivel empresarial a nadie se le ocurra utilizar lenguajes o tecnologías inmaduras.
Siento discrepar , creo que JavaScript a nivel de cliente tiene un presente y futuro brillante.
Yo sólo me refiero al lado del servidor ya que muchos dicen que Java es lento y que JavaScript puede equipararse a Java en el lado del servidor siendo completamente falso, en el lado del servidor PHP, JavaScript y Python seguirán siendo lenguajes de segunda clase ya que son dinámicos y sin la madurez de Java a nivel de ingeniería del software.
Y si JavaScript no es que tenga un futuro brillante pero su presencia en el lado del cliente es esencial por ahora y al menos el diseño del lenguaje es apto para el lado del cliente hasta cierto punto.
El futuro que tiene por delante es el tiempo que tarden en sacar WebAssembly, recuerdo que detrás de el unen fuerzas Google, Mozilla y Microsoft, cuando de forma nativa para la web lenguajes más legibles tengan la misma velocidad JavaScript quedará en el olvido.
Un ejemplo https://webassembly.github.io/demo/ , y el rendimiento es sobre unas 20x frente a JavaScript, hay queda eso, eso si ya adelanto que JavaScript es lento de narizes en el cliente, cualquiera que haya hecho uso de el para crear un panel de administración con estadísticas del sitio lo sabe de primera mano la única ventaja es que por ahora es el único lenguaje de primera clase en la web, pero tiene los días contados :).
Yo creo que en el servidor Java sigue ganando 🙂
Creo que tomar gráficas que se basan en las tendencias de búsqueda es una forma muy superflua de abordar este tema y que puede dar resultados engañosos. si se combina ambas gráficas se ve como jsf sigue superando a spring mvc y no lo digo porque prefiera uno u otro, simplemente hay que evitar dar malas interpretaciones a los datos sino tenemos opiniones sesgadas por nuestras preferencias personales.
Siempre es relativo y hay que ver como avanza todo primefaces ahora tiene unos proyectos muy interesantes con angular.
de todas maneras la gráfica que a mi me ha salido es esta que sigue poniendo a Spring MVC por delante , pasame por favor un link a tu comparativa porque igual en otro sitio sale distinto , muchas gracias
Hola, pues la verdad acabo de ver el link, y actualmente jsf esta empatado en búsquedas con Spring, y angular y react están demasiado distantes, es más, si te vas al mapa JSF gana en todos los países menos en uno. Saludos.
Buenas
Yo acabo de hacer una búsqueda por tendencias 🙂 y ahora angular tiene más tirón.
son dos modos de trabajar totalmente distintos, si queres hacer un aplicativo lo mas rápido que se pueda jsf contribuye en gran medida, pero existen muchos programadores que no les gusta ser configuradores, sino que hace uso de múltiples herramientas y lenguajes para hacer una funcionalidad innovadora, para hacer un simple ABM cualquier tecnología es buena, pero los desarrolladores java siempre buscamos nuevos desafíos.
de lo contrario estariamos hablando de webform + vb.net.
Hola Cecilio, entonces que me recomendarías para realizar una página tipo amazon o una red social, es decir que tienen mucha concurrencia; saludos, felicitaciones por tu página.
Spring MVC + Algún frawework MVC que te encaje 🙂
Muy interesante el blog en general y energizante los articulos principalmente para aquellos que no dominamos el ingles perfectamente.
Mi apreciación sobre el tema es que todo depende de lo que las personas dominen. La mayoria de las personas que usan estos framework js provienen de php y el desarrollo web en general y no conocen mucho el mundo JSF. Cada cual habla de lo que sabe. Pero no creo que los desarrolladores JSF se estén pasando a framework js.
saludos
Ojala hubiera soluciones absolutas, creo que los frameworks JS son unos competidores muy fuertes , pero JSF también tiene su hueco.
Hola,
Si se puede desarrollar aplicaciones grandes con bootstrap, jquery, angular ….. y spring mvc… depende de la arquitectura backend y la arquitectura frontend, pero sin dudas se pueden realizar componentes javascript (jquery, etc) las cuales se ejecutaran muy rapido en el cliente… Pienso en arq. SOA + microservices, y consumir todo en jquery, angular o lo que sea… con un buen layout… la seguridad se puede validar en ambos lados… Que curioso que en esta transnacional donde trabajo aun no usan JSF…
A día de hoy va a menos claramente 🙂
Buenas noches todos los framework basados en JS son utilizados para el frontend.Hoy en día ya la mayoria están llegando al servidor pero en la actualidad el performance no es comparable con JSF.
JSF es un framework para aplicaciones web transaccionales.Este se vale de PrimeFaces para decorar mejor su presentación. Ahora salió otro candidatos para su decoración FacesBostrup.
Solo son tecnologías para el frontend. Ahora el manejo de la paginación de una grilla siempre va ser mas lento en formularios basados en js, del lado del cliente. La mejor tecnología para el manejo de paginación la tiene jsf PaginationHelper. Una paginación hecha en primeces , NodeJS, Angular es muy lenta porqué. Primero se leen toda la tabla y depues hacen la paginación mientras la que utiliza jsf la rewaliza por el numero de registros que qquieres mostras. sin importar si la tabla tiene 10 millnes de registros, esta te muestra la grilla en menos de un 3 segundos.
Yo soy un ongeniero experto en tecnologia java EE y trabajo con JSF 2.x, JPA 2.1, EJB 3.x, Primefaces 4,5.x, EclipseLink, GlassFish, JBoss, etc. Lo importante de todo el tema que se trata aquí es que el performance se consigue con la configuración, buena programación las escogencias de las componentes.
No hay una solución unica también puedes acabar paginando con Angular o con REact o con lo que necesites. Para mi primefaces es de lo más avanzado que hay en el mundo JSF y esta integrando soluciones tipo Angular con el.
Yo trabajo con JSF y es lo mejor que he visto vengo desde los años 80 desarrollando desde D.O.S. y JSF es lo mejor que he visto no tiene limitaciones cuando se sabe trabajar.
JSF tiene sus ventajas al ser un standard
Tiene mucho futuro. En una encuesta en DZone (https://dzone.com/articles/poll-what-java-jvm-frameworks-do-you-use) en Agosto pasado, JSF lideró con 34.5% (463 votos) frente al 34.2% (459 votos) de Spring MVC. Si vemos encuestas anteriores, Spring MVC lideraba al menos por 5-7% de diferencia. Si bien la muestra es pequeña, es un pequeño reflejo del trabajo que se viene haciendo en JSF. JSF 2.2 y su compatibilidad con HTML5 han tocado fondo en los programadores (me incluyo).
He trabajado con JSF y Spring MVC y ambos me parecen soluciones válidas para la mayoría de casos (salvo real-intensive real time apps, en donde no dudo en usar NodeJS). Decir a estas alturas que JSF es más pesado está de más. Zeef, la página en donde puedes buscar recursos de todo tipo, está hecha en JSF. ¿Es lenta? Para nada. Parece que el fanatismo de algunos programadores por X framework hace que menosprecie a la competencia.
Lo que no me gusta del mundo de JSF es PrimeFaces. Los temas CSS por defecto son horribles, y para editarlos tienes que saber CSS intermedio; si usas un framwork tipo Bootstrap, la integración no se llevará a cabo y se verá feo estéticamente. Por ello siempre uso Bootstrap para mis aplicaciones, incluso sus controles JS como acordeón, modales, carruseles, tabs, etc.
Para resumir:
Aplicaciones pequeñas/Sitios web: Play, Spark
Aplicaciones pequeñas, medianas y grandes: JSF, Spring MVC, Struts
Yo tengo más dudas cada día JavaScript es más potente en el lado cliente y va a ser un competidor muy duro. No digo que JSF este acabado pero si que va a tener más problemas.
Yo tampoco tengo duda de eso. Y no se está haciendo más fuerte solo en el lado cliente, NodeJS está creciendo a un ritmo imparable. Yo creo firmemente que el futuro a mediano plazo será JavaScript, incluso puede dar batalla a Java/NET en el mundo Empresarial.
Como dijiste en un artículo, Java avanza lento y aunque desde una perspectiva es bueno para la empresa, creo que tiene su contraparte y es que si lo comparas con otros lenguajes como C# o Python, a mi gusto, Java como lenguaje, queda rezagado.
Es aconjonante ver como Oracle no invierte lo suficiente en Java para prestarle más atención a sus productos cloud. La JCP y su benditas JSR son los que lo mantienen en auge, porque Oracle poco (por no decir nada) aporta. Un futuro muy diferente hubiese sido si IBM ganaba la batalla por la compra de SUN 😉
¡Saludos!
Muchas gracias por el aporte 🙂 comparto tu opinión de que node esta creciendo muy rápido y va a competir de tu a tu en el futuro
¿que tecnología de presentación me aconsejaríais para implementar aplicaciones empresariales de gestión (contabilidad, gestión logística, etc.) en la intranet de la empresa?
Es una pregunta muy abierta, pero sobre todo elegiría una tecnología de largo recorrido en el tiempo…. JSF podría ser un ejemplo o también Spring MVC … dependerá mucho de lo complejo de la interface de usuario . A mayor complejidad mas encaja JSF. Hoy por hoy los frameworks de JavaScript de cliente son también una opción pero hay que empezar poco a poco con ellos . Yo ahora mismo si tuviera que elegir selecionaria Spring MVC + bootStrap
La velocidad de implementar Spring mvc (Angular+bootstrap), que consuman recursos del cliente es muy grande y superior a Struts 2.
Java JSF este destinado a mejorar o desaparecer!!!
Entre el desarrollo moderno de aplicaciones web y el enfoque de desarrollo de Java EE (JSF) hay sin duda alguna un gran vacío en donde hace falta construir un puente para unir ambos.
Yo soy desarrollador con Java EE/JavaFX pero también me soy un diseñador/UX aficionado. Me gusta siempre que mis aplicaciones tengan una vista que sea adapte a los estándares modernos y por ende una experiencia de usuario bastante agradable y creo que aquí es justamente en donde viene el conflicto con JSF, donde te limita de cierta forma la comunicación entre frontend y backend, en concreto, no te permite personalizar el comportamiento.
JSF es un framework que te abstrae de las tareas frontend comunes para que solo te centres en el backend. Por ejemplo, en lugar de hacer un script JS que haga una llamada AJAX JSF lo hace por tí tan solo mediante:
Personalmente nunca me ha gustado por más simplistas que sean, este tipo de frameworks porque no suelen adaptarse al cambio de los estándares frontend, como por ejemplo las SPA. Spring MVC por ejemplo, es mucho más amigable en este aspecto que JSF. Creo que fue un ‘error’ por así decirlo de SUN crear este framework. Si bien abstrae de tareas comunes y nos ahorra tiempo de desarrollo, te limita como programador/diseñador.
Por otro lado, la plataforma Java EE es realmente espectacular. JPA para el manejo de base de datos, JTA para transacciones, EJB como beans transaccionales y sus métodos asíncronos, CDI y su inyección de dependencias, calificadores, disposers, producers, eventos, JMS como servicio de mensajería, JAAS para el manejo de seguridad, y más. Todas estas son tecnologías muy maduras, testeadas y utilizadas durante muchos años que nos proveen seguridad y eficiencia en nuestras aplicaciones.
Por consiguiente, creo que hay actualmente 2 opciones:
– Utilizar Java EE (EJB, JPA, JMS, CDI, etc.) únicamente para backend y Angular, BackBone, CofeeScript, etc. para el cliente teniendo como vínculo entre ambos JAX-RS (Restful).
– Utilizar Java EE y Spring MVC como framework MVC y las tecnologías cliente que sean necesarias.
Personalmente elijo la segunda. Tengo mucha libertad en el frontent y puedo hacer lo que desee. Pero el uso de RESTs tiene un impacto no tan importante en el cliente que hay que tener en cuenta.
De todos modos, tengo 21 años así que carezco de la experiencia de muchos aquí y probablemente mi punto de vista esté equivocado.
Saludos.
Es un buen análisis , existen siempre más opciones como optar por JSF y PrimeFaces en la presentación , pero básicamente las dos que tu expones son las principales y la decisión esta muy ligada a la cultura empresarial de la organización
Jsf me gustó mucho, cuando era estudiante. Cuando llegue al ámbito laboral, trabajamos con Ajax y Jquery y al ver que este último no se podía integrar con JSF, le dije adiós. No me agrada que el código del cliente este muy amarrado a un framework, suficiente con Jquery.
hola a tod@s,
No se puede aplicar la misma solución a diferentes problemas. Las necesidades de una aplicación orientada a internet en la mayoria de los casos dista de una aplicación empresarial. Personalmente conozco jsf desde su versión 0.9 allá por el 2004-2005, pero con el tiempo para hacer aplicaciones empresariales me decanté por zkoss por considerarlo mas ligero y 100% ajax, además permitiéndome programar toda la lógica de comportamiento en java.
Hoy para la parte publica (internet) utilizamos angular js simplemente porque mediante json (apache cxf rest, jpa (hibernate), spring security y spring mvc en servidor), me permite dar mucho mejor rendimiento con menos recursos y mas escalabilidad en diseño.
El backend lo mantenemos con zkoss, BPM de activiti , servicios soa, brms ….
Personalmente recomiendo que en aplicaciones de gestión (intranets/extranets) se utilicen los frameworks como jsf, gwt,zkoss agilizan el desarrollo de potentes aplicaciones empresariales y permiten trasladar esa ansiada funcionalidad que tenían antaño las aplicaciones RIA de escritorio.
Pero si lo que vamos a construir es un portal con un elevado acceso de usuarios y que además el mismo diseño sea multi-canal (movil,web, tablet…) y donde los formularios no son demasiado complejos, recomendaría la utilización de angular js o jquery….
Por ello no creo que esté decayendo JSF y otros frameworks del lado de servidor, simplemente se está racionalizando su uso con la aparición de mejores frameworks en javascript.
Interesante entrevista a uno de los creadores de zeef.com donde se debate este tema http://www.adam-bien.com/roller/abien/entry/a_java_ee_startup_filtering
Gracias por el aporte 🙂
Hola, primeroque nada muy interesante tu blog. Con respecto a este artículo no estoy de acuerdo con lo que mencionas. Si bien es cierto que los frameworks JS hoy por hoy están ganando popularidad, no quiere decir que JSF este perdiendo popularidad. Muchos criticaron JSF en su momento (versiones 1 y 1.2) pero desde la versión 2.0 y especialmente 2.2 JSF mejoró muchisimo en un montón de aspectos. Siempre se critico que es un framework Server-centric (del lado del servidor) y que consumia mucha memoria al mantener el estado de la vista en el servidor, pero gracias al PARTIAL-STATE-SAVING hoy por hoy JSF tiene una performance igual o superior a muchos frameworks JS, sin contar con todas las ventajas que tiene: Componentes, Converters, Validators, etc. Y gracias a librerías como primefaces, primefaces-extensions y omnifaces JSF se potencia mucho más (Client side validations con soporte de bean validations y un largo etc.).
Ejemplos de uso de JSF en web apps publicas es zeef.com no solo usa JSF sino varias tecnologías de Java EE.
Para no extenderme más les dejo y recomiendo leer las 3 partes de este artículo en inglés donde se evalúa la perfiomrance de varios frameworks para Java
http://content.jsfcentral.com/c/journal/view_article_content?cmd=view&groupId=35702&articleId=73398&version=1.8#.VXiyKkYaN9w
gracias por los aportes 🙂
Gracias por la nota, esta excelente, muy bueno el debate que se armo, desde mi punto de vista, el futuro esta en separar totalmente el Fontend del Backend, ya sea con Angular, Backbone, Polymer o cualquier otro Framework MVC Js del lado del Cliente, y del lado del Servidor Java, Spring MVC, NodeJs, etc.
De esta forma se puede separar totalmente el desarrollo de ambas partes, y enfocarse de lleno en el negocio y en la la vista, cada uno con su lógica.
De todos modos con un amigo estamos desarrollando en pequeño Faces “framework”, en realidad es una extensión de JSF, por ahora, creamos un par de componentes, como, dataTable, commandButton, popup, paneles, etc, son todos component composition, lo subimos a git, sin mucha explicación ni nada, la url es:
https://github.com/Clevcore/clevcore-faces
Lo estamos usando en un proyecto privado, al estilo de lo que nombraron anteriormente, es decir, sistemas de gestión del rubro de la medicina, que tranquilamente puede estar dentro de la Intranet, como así de Internet, aunque normalmente estos proyectos están dentro de una Intranet.
También les cuento que hace dos años, realizamos una red social, utilizando JSF, creando componentes compuestos, como firma, comentario, etc, y resulto un dolor de cabeza realizarlo, en ese momento me pregunte, debería existir una mejor forma, y actualmente creo que seria usar otras tecnologías para manejar el fontend y backend, pero por mi corta experiencia creo que el futuro esta en separar totalmente cada uno, y comunicarlos, no se con .json
Particularmente me gusta por la productividad con la que se trabaja con JSF2 y más usando Primefaces. Algo que en mi caso particular considero una fortaleza para JSF es que el manejo de validaciones se hacen en el servidor lo que le brinda mayor seguridad a la aplicación.
Es cierto que tiene un sistema sólido de validaciones de servidor 🙂
Es cierto jsf1 o jf2 version reciente combinado con primafaces esta bueno, pero el cliente pierde todo el control en el frontend debido que esos componentes los maneja el server, tambien apuesto por spring mvc, tengo bastante experiencia en struts2 me encanta es rapido y sencillo, pero quiero probar spring mvc a ver que tal resulta.Saludos desde Argentina.
spring mvc tiene un buen futuro
Hola Cecilio,
Primero que todo, muchas gracias por compartir tus conocimientos con todos.
Ahora respecto al futuro de JSF yo creo que compararlo con tecnologías en cliente es bastante superficial(no critico tu visión, sino que invito a expandirla). Según mi experiencia(tanto jsf como angular, spring mvc, otros..) cada tecnología tiene su ventaja y debemos tomar muy en cuenta las competencias del mercado. Por ejemplo, la simplicidad que nos entrega JSF(Primefaces, MyFaces,etc…) es muy alta y esto claramente permite mantener alto enfoque en la solución y no en la tecnología usada. Ahora bien, frameworks como angular, backbone… nos proporcionan toda una solución MVC en cliente, pero “cuantos buenos desarrolladores existen en el mundo JS”. No es una critica, pero considero que aumenta el grado de dificultad para los desarrolladores y en consecuencia la curva de aprendizaje es mucho mas alta.
Ahora no podemos dejar de lado, otras tecnologías emergentes como lo son NodeJS(JS en servidor), Bases de datos NoSQL, etc… Estas también proporcionan soluciones(ExpressJS) que afectan directamente a la popularidad de JSF.
Yo creo que todo depende del enfoque requerido:
– Si necesitas soluciones intranet para empresas, usar JSF es una gran alternativa por su efectividad, simpleza. Pero su rendimiento no es comparable con tecnologías de vanguardia(NodeJS)
-Si necesitas soluciones para internet, debes dejar de pensar en una sola tecnología dado que en la industria no se maneja una sola. Existen diversas opciones para cada requerimiento, es decir, puedes construir algo con JEE, Rails, Python, AngularJS, NodeJS,etc…
Finalmente, todo depende de lo requerido por tu cliente, producto o servicio.
Espero sea de utilidad lo comentado… saludos y reitero mis felicitaciones por tu blog.
Yo creo que todo tiene su hueco, JSF ha sido utilizado en intranets con bastante éxito. Pero hoy por hoy pienso que el universo JavaScript en el lado cliente esta sumando muchos apoyos por parte de la comunidad y eso le concede una posición digamos de “futuro” muy sólida
Buenas tardes,
No entiendo por qué insistís en intranet/internet. JSF es un framework web orientado a componentes y el cual mantiene un estado de lo que sucede en el cliente en el lado servidor. Esto tiene sus ventajas y sus inconvenientes. La ventaja es que el servidor es capaz de conocer en todo momento cual es el estado de los componentes. La integración ajax y la conversión de objetos de cliente a objetos servidor es poco menos que automática y la validación de los campos formulario también está integrada para el lado servidor. Por lo tanto las ventajas de JSF son simplicidad + seguridad.
El gran inconveniente bajo mi punto de vista es la necesidad de mantener este estado actualizado: La filosofía JSF en una vista (url) es básicamente notificar al servidor cuando se desea que se produzca un cambio y que el servidor vuelva a renderizar el DOM, todo esto por Ajax. En un framework orientado a requests, se modifica el DOM de la página en el cliente y cuando deseemos procedemos a lanzar el request. Por lo tanto obtenemos una opción más dinámica en el segundo caso, pero no creo que la diferencia resida en intranet/internet, si no en el tipo de aplicación. No programaría una aplicación cuyo peso resida en el lado cliente en JSF (con opción de trabajar offline o con poca conectividad, por poner un ejemplo). Pero JSF es perfectamente válido para aplicaciones de gestión y demás, que tengan una lógica importante en el lado servidor y sean relativamente simples en cliente.
Un saludo
Es cierto que la seguridad es uno de sus puntos fuertes . Ojalá hubiera una respuesta completamente válida para todo pero depende mucho de las situaciones
¡Buenas tardes!
Estoy totalmente en sintonía con lo que dice Aritz. En mi opinión, pensar que JSF es válido solo para aplicaciones de Intranet es subestimar la potencia de este framework.
Dentro del ámbito de aplicaciones de gestión, donde hay una lógica de negocio considerable (por ej.: entrada/salida de mercancía, gestión de stocks, venta de productos), yo les aseguro que JSF es una maravilla y más aún si lo combinamos con otros que facilitan la vida del equipo de desarrollo: Spring (para la gestión de sesiones a la base de datos, para el control de transacciones, etc..) e Hibernate para la persistencia en base de datos relacionales. No olvidemos que éstas son más fiables desde el punto de vista de la consistencia de datos que las denominadas NoSQL, lo que las hace ideales para este tipo de aplicaciones.
Saludos,
No lo dudo pero al ser un framework basado en componentes va a tener una dura competencia con los nuevos standares de HTML5 que se denominan web components y que entran en competencia directa con su filosofia. Lo mismo le va a pasar a ASP.NET Web Controls
A lo que me imagino que se refiere Cecilio (corrijame si me equivoco) es a la demanda de usuarios que tendría. Hablando de aplicaciones intranet en la mayoría de los casos entendería que hablamos de aplicaciones para empresas, que serían utilizadas por el personal de una empresa únicamente. Pudieran ser 2 usuarios, 5, 20, 100 por dar un ejemplo, teniendo límite en el tamaño de personas que conforman la empresa por ejemplo, lo cual es algo fácilmente manejable.
Pero hablar de una aplicación en internet implica que podría ser utilizada por 10000, 100000, millones de personas, es decir una demanda muchisimo mayor en la cual se necesitan aplicaciones que sean capaces de aprovechar al máximo los recursos y poder atender cientos de miles de peticiones de forma concurrente, algo para lo cual se han especializado elementos como nodejs por ejemplo.
Sobre todo me refiero a que una aplicación en internet puede tener un acceso remoto lejano en donde el trafico de red esta muy reducido y hacer peticiones al servidor pueda penalizar. En estos casos estar recargando continuamente la página penaliza mucho.
Me gustaría empezar a aprender un poco sobre SpringMVC pero, hay tantas cosas que no se por donde empezar. De hecho, no se qué es lo que debo buscar. Me gustaría saber si me podrías recomendar un path de cosas puntuales.
Muy bueno el blog pero hace falta los botones para compartir sus articulos , los botones de la izquierda algunos no funcionan.
Gracias por la información he actualizado wordpress a la última versión yo creo que ahora funciona 🙂
Pues ya veremos qué pasa. Mientras tanto estoy encantada con JSF 2, Spring, Hibernate y, cómo no, con primefaces…
Si hay que esperar un poquito a ver como avanza todo . Parece que JavaScript se comerá el lado cliente …. pero hoy por hoy todavia no lo ha conseguido
Me encanta su blog, arquitecto.
Y quisiera tener un poco mas de tiempo para poder ponerme al día y leer todas las entradas. 🙂
Ahora me gustaria, me diga que herramienta usas para hacer los diagramas que colocas, es
que se ven sencillos y muy puntuales.
Onmigrafle para mac 🙂
no que con PrimeFaces Extensions se puede tener los controles del lado del cliente?
PrimeFaces Extensions
gracias por el aporte no los había ni mirado … cual ha sido tu experiencia?
Yo he visto que primefaces ha agregado nuevos componentes y ha creado unos templates (de paga) y temas nuevos que se ajustan mucho el diseño actual de aplicaciones. Sin embargo, tiene mucho empuje los frameworks javascript, esperemos que JSF siga mejorando y las versiones de myFaces y mojarra sean mas rápidas.
Vamos a ver como avanza todo y luego se podrán tomar más decisiones 🙂
Pues todo apunta a una perdida de popularidad, puede ser por la aparición de otros frameworks que utilizan mas la parte de cliente como dices. Es un problema para los que estudiamos esta tecnología, y ahora me pregunto, que pasa con los frameworks para jsf? proyectos tan fuertes como primefaces, icefaces, etc. que te facilitan tanto la vida.
Yo croe que seguirán teniendo su hueco pero habrá que ver si soportan el empuje de Javascript. Por ahora van a tener que compartir su cuota de mercado con más competencia.
La respuesta a lo que pasa con frameworks como primefaces es que ellos ya estan migrando a esas tecnologias: primefacesUI y primefacesNG.
Gracias por el aporte 🙂