¿Por qué se prefiere Facelets sobre JSP como el lenguaje de definición de vista de JSF2.0 en adelante?

Veo que a partir de JSF2.0 en adelante, el lenguaje de definición de vista de Facelets es el lenguaje de definición de vista preferido y no el JSP que se ha desaprobado como retroceso heredado. Quiero entender por qué Facelets es preferible a JSP como el lenguaje de definición de vista de JSF2.0 en adelante? Sé que JSP también tiene un comportamiento de plantillas que es el principal punto de impulso para la adopción de Facelets.

PD: He pasado por esta publicación en stackoverflow pero no creo que responda mi pregunta. De ahí publicar esto como una pregunta separada.

Es cierto que JSP tiene algunas capacidades de creación de plantillas , pero la mayor desventaja de utilizar JSP en JSF es que JSP escribe en la respuesta tan pronto como encuentra contenido de texto de plantilla, mientras que JSF desea hacer algo de procesamiento previo / posterior con él. En JSF 1.0 / 1.1 el siguiente código JSF

 second  fourth 

produciría

segundo cuarto primer tercero

Esto fue durante las edades JSF 1.0 / 1.1 un dolor de cabeza . Los desarrolladores tendrían que ajustar el texto de la plantilla como second y fourth en el ejemplo anterior en tags en todos los lugares. JSF 1.2 lo ha resuelto con un controlador de vista mejorado que analiza el JSP en lugar de ejecutarlo, pero todavía era muy torpe porque la syntax JSP no está “bien formada” como XML. Se deseaba una tecnología de visualización basada en XML, de modo que se pudiera utilizar un analizador basado en SAX eficiente. Y Facelets nació (entre “JSFTemplating” de Ken Paulsen).

Además, el EL #{} unificado no se podía usar en el texto de la plantilla JSP, lo que resulta feo, y para los principiantes no es intuitivo , la mezcla de ${} y #{} . Además, JSTL podría, en JSF 1.x en JSP, no usarse como ver las tags de tiempo de comstackción . Además, la syntax de JSP con < % %> cosas es de la vieja escuela y la posibilidad de incrustación de código Java sin procesar en JSP se considera una práctica muy pobre que rompe la ideología de MVC .

Con todo, en perspectiva JSF / MVC, JSP es simplemente feo y terrible y Facelets es simplemente limpio e impresionante.

Encontré las siguientes respuestas en Internet.

Documentación JSFToolbox capítulo 3 :

JSP Compile-Time Overhead

Cada vez que edita, guarda y recarga una página JSP, el comstackdor JSP del servidor genera código de servlet Java y lo comstack en un servlet. Esto se denomina proceso de traducción JSP, y generalmente cuesta entre 1 y 2 segundos, dependiendo del rendimiento del servidor.

Facelets XML Comstacktion

A diferencia de JavaServer Pages, las páginas Facelets no se comstackn en servlets. Dado que las páginas de Facelets cumplen con XML, el marco Facelets usa un comstackdor rápido basado en SAX para construir sus vistas. Además, Facelets se puede configurar para detectar y realizar cambios en sus páginas de forma inmediata, lo que acelera el ciclo de desarrollo de JSF.

Reserve “componentes JSF 1.2” de Ian Hlavats, página 49 :

Durante el desarrollo de la aplicación JSF, a menudo realizamos cambios en nuestras páginas JSF, lo que resulta en la recostackción frecuente de nuestras páginas JSP, y esta sobrecarga en tiempo de comstackción puede sumrse.

Las páginas Facelets son documentos XML simples (páginas XHTMl) que nunca se comstackn en servlets, sino que usan el proceso de comstackción basado en SAX que construye el árbol de componentes de la interfaz de usuario para nuestras vistas. Por lo tanto, Facelets es más rápido en comparación con JSP, ya que está libre de la sobrecarga de traducción JSP.