¿Por qué necesitamos lenguajes de plantilla HTML? ¿Insertar HTML simple (con elementos de script para lógica) no es suficiente?

Imagine este escenario más simple: tiene un sitio web de juegos con una sección del “Salón de la fama” donde se presentan los 10 mejores jugadores. Ahora para mostrar esa sección, crea una tabla con HTML donde están los nombres / apodos / puntaje de los ganadores. Los ganadores están cambiando, por lo que la lista de los 10 principales de hoy puede diferir de la lista de mañana. Si fuera a crear esa página con HTML simple, debe editarla cada vez y completar los valores.

Una forma mejor y ampliamente adoptada de hacerlo es presentar toda la página construida con HTML simple y usar plantillas donde se agregan estos reproductores. Entonces en nuestro caso se vería así:

PARA CADA jugador genera una columna separada y completa los detalles.

La línea media con el motor de plantillas se vería así (la sintaxis varía):

{{INSERT_TOP_PLAYERS}}

El motor de plantillas tomará todas esas ocurrencias y las reemplazará con las contrapartes correctas generadas por el sistema de fondo.

Qué hace el backend:

Una vez que se cumple una ocurrencia de {{INSERT_TOP_PLAYERS}}, el sistema toma a todos los mejores jugadores de la base de datos, crea la columna y la reemplaza por el campo {{INSERT_TOP_PLAYERS}}. Aquí hay un ejemplo de dicha columna:

Nombre del jugador

Nombre del jugador

Puntuación del jugador

Los motores de plantillas proporcionan muchas variaciones complejas, lo anterior fue el escenario más simple. Y hace que el código sea mucho más agradable, conciso y legible y más escalable que el uso directo del lenguaje sciprting.

Respuesta corta: no, hay otras soluciones, pero esta funciona bien y es conveniente para todos los involucrados. Uno largo: se introdujeron lenguajes de plantilla para separar la lógica y la presentación de la aplicación. Esto hace que la aplicación sea más modular, más fácil de entender y permite que diferentes personas trabajen en diferentes partes. La presentación necesita acceso a los datos generados por la lógica. Ahora, podría escribir estos datos en html simple y usar js para mostrarlos, pero:
1) el desarrollador front-end definitivamente querrá definir cómo se ve este html. Por lo tanto, querrá ser el que convierta los datos en html, y si lo hace, también podría definir cómo se muestran.
2) En algunos casos es más eficiente o confiable generar htmlon final del lado del servidor en lugar del lado del cliente.
3) Es obvio que esta canalización (datos -> html simple -> html atractivo) no es muy eficiente e implica conversiones innecesarias en todos los lados. Puede o no ser significativo, dependiendo del caso de uso.

Una forma alternativa de hacerlo es hacer que js solicite datos sin formato y sin formato a través de llamadas ajax y realice todo el procesamiento en el navegador, eso también funcionará. Hasta ahora, prefiero el enfoque de plantilla, principalmente porque los lenguajes de plantilla y todas las herramientas y bibliotecas relacionadas son mucho mejores en el lado del backend que en js.

La codificación rígida cada vez que hay un cambio en su sitio web es repetitiva y aburrida, para eso están las computadoras.

¡Levon Manucharyan lo explicó perfectamente!