Puedo llegar tarde a la fiesta en 2016. Play 2 está fuera, y el JDK (sin mencionar el hardware) mejoró drásticamente. No estoy usando Play o Spring Boot, ya que mi plataforma no los necesita, solo generación de HTML/texto en tiempo de ejecución puro a partir de plantillas.
En primer lugar, cuando hablamos de plantillas de Groovy, hay más de una. Uso el Groovy SimpleTemplateEngine original para cualquier cosa, desde correos electrónicos hasta páginas web ricas, si la mayoría de las personas hoy en día prefieren el MarkupTemplateEngine "avanzado" con su sintaxis de constructor que no es HTML. No tomé esa ruta debido al soporte IDE (por ejemplo, UntelliJ) para archivos HTML JSPish con JavaScript, que capturan etiquetas sin abrir, llaves, etc. Además, ¿cómo incluiría JavaScript en la plantilla de estilo "generador" basada en llaves?
Cualquiera que elija, tanto SimpleTemplateEngine como MarkupTemplateEngine compilan estáticamente sus plantillas, aunque el documento de Groovy solo lo menciona para este último. ¿Por qué no generaría una clase para el primero? No los comparé uno contra el otro, pero esperaba que SimpleTemplateEngine fuera más rápido, ya que es ... bueno, más simple, no convierte ninguna sintaxis en concatenaciones de cadenas con ifs y loops intermedios.
Y de hecho es muy rápido. Estaba preocupado por invocarlo en un bucle. No hace ninguna diferencia. No hay sobrecarga, ya que la plantilla se compila una vez.
Utilizo varias plantillas pequeñas responsables de generar el marcado de control de formulario individual (HTML + JS) para generar un formulario compuesto, incluido en un contenedor de nivel superior, incluido en otro contenedor, y así sucesivamente, hasta que se forma toda la página . La descomposición de su vista de esa manera la hace, como ya ha adivinado, modular, encapsulada y "orientada a objetos", compuesta de muchos componentes MVC individuales que se complementan entre sí. Algo así como las buenas y antiguas etiquetas JSP personalizadas, solo evaluadas en tiempo de ejecución y compatibles con tecnologías como Spring Boot, si no puedes resistirte a cosas tan modernas como la promoción de currículums.
Una forma de prueba con 100 campos (todos los controles "inteligentes" complejos con gestión de estado encapsulado y comportamiento) se procesa en 150ms la primera vez, y luego 10-14ms después. En un depurador IDE en mi 4y.o. cuaderno. También verifiqué que es seguro para subprocesos, ya que Groovy nunca lo mencionó explícitamente. ¿Por qué no sería así si se compila en una clase Groovy sin estado como cualquier otra? Llame a createTemplate() una vez, almacene la plantilla en algún lugar, y úsela (llame a Template.make()) en su servlet u otro contexto concurrente. Obviamente, nunca tendré un formulario de 100 campos en una aplicación real. Cualquiera que lo haga, necesita reconsiderar su UX.
El rendimiento es bastante adecuado. Incluso aceptaría un segundo para renderizar una página de 100 campos. Piense en ello, no necesita el máximo rendimiento de nanotrading o rastreo de misiles nucleares en una aplicación web. Si lo hace, elija Jamon: http://www.jamon.org/Overview.html, que genera una clase Java, normalmente escribiría para concatenar cadenas. No lo probé, ya que no me gustan los pasos de compilación adicionales (ejecutados automáticamente por Maven, pero aún así). El código de bytes compilado de Groovy es lo suficientemente bueno para mí, en comparación con el Java compilado, sí, fuertemente tipado.La diferencia sería marginal a menos que esté haciendo algo complejo, que no debería dentro de una plantilla (ver a continuación). Jugar con variables Groovy tipadas contra def como se sugiere en este hilo, solo me salvó un par de milisegundos en esa ejecución de 100 plantillas.
Las plantillas no deben tener mucha lógica de procedimiento (variables internas, ifs y bucles) de todos modos, esa es la responsabilidad del controlador, no de la vista. Dicho esto, los ifs y los bucles son imprescindibles para un motor de plantillas. ¿Por qué uno usaría Manillar/Bigote, si él/ella simplemente puede llamar a String.replace()?
El resto de los motores de plantillas también es irrelevante. Ninguna concatenación de cadenas (por ejemplo, Velocity, o Freemarker) o tecnología basada en JS interpretada (por ejemplo, Jade) superarían alguna vez el enfoque de Jamon más directo en cuanto a rendimiento. Y al ser un programador de Java, desea utilizar su idioma/sintaxis favorita: ya sea directamente (Jamon) o en un 90% cerca de Java, Groovy es (al ser una Java conciso y centrada en scripting). No comentaría sobre Scala: el asunto de las preferencias. Aparte de su supuesta sintaxis "conciso" (menos y menos relevante con Java 8+) tiene un precio. Y solo importa para bucles complejos. No desea escribir toda su aplicación dentro de una plantilla, como ya he dicho. Un par de bucles y hasta diez declaraciones if max.
Y, como todos mencionaron, la sintaxis intuitiva y la facilidad de uso son la clave. Reducen drásticamente la cantidad de errores. Un buen servidor (adicional) cuesta $ 1000, mientras que los salarios de los desarrolladores: para arreglar todos los errores derivados de la complejidad de la optimización del rendimiento marginal, son 100 veces más altos.
Nota: las plantillas groovy se reemplazarán en Play 2.0 (no recuerdo ahora cuál es la sustitución) – ripper234
@ ripper234 Las plantillas se basarán en Scala: http://www.playframework.org/2.0 – romaintaz
hay una implementación de plantillas groovy alternativo: http://www.playframework.org/modules/fastergt - es más rápido y usa menos memoria, y es compatible con play 2.0, por lo que le permitirá reutilizar sus plantillas ... – opensas