Cómo elegir un motor de plantillas de front-end web (recomendado)

Esta publicación le brinda contenido sobre cómo elegir un motor de plantilla de interfaz de usuario web (recomendado).

El motor de plantillas se encarga de ensamblar datos y presentarlos en otra forma o apariencia. La página en el navegador es la representación final del motor de plantillas web.

Ya sea que utilices un motor de plantillas directamente o no, las plantillas web siempre han existido, tanto en el front-end como en el back-end, incluso antes de la creación formal del estándar HTML del lenguaje de marcado de hipertexto.

Motor de plantillas del lado del servidor

Hasta donde yo sé, el primer motor de plantillas web es PHP, que nació oficialmente en 1997 y funciona en el lado del servidor. Echemos un vistazo a la introducción oficial de PHP:

Los usuarios de HP generalmente creen que PHP en sí es el motor de plantillas PHP más natural y nativo, porque así es como debería ser.

No hay duda de que estos motores de plantillas del lado del servidor eventualmente generarán cadenas HTML (XML), y la lógica de procesamiento se implementa a través de la propia sintaxis del lenguaje anfitrión.

Todos comparten la misma idea: HTML es solo una cadena y el resultado final puede requerir una herramienta de validación de limpieza o reparación como Tidy.

Esto plantea la pregunta: ¿es necesario un segundo envoltorio para Smarty?

Motor de plantillas del lado del navegador

Hasta donde yo sé, el primer motor de plantillas de front-end es jCT, que está alojado en Google Code y nació en 2008. Utiliza JavaScript como idioma anfitrión. Se puede ejecutar en el navegador.

Busque motores de plantillas JavaScript en OSC hoy y obtendrá más de 100 resultados, estos son algunos de ellos:

Ligero: tpl.js, T.js

p>

Nivel consciente: arttemplate, mustache.js, doT.js, handlebars.js, pug

Basado en el árbol DOM: domTemplate, transparencia, placas

Basado en VDOM: htmltemplate-vdom, virtual-stache, html-patcher

Marcos populares: Vue.js, ReactJS, riot

Real-DOM: PowJS

Todos tienen una cosa en común: todos admiten la interpolación.

También hay una comparación de la popularidad del motor de plantillas, e incluso una votación por el mejor motor de plantillas de JavaScript y argumentos a favor y en contra.

Cómo elegir

Creo que cada motor y marco tiene sus ventajas, al menos en algún punto de su aplicación. Ahora para responder a la pregunta mencionada anteriormente: ¿Es necesario el sabelotodo? Mi respuesta es: sí. El motivo es muy sencillo, depende de quién lo utilice y de los antecedentes. Para aplicaciones donde el front-end y el back-end no están separados, o el personal de front-end no está lo suficientemente familiarizado con el lenguaje de back-end, o debido a responsabilidades laborales, es realista que el personal de front-end domine un sintaxis de plantilla más general (lenguaje). En su lugar, deje que PHPer lo haga ellos mismos. Usar Smarty es un desperdicio de habilidades.

Las siguientes son sugerencias generales para la selección del motor:

Preestablecido, elija un motor que pueda satisfacer sus necesidades de presentación de datos sin entrar en conflicto con las dependencias existentes. Si ya está muy familiarizado con uno en particular. motor y tienes la respuesta.

¿Es un requisito único del proyecto? Si es así, elija directamente el motor liviano con la menor complejidad de aprendizaje. ¿Se utiliza para el desarrollo de componentes?

¿El motor admite resultados precompilados para que no tengas que compilar sobre la marcha cada vez?

¿Quieres multiplataforma? Si hay soporte oficial, elija un motor similar a React-JSX o un motor VDOM puro.

Elija el motor que sea menos complejo de aprender o mantener; se sabe que los desarrolladores odian dedicar tiempo a depurar y escribir código.

Lo último que debe hacer es comparar el rendimiento, que es un trabajo muy delicado y es posible que las comparaciones de otras personas no necesariamente coincidan con su escenario de aplicación.

Creo que la comparación de estilos gramaticales debería debilitarse. Las preferencias no son comparables. Algunas gramáticas incluso tienen razones contextuales especiales.

¿Por qué poner la comparación de rendimiento al final?

El rendimiento sí importa, pero si no afecta el nivel de experiencia que tienes con tu aplicación, ignóralo. Es difícil simular de manera realista escenarios de aplicaciones y, a menudo, la única forma de realizar pruebas es realizar pruebas en escenarios reales, lo que no se puede lograr con las herramientas de prueba actuales.

Algunas de las preguntas anteriores ya tienen respuestas fijas, así que analicemos las demás: ¿Qué opinas sobre el desarrollo de componentes, el soporte de precompilación y la complejidad?

Desarrollo de componentes

El desarrollo de componentes ya no es una cuestión de elegir un motor de plantilla, sino una cuestión de elegir un ecosistema. Si su aplicación necesita completarse más rápido, el tiempo será la primera prioridad, así que elija un marco que sea popular y que proporcione suficientes componentes para su uso o consulta. Si su aplicación tiene un ecosistema independiente y necesita seleccionar tecnologías para el mantenimiento a largo plazo, continúe leyendo a continuación.

Precompilación

La precompilación debe tener:

El resultado de la compilación ya no requiere el proceso de compilación en el entorno de destino.

Depuración de los resultados de la compilación, lo que significa que los resultados de la compilación deben contener código ECMAScript nativo en lugar de descripciones de datos puros.

Como sabes, React-JSX admite la precompilación, oficialmente llamada React Without JSX, que significa siempre integrada.

Algunos motores basados ​​en cadenas también admiten la precompilación. Si necesita precompilación, es mejor abandonar un motor que todavía compila basándose en la concatenación de cadenas que no precompilar, porque eso es lo que hacía la gente antes de que HTML5 fuera ampliamente soportado.

Como mínimo, una compilación como React-JSX debería ser depurable. Nota: Vue.js admite múltiples motores de plantillas que pueden lograr la misma funcionalidad.

El código original de ReactJS utiliza tecnología de componentes web:

la clase HelloMessage extiende React! lt;x-search>{this.props.name}!createElement(

"x-search",

null,

this.props.name

),

"!"

);

}

} Un buen número de motores VDOM pueden compilar efectos similares, como htmltemplate-vdom.

Complejidad

Debido a las diferentes formas de pensar de los usuarios, es difícil juzgar la complejidad de cuál de los dos motores mediante un criterio único inferior. Por ejemplo, diferentes usuarios tienen sentimientos diferentes sobre las diferencias en el uso y los resultados precompilados de los motores anteriores, razón por la cual los diferentes motores tienen su legitimidad y valor.

Algunos usuarios creen que las plantillas de cadenas en este escenario de aplicación son suficientes para sus necesidades y son lo suficientemente livianas para usar.

Algunos usuarios piensan que el motor de plantillas de tecnología de empalme de cadenas no es lo suficientemente potente y no puede usarse con la suficiente frecuencia.

Algunos usuarios piensan que la programación orientada a objetos es lo suficientemente razonable, lógica y abstracta.

Algunos usuarios piensan que el HTML nativo se llama front-end.

Algunos usuarios piensan que VDOM es más adecuado.

Estos juicios se basan en sus propias razones y diferentes puntos de vista producirán diferentes estándares. Pero todavía podemos pensar en su complejidad desde una perspectiva sangrienta.

Las plantillas de clases de cadena son generalmente livianas y están más allá del alcance de esta sección. ¿Cuál es el criterio de calidad para juzgar la complejidad de las plantillas que no son cadenas? Creo que se puede considerar la complejidad del enlace de datos.

En este artículo, me refiero al enlace de datos no solo como interpolación, sino también como contexto y eventos, e incluso como todo el entorno de ejecución del host.

De hecho, se requiere al menos un motor de nivel VDOM para hacer esto, ya que los VDOM se asignan a nodos DOM reales.

Hay varios modos (combinaciones):

1. El parámetro de entrada es un objeto y la variable x en la plantilla es el atributo .x del objeto, por ejemplo: ejemplo-virtual-stache

2. Sintaxis o propiedades específicas, como: Vue.Net, Vue.Net, Vue.Net, Vue.Net, Vue.Net, Vue.Net, Vue.Net: Vue. Estos patrones son sólo cuestiones teóricas y normalmente son problemas que los diseñadores de motores de plantillas deben resolver.

Para los usuarios, es mejor simplemente hacer las siguientes preguntas:

1. ¿Puedo escribir el console.log(context) más simple directamente en la plantilla HTML para depurarlo?

2. ¿Es posible vincular o pasar diferentes parámetros de contexto en múltiples niveles del árbol DOM?

3. ¿Es posible acceder al Nodo generado hacia arriba en un árbol DOM multicapa?

El equipo de Template Engine le proporcionará la solución correcta, pero a menudo diferirá de la descripción literal del problema. Creo que esto es clave para juzgar su elección, qué tan consciente es del enfoque oficial correcto.

Incrustar DOM

Incrustar HTML

PowJS se implementa de esta manera:

Instrucciones que se deben implementar para implementar la plantilla

Precompilado para generar código ECMAScript nativo

La sintaxis de la plantilla está estructurada de la misma manera que se escriben las funciones ECMAScript

En última instancia, escribir plantillas PowJS es como escribir funciones ECMAScript.

Escribir en el índice de GoHub

La mayoría de los motores de plantillas implementan las directivas if y each. Las plantillas PowJS anteriores también incluyen:

Los objetos globales son, sel

Plantillas (funciones) denominadas repositorio, lista, etc.

Datos de parámetro formal de entrada de plantilla (función)

Variable local personalizada ctx

Plantilla subordinada (función) parámetro formal derivado data.sha->sha

Recorrer los valores hasta la derivación de parámetros formales de la plantilla subordinada (ctx.Package,val-pkg)->pkg, (data. content,val-rep)->rep

Operación del nodo DOM esto renovar, this.appendTo, esta operación se representa directamente en el árbol DOM de la página

Interrupción del control del proceso

Pseudonodo if="':';", la representación no generará una p. nodo en absoluto.

Este es un pseudonodo, equivalente al símbolo de código de bloque "{}"

La clave es que toda la estructura de la plantilla, la semántica de las instrucciones y la función ECMAScript son exactamente iguales:

Sin enlace de datos, estás escribiendo una función ECMAScript, solo pasa parámetros, ¿qué más necesitas vincular?

No hay enlace de eventos, cada nodo es real, solo escribe addEventListener

Para depurar, simplemente busque do o if o let e inserte _=console.log(x). Las expresiones de coma se pueden insertar sin problemas en casi cualquier declaración nativa

Toda la lógica empresarial la escribe el usuario y PowJS es solo responsable de unirla en una sola función