5 razones para no usar Smarty (o similares)

Ejemplo de uso de SmartyEn la mayoría de los casos, Smarty no es la solución idónea para separar la lógica de las vistas, aunque hay que admitir que la versión 3 está siendo un salto de calidad impresionante. No obstante, estas son las cinco principales razones que he encontrado para no incluirlo más en mis proyectos:

  1. PHP es un lenguaje con sintaxis embebida, es decir, es de por sí un sistema de plantillas. Para mayor claridad puedes utilizar la tag de apertura corta (<?en lugar de<?php) y el operador de impresión (<?=$nombre ?> en lugar de <?php echo $nombre ?>). Además, Smarty no añade funcionalidad.
  2. Con Smarty debes aprender una nueva sintaxis para imprimir variables, hacer bucles, etc.
  3. En aplicaciones complejas tendrás que crear un montón de plug-ins para cargar widgets u otros fragmentos de código para las vistas que quieras reutilizar. O bien utilizar cada dos por tres la tag {php}.
  4. Smarty es difícil de integrar en gestores de contenido, frameworks y editores de código.
  5. Smarty reduce el rendimiento de tus aplicaciones web ya que debe parsear y convertir a PHP las plantillas. Incluso con caché el rendimiento se ve afectado (más accesos a disco).

Ya habíamos hablado de este tema en Plantillas PHP: cuestión de rendimiento, proponiendo el funcionamiento básico de un motor de plantillas basado en PHP puro.

ACTUALIZACIÓN (23 de noviembre de 2009):

Algunos expertos han escrito artículos en profundidad sobre este tema, por ejemplo “Template Engines” de Brian Lozer.

Con respecto a las alternativas, Savant y PHPTemplate (creado para Drupal) son buenas opciones. Además, los principales frameworks (CakePHP, etc) y gestores de contenido (Joomla!, WordPress) suelen incluir sus propios motores de plantillas en PHP.

«In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code.»

ACTUALIZACIÓN (31 de enero de 2013):

En este artículo no defiendo que los sistemas de plantillas sean malos siempre. No son ni malos por naturaleza, y hay muchos tipos de proyectos en los que tiene sentido usarlos. Personalmente no los he necesitado nunca, aunque si tengo que elegir uno elijo Twig, sin duda.

Por

30 comentarios

    • Estoy de acuerdo con Enrique esto ha llevado a muy malas practicas el hecho de querer ahorrar unos cuantos caracteres en vuestro código, lo recomendable cuando empezamos es escribir completo.

  1. Gracias por tu comentario y tu visita, Enrique ;-)

    Estoy de acuerdo, las etiquetas cortas se deben utilizar sólo si el beneficio es mayor a los riesgos (como todo en esta vida). Personalmente nunca las uso pero hay que reconocer que pueden mejorar la legibilidad de las plantillas.

    De todos modos, lo de las short tags es discutible, pero que PHP sea un lenguaje embebido es así y no hay discusión posible… en todo caso remitirse a Rasmus Lerdorf :-P

  2. Plenamente en desacuerdo con el punto 5, tenemos (casi) Smarty 3 con una mejora de la velocidad que supera a cualquiera de las versiones anteriores mereciría la pena realizar una comparativa de Smarty con el resto de opciones.

  3. No digo que Smarty sea una mala idea, digo que PHP puro es mejor ;-P

    Y el rendimiento no es un punto crítico, ya que la caché está ahí. No obstante, me juego lo que quieras a que por muy buen rendimiento que tenga Smarty parsear y compilar una plantilla es más rápido que compilarla sólamente. O, si se aplica la caché, recuperar de disco dos scripts (la plantilla y el que lo carga, sin contar las librerías de Smarty) es más lento que recuperar uno sólo (la plantilla en PHP puro).

    • Como te lo mencioné anteriormente, estoy de acuerdo contigo,
      El usar PHP puro es mucho mejor, ya que para gestionar mejor las plantillas usaríamos los includes() que es lo que hace Smarty.

  4. Hola muy bueno el articulo y la pequeña discucion de si usar o no un sistema de plantillas.

    Yo solía programar mis aplicaciones siempre embebiendo el php con html, un tiempo me toco trabajar mucho con los famosos foros phpBB, lo primerito que llamo mi atención fue ver como tenían separado el código php de html, ellos utilizan su propia class de plantillas, pero la verdad fue algo que cambio la forma de programar mis aplicaciones.

    Como dices Isra no es malo utilizar Smarty o cualquier otro sistema de plantillas, yo pienso que aquí seria a criterio de cada quien.

    Por ejemplo Smarty es muy robusto y teda una infinidad de posibilidades, pero igual solo lo recomendaría si es para proyectos muy grandes, yo intente utilizarlo pero la verdad fue una pérdida de tiempo en tener que aprender su sintaxis y otras cosas y realmente iba más allá de lo que yo necesitaba, más claridad en el código de mis aplicaciones…

    Pero en mi afán de aun querer separar mí código php de html me llevo a seguir buscando una clase para este fin, después de probar varias, me encontré con una que hasta ahora me ha resultado bastante bien y que me gustaría compartir con todos ustedes para que meden su opinión al respecto y por si a alguien más le interesa:

    Se llama Template Power la url es: http://templatepower.codocad.com/

    Para lo que realmente necesito está bastante bien separo el código php del html.

    Una de las tantas ventajas de utilizar un sistema de plantillas es que cuando se trabaja en equipo unos se dedican al código php otros al html y css y de esta forma es más sencillo porque ya solo nosotros vamos llenando los html’s y viceversa los de diseño ya solo ven etiquetas html y no preguntan en donde pueden poner un <div> o que ya se volaron un pedazo de código ejejeje…

    Esta es mi experiencia que he tenido con un sistema de plantillas.-

    Saludos.-

  5. ¡Gracias por compartir tu experiencia, Karl! Estamos todos de acuerdo en que separar código de plantillas es beneficioso y casi necesario.

    Por su parte, TemplatePower no me convence demasiado. Si has conseguido acceder a tus clases y objetos dentro de ellas bien, pero si no le veo un gran handicap a este sistema.

  6. ¿Has probado Twig (http://www.twig-project.com)? Es un proyecto del creador de symfony.

    Sin duda yo también soy partidario de usar PHP (al estilo Zend_View) antes que sistemas de plantillas siempre que se pueda. Pero eso no quita que estos sistemas tengan su sitio.
    Por ejemplo, en un proyecto donde trabajan un programador PHP y un maquetador XHTML+CSS donde hay frecuentes cambios y actualizaciones. Para el maquetador es mucho más sencillo trabajar con plantillas como las de Twig o Smarty que con plantillas con PHP puro.
    O en el caso de una aplicación que te permite modificar el aspecto de tu web sin darte la posibilidad (por motivos de seguridad) de usar el código PHP (es lo que yo hago con tiendy.com).

    Yo creo que la cuestión no es qué es mejor, así a secas, sino "qué es mejor para mi proyecto concreto" :)

    Felicidades por el blog.

  7. Gracias por la información, Manuel. No conocía Twig y el nombre de Fabien Potencier me genera bastante confianza. Tiene muy buena pinta, tanta que creo que le hace competencia directa a Smarty. No obstante sigo sin estar convencido de su idoneidad frente a sistemas de plantillas basados en PHP.

    Lo que sí es cierto es que cada proyecto es diferente, pero a mí de estos sistemas me preocupa la orientación a objetos y poder llamar a clases estáticas, por ejemplo. En un entorno totalmente orientado a objetos y desacoplado los sistemas de plantillas con sublenguajes no se integran tan bien como los basados en PHP, y ese es, personalmente, mi argumento más fuerte para no usar ni Smarty ni Twig.

  8. Los motores de plantilla nacieron con ese objetivo de ser completos y fáciles de manipular según el programador que haya dominado cierto api, normalmente es un standard que se usa para los sistemas MVC, siempre es de tomar en cuenta el rendimiento y la velocidad, xmi parte recien estoy viendo lo de Smarty y claro xq no encontrar un buen motor de plantillas, es notable que cada producto de este tipo tiene su pro y contra y como dice Manuel "qué es mejor para mi proyecto concreto" :) para que más adelante pueda maniuparlo no solamente uno sino varios en esa parte.

  9. Muy bueno el artículo, pero disiento un poco y estoy muy de acuerdo con Manuel.
    Los "template engines" han nacido para que un maquetador que conoce a fondo HTML y CSS (sin conocimientos de PHP) pueda realizar una plantilla con solo aprender ciertos comandos y para tener un nivel de seguridad más alto.
    Si es por el tema de la velocidad de respuesta, se puede realizar un sistema de cacheo para Smarty que utilize Memcached y que no almacene en disco, sino en memoria el template "compilado", con esto se obtiene cero acceso a disco y por lo tanto mayor rendimiento.

  10. No podria estar mas en desacuerdo con tigo!
    punto 1: ?? justamente para eso sirve smarty…separar codigo html de codigo php…

    punto 2:
    es una sintaxis muy liviana y sencilla. no creo que sea complicado aprender esta sintaxis… para un maquetador html y css es muy sencillo… y si se carga algo no es un problema… al revés…

    punto 3: con que operacion complejas hablas… teniendo tu controlador, vista->smarty, y modelos de que complejidad hablas?

    punto 4: no lo se porque no uso ninguno…ni ganas…

    punto 5: mmm con smarty 3 es falso… con el 2 estamos hablando de un valor MUY PEQUEÑO

  11. @mauro,

    1/2.- Nosotros, los programadores PHP, ya sabemos PHP. Quizá para los que no saben les resulte más fácil usar Smarty, pero prueba a pedirle a un diseñador no que aprenda PHP, sino que use la sintaxis de PHP para las cuatro cosas (técnicamente sencillas) que lo necesita.

    3.- Si desarrollas pasando variables "sencillas" a las páginas, y tú escribes todo el código, quizá no sea tanto problema. Pero si utilizas helpers para HTML o formularios, si pasas de las variables y desarrollas completamente orientado a objetos, entonces sí necesitas muchos artificios para poner en tus plantillas Smarty toda la potencia de tu programa.

    4.- Si prefieres reinventar la rueda, allá tú, pero no todo el mundo escribe código desde cero.

    5.- Te digo lo mismo que a Caledor. Por muy optimizado que esté Smarty 3, es siempre más costoso cargar Smarty, compilar (o recuperar de cache) la plantilla, y asignar las variables que sólo cargar un archivo.

  12. Hola isra seria usted tan amable de orientarme como puedo pasar un codigo de smarty a php puro…si es que se puede sin hacer todo el code desde cero.

  13. como pongo un fckeditor en mi archivo.tpl de smarty y agarro el valor que estoy introduciendo ojo: no quiero pasarle el valor quiero agarrar el conternido mi fckeditor y pasarle a un php.algo para poder guardar el valor en mi base de datos

  14. como pongo en mi *.tpl un jscal? ya probre con {literal} {/literal} pero no me funciona

  15. @Pedro, por una parte puedes hacer clases PHP que se emulen Smarty y sus métodos (pasar variable, cargar plantilla, etc).

    Por otra, migrar las plantillas no es tan sencillo. Puedes hacer simples sustituciones de texto para {variable}, los bucles, etc… pero para las funciones (incluidas aquellas que tú hayas agregado a Smarty) me temo que no hay ninguna forma automática.

  16. Hola, sin animo de ofender pero estoy en desacuerdo, ya he hecho varios proyectos grandes usando Smarty y no me ha generado ningún inconveniente, todo lo contrario aumenta la productividad en cuanto a trabajo en equipo se trata.

    Embeber codigo php es una muy mala practica! darle mantenimiento, “debugar”, WTH! :P

    Que se le dificulte a un maquetador aprender esta sintaxis? muy dudoso el argumento, vamos! sabe HTML, CSS.x JavaScript minimo….

    Smarty rules! jajajaja :)
    Saludos!

    • Lejos de ofender, tus comentarios enriquecen el debate.

      Aunque creo que no aportas muchos argumentos, sobre todo en eso de que embeber PHP “es mala práctica”. ¿Crees que los sistemas de plantillas de Zend, Drupal o WordPress implementan “muy malas prácticas”? Yo no lo creo.

      He expuesto cinco motivos, puedes discutir cada uno de ellos… El artículo no va pretende satanizar los sistemas de plantillas en general.

  17. Se que Smarty se usa a nivel profesional y grandes proyectos lo usan pero realmenten no conocen el gran cuello de botella que supone parsear un pseudocódigo.

    La productividad no depende de un motor de plantillas, depende de como se haya estructurado el sistema a nivel de modelos. WordPress es un gran ejemplo al respecto.

    Personalmente, no utilizo Smarty y NO lo recomiendo.

  18. Es una patada al hígado; lo probé con Prestashop es más sencillo trabajar en Opencart

  19. Hola,

    Soy el creador de divengine.com, un poco que ya deben saber mi criterio no? Un motor de plantilla, permite dividir el trabajo, y reutilizar el diseño en otros lenguajes. Por ejemplo un mismo diseño creado para PHP, puede ser interpretado por JS, o por Java, etc..

    Separar la forma del contenido es buena práctica. Usar PHP como gestor de plantillas disminuye el rendimiento. Es más rápido un str_replace :) Esto es porque el parser de PHP tiene que tratar el archivo PHP varias veces: parsear, sintaxis, semantica, etc.

    El debate se extiende. Usar un motor tiene su momento, su objetivo, no es que siempre haya que usarlo.

    Saludos,

    Rafael

    • ¡Gracias por tu comentario, Rafael! Y enhorabuena por ese proyecto… la verdad es que no conocía divengine, y mola la idea de logic-less template. Otros sistemas así, como Moustache, tienen la ventaja de la interoperabilidad, lo cual es muy interesante en webs con una fuerte carga de JS/AJAX: tener un mismo motor de plantillas en el cliente y en el servidor permite reutilizar más y mejor el código.

      Quizá la contrapartida es que las logic-less templates exigen pasar cada una de las variables, mientras que con Smarty puedes acceder directamente a clases, etc. Ojo, eso es bueno en la mayoría de los casos, pero en otros es un esfuerzo mayor de desarrollo.

      En cualquier caso, mantengo que a nivel de rendimiento es una pérdida :-p

      • Con div puedes acceder a metodos de clases y funciones, pero debes definirlo primero. No es bueno acceder desde la plantilla a cualquier parte del codigo, ademas rompe el patron. Todavia el motor para javascript no esta terminado. Estoy lleavando a div en php a un nivel tal que pueda mantenerse un tiempo y luego hacer un clon en otros lenguajes. Empezare por JS, luego quizas con python, porque no?, quizas java, etc… Quizas la comunidad me ayude.

        Te pongo un ejemplo de lo que puedes hacer con div OOP, es algo como esto:

        class MyPage extends div{
        public function getLastBlog(){
        return array(
        “title” => “The last blog entry”,
        “body”=>”bla bla bla”);
        }
        }

        echo new MyPage(“index.tpl”);
        ?>
        y en la template

        {= blog: ->getLastBlog() =}

        {$blog.title}
        {$blog.body}

        La clase myPage puede ser la V del MVC.

        Saludos

        PD: El rendimiento mejora mientras mas “inteligente” es el algoritmo, y mientras sigas las buenas practicas que propongo.

        • Más de lo mismo. Prueba mustache si quieres reutilizar plantillas… aunque las de mustache son logic-less.

  20. Pretendo aprender Zend Framework para proyecto grandes, podria trabajarlo sin usar el Smarty???, realmente como dicen cada libreria, cada componente adicional a una aplicacion incrementa costo en terminos rendimientos, por lo quiero evitar usar el smarty o cualquier otro motor de plantilla, es posible sin usar ninguna con el Zend Fram???

    • Hugo: sí, es posible usar ZF sin Smarty y sin ningún otro motor de plantillas. PERO:
      1) Si es un proyecto realmente grande, el front-end será complejo y quizá merezca la pena usar un sistema de plantillas, pero no Smarty sino Twig que es mucho mejor.
      2) “La optimización prematura es la base de todos los males” (Knuth). No optimices lo que todavía no existe. Preocúpate por hacer una buena arquitectura del software.
      3) Si quieres optimizar, empieza por lo que más recursos consuma. Y para saber qué consume más recursos, debes medir. Usa xhprof y/o xdebug para medirlo, pero ya te adelanto que seguramente la BD se lleve bastante (si usas eficazmente memcached puedes optimizar muchísimo). Y, por supuesto APC instalado en el servidor siempre.

  21. Estoy de acuerdo contigo,
    el si en tu proyecto ya mantienes un código extenso, pues al usar Smaty a simple vista parece que todo estará de maravilla, pero no es así, imagínate los procesos que se realiza para convertir todo a PHP.

    en mi opinión eso seria una carga mas para un proyecto, y el consumo de recursos adicional para el servidor.

    un saludo.