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

jsf tutorial español (2)

Encontré las siguientes respuestas en Internet.

JSP Compile-Time Overhead
Cada vez que edita, guarda y recarga una página JSP, el compilador JSP del servidor genera código de servlet Java y lo compila 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 Compilation
A diferencia de JavaServer Pages, las páginas Facelets no se compilan en servlets. Dado que las páginas de Facelets cumplen con XML, el marco Facelets usa un compilador 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 recopilación frecuente de nuestras páginas JSP, y esta sobrecarga en tiempo de compilación puede sumarse.
Las páginas Facelets son documentos XML simples (páginas XHTMl) que nunca se compilan en servlets, sino que usan el proceso de compilació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.

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 templating , 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

<h:outputText value="first"> second <h:outputText value="third"> fourth

produciría

segundo cuarto primer tercero

Esto fue durante las edades JSF 1.0 / 1.1 un headache . Los desarrolladores tendrían que ajustar el texto de la plantilla como second y fourth en el ejemplo anterior en etiquetas <f:verbatim> 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 sintaxis 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 unintuitive , la mezcla de ${} y #{} . Además, JSTL podría, en JSF 1.x en JSP, no usarse como ver las etiquetas de tiempo de compilación . Además, la sintaxis 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.