Vistas de vistas PHP/HTML puras vs plantillas de vistas de motores

https://stackoverflow.com/questions/9363215

28-10-2019
|

Pregunta

Me gustaría saber qué enfoque es más rápido, usando el PHP puro en los archivos HTML o usando un motores de plantilla como Smarty, Twig, ... lo que me gustaría saber que es a continuación: lo que se analiza más rápido, es el Smarty Cachey Cachey por ejemplo, más rápido que usar PHP puro? ¿Cuál de los motores de plantilla es el más rápido? Estoy a punto de reescribir una aplicación simple donde la velocidad está en primer lugar.

Solución

"Depende" es la respuesta a todas sus preguntas.

¿Qué es "más rápido"? ¿Tiempo de ejecución? ¿Tiempo de desarrollo? ¿Mantenimiento? ¿Sobrecarga de memoria? Una mezcla de ellos? Un motor de plantilla generalmente se negocia en cierto rendimiento (velocidad, memoria) para un mejor desarrollo y mantenimiento.

Si está hablando de plantillas puramente dinámicas (significado: plantilla evaluada en cada solicitud) PHP superará a cualquier motor de plantilla. Este es un nobrainer, de verdad. Si tiene en cuenta el almacenamiento en caché, un motor de plantilla como Smarty puede ayudar. Sin embargo, el almacenamiento en caché no es nada que no pueda implementarlo en PHP simple. Con Smarty se ha hecho por ti (y en un nivel mucho más sofisticado de lo que posiblemente lo harías).

Si está utilizando un marco, digamos Symfony, podría ser aconsejable usar Twig, ya que Twig y Symfony están estrechamente integradas. Seguro que puede usar Smarty o PHP sencillo. La pregunta aquí es: ¿es practicable?

El almacenamiento en caché tiene sentido al construir sitios de datos de datos como una base de datos o API remotas. Lo que realmente está ahorrando (en el sentido de reducir) aquí son llamadas de base de datos, cálculos intensivos, etc. Verifique si tiene alguna funciones de tiempo que se ejecute para construir su sitio. Si es así, use el almacenamiento en caché (si puede).

Conociendo el desarrollo/mantenimiento/conveniencia/compensaciones de rendimiento, recomendaría (siempre) usar un motor de plantilla. Siendo un desarrollador de Smarty, por supuesto, sugeriré usar Smarty. Eso es a menos que esté usando Symfony, entonces podría ser mejor con Twig. O algún otro marco con otro motor de plantilla.

Por favor ignore publicaciones como Smarty vs. Twig, ya que solo comparan una visión muy limitada de los motores. No confíe en los puntos de referencia que no has falsificado.

En general, sin embargo, Smarty 3.1 es un poco más rápido que Twig. Twig está haciendo muchas cosas en tiempo de ejecución (siendo el momento en que se ejecuta una plantilla) que Smarty hace en el tiempo de compilación (siendo el momento en que una plantilla está preparada para la ejecución). Twig no está realmente enojando la velocidad aquí. Twig necesita hacer ciertas cosas en tiempo de ejecución por diseño. Cambiaron un poco de rendimiento por un poco de "conveniencia" (acceder a matrices y objetos con la misma notación, por ejemplo).

Otros consejos

Rompamos los tropos relacionados con este tema:

1. Mantenga la lógica fuera de la presentación: no ponga 'código' en su HTML

Cualquiera que diga esto y luego le diga que vaya con plantillas es contradictorio:

PHP es un interpretado Idioma: se convierte en código C en la ejecución.
La plantilla 'sintaxis' es interpretado en PHP

Deben dejar de mentirse a sí mismos. Su 'sintaxis de plantilla' es Un lenguaje de programación construido sobre otro, que a su vez se basa en la parte superior todavía otro lenguaje: eso es ineficiente, redundante y extraño.

Además, no veo cómo la existencia misma del variables Cada motor de plantilla que alguna vez depende no se considera lógica: su existencia, contenido e implementación dependen de un lógico backend.

Y qué hay de esos sistemas de plantilla con si/más declaraciones y por bucles? Esa es la esencia misma de la lógica, los mismos conceptos que la mayoría programación Los idiomas utilizan. Ellos requieren variable datos que solo se pueden generar o existir a través de alguna forma de cálculo.

No puede servir contenido dinámico sin mezclar la presentación con lógica. Es imposible.

2.1 Es más seguro...

Entonces, no confianza ¿Tu chico HTML?

Caso: Crees que tu tipo HTML/CSS es estúpido e imprimirá accidentalmente la contraseña de la base de datos

Si es así, tengo noticias para usted: su entorno ya no es seguro si se pueden acceder/modificar datos confidenciales desde cualquier lugar dentro del programa.

Caso: Crees que tu tipo HTML imprimirá constantes de servidor aleatorias: es peligroso permitirle, como individuo, trabajar con la lógica del servidor

Ya veo: es estúpido o odia su trabajo y quiere ser despedido y, por lo tanto, hará algo tonto como las variables de la sesión de impresión. Bien, pero a eso diré ...

... ¿Por qué diablos es esto no? revisado por pares? Incluso si no tuviera acceso a la lógica directa del servidor, sino a un sistema de plantilla elegante, aún podría difundir su estupidez/odio simplemente porque tiene la última palabra sobre la producción. O bien, incluso podría estar en cahohots con otro programador (si lo hay) y aún acceder a las constantes de servidor y compañía.

2.2.1 Buenos motores de plantilla desinfectar automáticamente la salida, o permitir que la plantilla -Guy lo haga él mismo: él sabe mejor cuando los datos deben desinfectarse

Tu muñeco.

¿No sabes cuándo se debe desinfectar la salida? No pudiste hacer eso tú mismo ...?

Aun así, tal vez solo eres el mono del código y el tipo HTML es un especialista en inyección HTML de seguridad web, y él Debe ser el que desinfecta la salida. En ese caso, darle acceso a PHP también le permite usar los gustos de htmlspecialchars() En lugar de lo que sea que la plantilla le dé lo mismo.

Con respecto a la escapada automática, siempre que esté sin peligro Al pasar contenido, puede implementar una característica tan simple dentro del código que está haciendo.

2.2 ... y puedo controlar con qué datos se están trabajando

Piense en clases, funciones, etc.: usted arroja datos, trabajan con él, luego obtiene un resultado. Por lo general, no tratan con datos externos a menos que se les entregue (hacer lo contrario no es claro, peligroso y mal de práctica, aparte de algunas constantes). A través de estos mismos métodos, puede transmitir precisamente lo que necesita para su salida en una mansión eficiente, clara e ilimitada.

Todo lo dicho, parece que la razón por la que pensar Su motor de plantilla es más seguro que el código simple es porque le falta en varias áreas de general la seguridad:

Usted (o quien sea) no revise el contenido: usted permite individuos para salir de contenido.
No está implementando prácticas de programación adecuadas o seguras, y parece no darse cuenta de que pueden controlar lo que se pasa desde el punto A a B.

3. La sintaxis de PHP es demasiado difícil/difícil de enseñar a la gente del estilo

La verdad es que no es más complicado que el psuedo-syntax creado por sistemas de plantilla como Smarty, por lo que si esto es un problema, el contenido dinámico no es para usted.

Lo siguiente está en PHP 'sintaxis corta', ¿es demasiado difícil?

<div class='username'><?= $username ?></div>

4. Es demasiado trabajo para desarrollar mi propia solución

Aunque diría que no lo es, ¡eres libre de elegir lo que quieras! Elija lo que mejor se adapte a sus necesidades. Por lo general, son gratuitos, no son difíciles de integrar, y vienen con muchas características de la caja.

Tengo la impresión de que la mayoría de las personas optan por la plantilla simplemente porque se ve 'más ordenada dentro del archivo: les encanta pensar que el archivo TPL es algo especial que crearon, les gusta la forma en que se ve la sintaxis; Como por alguna magia, la variable es 'llamada' por la pequeña @ o # símbolo y salto de su lógica a la salida.

Parece un truco: la hermosa hechicera (También conocido como el motor de plantilla) te atrae con su belleza. Aunque está apelando a la vista, es De Verdad un demonio chupando sangre y extrae tu alma (Recursos del servidor) a cambio de dulces oculares que nadie más ve (sus usuarios preferirían tener un sitio web más rápido y Más funciones financiadas por el $$$ que está ahorrando en el alquiler de potencia/servidor)

<title>{{@title}}</title>
Vs
<title><?= $title ?></title>

Admito que solo hay un caso en el que puedo pensar en el que las plantillas tienen algún terreno sobre PHP - portabilidad a otras aplicaciones. La respuesta del apartidista aborda eso. Aun así, no es difícil de reemplazar <?= $var ?> con {{@var}} - Ese es Un trabajo para un sistema de plantilla.

Simple y puramente opinión, creo que la única ventaja es la portabilidad. Puede reutilizar plantillas o vistas desde un motor de plantilla en otra aplicación de backend. Digamos que está moviendo su solicitud de PHP a Java, no necesita refactorizar las plantillas.

De lo contrario, está agregando complejidad, agregando otra capa de ejecución (más tiempo), más requisitos para mantener la aplicación (necesita personas que conozcan ese motor de plantilla), etc. PHP en sí es el mejor y más destacado motor de plantilla que obtendrá, probablemente el más rápido, y también puede hacer almacenamiento en caché, con la ventaja de controlar el caché desde la aplicación de backend, y no desde la vista.

Tomaré esto nuevamente ya que las cosas han cambiado significativamente y faltan algunas pruebas de la respuesta anterior.

Sin profundizar en por qué los marcos usan motores de plantilla sobre PHP, lo que la mayoría hace. Por alguna razón, hay un esfuerzo constante para "arreglar" PHP con otra capa de abstracción. Siempre con reclamos de simplicidad sin pérdida de versatilidad o rendimiento.

De todos modos, el uso de PHP sigue siendo la forma más rápida y versátil de plantillas. Php en Its es encarnaciones más tempranas se parecía mucho a un lenguaje de plantilla. Pero echemos un vistazo a los avances en PHP y colóquelos junto con las capas posteriores.

Twig y otros afirman almacenar en caché algo que siempre fue un complemento en versiones anteriores de PHP. El almacenamiento en caché ahora es un parte predeterminada de Php5.5+ (Opcache) y, por lo tanto, usar PHP como lenguaje de plantilla dará más mejoras de rendimiento.

Twig y otros reclaman una sintaxis simple para los diseñadores. Al comparar el Sintaxis de un motor de plantilla Verá que la lógica es similar con el único beneficio de usar un sistema de plantilla como Twig que es otra capa de separación de seguridad entre el diseñador y el código del sistema subyacente.

Dos CMS WordPress y Drupal muy populares usaron PHP como sus motores de plantilla. Por lo tanto, el antiguo argumento de usar un motor de plantilla para asegurar y simplificar el uso de PHP mientras diseña un sitio web no es realmente válido en la web de hoy. Mientras que Drupal 8 está pasando a la ramita principalmente porque Twig es parte del marco de Symfony (volviendo a por qué los marcos usan motores de plantilla). WordPress, por otro lado, sigue usando PHP. A medida que WordPress está creciendo a pasos agigantados con diseñadores web que usan PHP para ayudar a que esto suceda. La comunidad de Drupals también se ha dividido en parte por decisiones de usar Twig and Symfony.

Por lo tanto, parece que el uso de PHP es la mejor opción en términos de rendimiento, pero también la preferencia por los titulares y los diseñadores en el futuro. Al menos toda evidencia conduce a esta conclusión.

Dicho esto, aquí está mi opinión sin fundamento. Creo que usar algo más que PHP como motor de plantilla en la web actual cubre algunas debilidades inherentes en el marco subyacente o la arquitectura de aplicaciones web. Esa debilidad es su complejidades y complicaciones Eso no puede explicarse fácilmente a nivel de diseñador o Themer.

Si está escribiendo una aplicación liviana que debe ser pequeña. Manténgalo pequeño y funcione de manera óptima utilizando PHP y deje los otros motores a grupos y proyectos de nivel "empresarial"

Tengo un problema con el argumento de que la lógica y la visualización de datos deben separarse tanto como sea posible. Encontré que la validación y la pantalla de datos en realidad requieren mucha lógica en los formularios. La información sobre el tipo de datos, el rango de números, la relación entre diferentes datos requiere mucho código. La verdadera pregunta es si usamos un lenguaje de plantilla en el lado del servidor o JavaScript en el lado del cliente. Al usar AJAX y el código del lado del cliente para la visualización de datos y la validación, termino teniendo muy poco código de plantilla. El mayor problema con los motores de plantilla es la introducción de nuevas reglas de código y sintaxis. Veo el futuro con los motores PHP, JQuery y Ajax y plantilla que pierden su atractivo.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow