Why I refused to use Smarty

A brief history

When I came to work in an American office (remotely, of course. And it was this year in 2000), I was forced to use the standards adopted by this organization. And one of them was the use of its own template engine, which looked like a simple html file in which there may be special sequences of characters (usually beginning and ending with "##"), which before being sent to the browser will be replaced by texts or the results of other templates. Also there was its own API for working with such templates. Very simple API. And since I was very young at that time, I adopted these standards and began to use them in my work.

Here is an example of working with such a template:
    $template = new Template();
    $template->Replace('##TITLE##', 'Hello world!');


Years passed. And during the implementation of the next project, a demand arose: “Smarty is required as a template engine.” The party said: "It is necessary." Komsomol replied: "Yes!". So I met with Smarty. I really liked him. I was just overjoyed. Any task that I needed to realize could be realized with its help. Sometimes simple, sometimes very difficult, but possible. In general, I began to use Smarty.


A few more years passed. I don’t remember why, but there was a task to find a framework for php that is easy to work with. I found a list of them and began testing them for our purposes. Naturally, one of the requirements was: Smarty support (and this was already my requirement). When reading the documentation of one of the frameworks (either Kohana, or CodeIgniter) I came across a phrase something like this: “You can use Smarty, here’s how to connect it and how to work with it in our framework, but we think that native php is easier, more understandable and faster ... ". And I thought. He began to compare implementations on native php and Smarty.

Easier? Of course, because php we already know.
More clear? Of course, we already understand php.
Faster? Of course, the Smarty code will be translated into php code (and at least it cannot be faster, but slower easily).
Safer? I think yes. Although it can be argued. A hole can be made anywhere.

See for yourself:
{$foo} против 

{assign var=foo value='baa'} против 

{include file='header.tpl'} - реализация этого на php зависит от разных факторов от  до более сложных вариантов (все зависит от фреймворка)

{assign var="foo" value="`$foo+$bar`"} // помню, всегда искал это в документации.

I will not give examples of conditions and cycles - they take up a lot of space and look approximately the same.

I also remember how on Smarty I did the implementation of a recursive tree traversal, one of the options is to create a template and call this template within itself. On php, it looks like this:

For a long time I tried to convince myself that Smarty is more convenient for designers. But they never came to him (for various reasons). And in the end, as a programmer, I had to write scripts for the scripting language. In addition, some versions of Smarty turned out to be vulnerable and I, every now and then, had to go back to old projects in order to update libraries and do compatibility checks.

PS. I have not used Smarty for 2-3 years already, and therefore it is difficult for me to assess the current state of affairs, but I think things are no better and no worse than before.

Also popular now: