2012-02-20 9 views
7

Me gustaría saber qué enfoque es más rápido, usando PHP puro en los archivos HTML o usando una plantilla de motores como Smarty, Twig, ... Lo que me gustaría particularmente know is next: que se analiza más rápido, ¿es el caché Smarty, por ejemplo, más rápido que el uso puro de PHP? ¿Cuál de los motores de plantillas es el más rápido? Estoy a punto de reescribir una aplicación simple donde la velocidad está en primer lugar.Puras vistas de PHP/HTML VS vistas de motores de plantilla

Respuesta

20

"Depende" es la respuesta a todas sus preguntas.

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

Si se trata de plantillas puramente dinámicas (es decir, plantilla evaluada en cada solicitud) PHP superará cualquier motor de plantilla. Esto es un nobrainer, realmente. Si está teniendo en cuenta el almacenamiento en caché, un motor de plantillas como Smarty puede ayudar. Sin embargo, el almacenamiento en caché no es nada que no puedas implementar tú mismo en PHP. Con Smarty se acaba de hacer para usted (y en un nivel mucho más sofisticado de lo que posiblemente sea).

Si está utilizando un marco, digamos Symfony, podría ser conveniente usar Twig, ya que Twig y Symfony están estrechamente integrados. Claro que puedes usar Smarty o PHP simple. La pregunta aquí es: ¿es practicable?

El almacenamiento en memoria caché tiene sentido cuando se crean sitios a partir de fuentes de datos como una base de datos o API remotas. Lo que realmente está ahorrando (en un sentido de reducción) aquí son las llamadas a la base de datos, los cálculos intensivos, etc. Verifique si tiene funciones que requieren mucho tiempo para ejecutar su sitio. Si es así, usa el almacenamiento en caché (si puedes).

Conociendo las ventajas de desarrollo/mantenimiento/conveniencia/rendimiento, yo (siempre) recomendaría usar un motor de plantillas. Siendo un desarrollador de Smarty, por supuesto, sugiero usar Smarty. Eso a menos que estés usando Symfony, entonces es mejor que estés con Twig. O algún otro marco con algún otro motor de plantillas.

Ignore las publicaciones como Smarty vs. Twig, ya que solo comparan una vista muy limitada de los motores. No confíe en los puntos de referencia que no haya 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 (que es el momento en que se ejecuta una plantilla) que Smarty hace en el tiempo de compilación (es el momento en que se prepara una plantilla para la ejecución). Twig no está realmente cabreando 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 "convenienve" (Accediendo a matrices y objetos con la misma notación, por ejemplo).

4

Volveré a ocuparme de esto ya que las cosas han cambiado significativamente y faltan pruebas en la respuesta anterior.

Sin entrar en profundidad en por qué los frameworks utilizan motores de plantillas en PHP que la mayoría lo hace. Por alguna razón, hay un esfuerzo constante para "arreglar" PHP con otra capa de abstracción. Siempre con afirmaciones de simplicidad sin pérdida de versatilidad o rendimiento.

Independientemente, el uso de PHP sigue siendo la forma más rápida y versátil de creación de plantillas. PHP en su earliest incarnations se parecía mucho a un lenguaje de plantillas. Pero echemos un vistazo a los avances en PHP y colóquelos uno al lado del otro con the after layers.

Twig y algunos otros reclaman el almacenamiento en caché de algo que siempre fue un complemento en las versiones anteriores de PHP.El almacenamiento en caché ahora es default part of PHP5.5+ (Opcache) y, por lo tanto, usar PHP como lenguaje de plantilla proporcionará más mejoras de rendimiento.

Twig y otros afirman una sintaxis simple para los diseñadores. Al comparar el syntax of a template engine, verá que la lógica es similar, con el único beneficio de utilizar un sistema de plantillas 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 usaban PHP como sus motores de plantilla. Entonces, el viejo argumento de usar un motor de plantillas para asegurar y simplificar el uso de PHP mientras se diseña un sitio web no es realmente válido en la web de hoy. Mientras que Drupal 8 se está moviendo hacia Twig principalmente porque twig es parte de Symfony Framework (volviendo a por qué los frameworks usan motores de plantillas). Wordpress, por otro lado, todavía usa PHP. Como Wordpress está creciendo a pasos agigantados con los diseñadores web que usan PHP para ayudar a que esto suceda. Drupals Community también se ha dividido en parte por las decisiones de usar Twig y Symfony.

Parecería que usar PHP es la mejor opción en términos de rendimiento, pero también la preferencia de los diseñadores y 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 el uso de cualquier elemento que no sea PHP como motor de plantillas en la web de hoy cubre algunas debilidades inherentes en el marco subyacente o la arquitectura de la aplicación web. Esa debilidad es su complexities and complications que no se puede explicar fácilmente en el nivel de diseñador o de más.

Si está escribiendo una aplicación liviana que tiene que ser pequeña. Manténgalo pequeño y tenga un rendimiento óptimo mediante el uso de PHP y deje los otros motores en grupos y proyectos de nivel "empresarial"

5

De manera simple y pura, creo que la única ventaja es la portabilidad. Puede volver a utilizar plantillas o vistas desde un motor de plantillas en otra aplicación de back-end. Digamos que está moviendo su aplicación de PHP a Java, no necesita refactorizar las plantillas.

De lo contrario, agrega complejidad, agrega otra capa de ejecución (más tiempo), más requisitos para mantener la aplicación (necesita personas que conozcan ese motor de plantillas), y así sucesivamente. PHP en sí mismo es el mejor y más destacado motor de plantillas que obtendrás, probablemente el más rápido, y también puedes usar el almacenamiento en caché, con la ventaja de controlar el caché desde la aplicación back-end, y no desde la vista.

7

Vamos a rasgar el tropos relacionados con este tema aparte:

1. Mantener la lógica de la presentación - No ponga 'código' en tu HTML

Cualquier persona que dice esto y luego le dice que vaya con plantillas es contradictoria:

  • PHP es un interpretarse idioma - se convierte en código C en la ejecución.
  • El 'sintaxis' de plantillas es interpretarse en PHP

Deben dejar de mentir a sí mismos.Su 'sintaxis de plantillas' es un lenguaje de programación construido encima de otra, que a su vez se construye en la parte superior todavía otra idioma - Eso es ineficaz, redundante y raro.

Por otra parte, no veo cómo la existencia misma de las variables de cada motor de plantillas que haya existido depende de la lógica no se consideran - Su existencia, el contenido y la aplicación depende de una lógica backend .

Y qué de esos sistemas de plantillas con si/ demás declaraciones y de bucles? Esa es la verdadera esencia de la lógica: los mismos conceptos que utilizan la mayoría de los lenguajes de programación . Requieren variable datos que solo pueden generarse o existir mediante algún tipo de cálculo.

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


2,1 Es más seguro ...

Por lo tanto, no confianza tu chico HTML?

caso: Usted piensa que su chico HTML/CSS es estúpida y accidentalmente imprimir la contraseña de la base

Si eso es una noticia así, Tengo para usted - Su entorno ya no es seguro si los datos sensibles pueden ser accedido/modificado desde cualquier lugar dentro del programa.

caso: Usted piensa que su chico HTML imprimirá constantes servidor aleatorio - es peligroso permitir que él, como individuo, para trabajar con la lógica del servidor

veo - Está bien estúpida, u odia su trabajo y quiere ser despedido y por lo tanto hará algo tonto como imprimir variables de sesión. Bien, pero para eso diré ...

... ¿Por qué diablos es esto no con calificación de? Incluso si no tuviera acceso a la lógica del servidor directo, sino a un sistema de plantillas sofisticado, igualmente podría difundir su estupidez/odio simplemente porque tiene la última palabra en la producción. O bien, incluso podría estar en connivencia con otro programador (si corresponde) y aún acceder a las constantes del servidor y co.

-

2.2.1 motores de plantillas Buenas desinfectar automáticamente la salida, o permitir que la plantilla-hombre para hacerlo por sí mismo - él sabe mejor cuando los datos deben ser desinfectados

Usted Dummy .

¿No sabe cuándo se debe desinfectar la salida? Usted no podría hacer eso usted mismo?

Aún así, tal vez usted es solo el código mono y el tipo HTML es un especialista en inyección de HTML de seguridad web, y él debe ser el único producto sanitario. En ese caso, darle acceso a PHP también le permite usar los gustos de htmlspecialchars() en lugar de lo que la plantilla le dé para hacer lo mismo.

Con respecto al escape automático, siempre que sea con seguridad transfiriendo el contenido, puede implementar una función tan simple dentro del código que está haciendo.

-

2,2 ... y puedo controlar qué datos se está trabajando con

Piense en las clases, funciones, etc - usted lanza en los datos, trabajan con eso, entonces obtienes un resultado. Por lo general, no se ocupan de datos externos a menos que se los entreguen (Hacer lo contrario no es claro, es una práctica peligrosa y mala, algunas constantes aparte). A través de estos mismos métodos, puede transmitir exactamente lo que necesita a su producción de una manera eficiente, clara e ilimitada.

-

Dicho todo esto, parece que la razón por la que cree su motor de plantillas es más segura que el código normal es porque te falta en varias áreas de la seguridad en general :

  • Usted (o quien sea) no contenido de revisión por pares: permite individuos para producir contenido.
  • No están aplicando prácticas de programación adecuadas o seguras, y parecen no darse cuenta de que puede controlar lo que pasa a lo largo del punto A a B.

3. sintaxis de PHP es demasiado dura/difícil de enseñar al pueblo de estilo

La verdad es que no es más complicado es que la pseudo-sintaxis creada por los sistemas de plantilla tales como Smarty, entonces si esto es un problema, el contenido dinámico no es para ti.

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 yo diría que no es, usted es libre de elegir lo que desea ! Elija lo que mejor se adapte a sus necesidades. Por lo general, son gratuitos, no son difíciles de integrar y vienen con muchas funciones listas para usar.



estoy bajo la impresión de que la mayoría de la gente opta por plantillas, simplemente porque se ve 'más limpio' dentro del archivo - Aman pensando que el archivo TPL es algo especial que crearon, les gusta el forma en que se ve la sintaxis; Como por arte de magia, la variable es 'llamada' por el pequeño símbolo @ o # y salta de su lógica a la salida.

Parece un truco - La bella hechicera (AKA El motor de plantillas) te atrae con su belleza. A pesar de que es atractivo a la vista, ella es realmente una sangre de demonio que aspira y extrae su alma (recursos del servidor) a cambio de ojos dulces que nadie más ve (Sus usuarios preferirían tener un sitio web más rápido y características más financiado por el $$$ va a guardar en la energía/servidor alquilar)

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


voy a admitir, sólo hay un caso que puedo pensar en que las plantillas tienen ningún terreno en PHP - Portabilidad a otras aplicaciones. La respuesta de appartisan aborda eso. Aún así, no es difícil reemplazar <?= $var ?> con {{@var}} - Eso es un trabajo para un sistema de plantillas.

+0

Permítanos [continuar esta discusión en el chat] (http://chat.stackoverflow.com/rooms/154562/discussion-between-vaxquis-and-super-cat). – vaxquis

0

Tengo un problema con el argumento de que la lógica y la visualización de datos se deben separar tanto como sea posible. Descubrí que la validación y visualización de datos en realidad requiere mucha lógica en los formularios. La información sobre el tipo de datos, el rango de números y la relación entre diferentes datos requiere mucho código. La verdadera pregunta es si debemos usar un lenguaje de plantilla en el lado del servidor o Javascript en el lado del cliente. Al utilizar Ajax y el código del lado del cliente para la visualización y validación de datos, termino teniendo muy poco código de plantilla. El mayor problema con los motores de plantillas es la introducción de nuevas reglas y sintaxis de códigos. Veo el futuro con PHP, Jquery y Ajax, y los motores de plantillas pierden su atractivo.

Cuestiones relacionadas