Hacker News Reader

Comment by tyrmored | Hacker News Reader

Among PHP developers, the idea that "PHP is already a templating language" became pretty much memetic. I use an older version of this engine in my work and never really bought into actively hating Smarty, although I stopped using it for my own projects.

One of the core arguments against it, I think, was PHP developers suddenly remembering short tags and alternative syntaxes for control structures (if, foreach) that made working with templates in straight PHP just as easy, much more flexible, and shaving a few milliseconds off load times -- it's a sizeable library to load.

View on HN

I've always thought that the problem with that viewpoint is that PHP is actually a pretty bad templating language.

    <?php echo htmlentities($name); ?>

In Django templates:

    {{ name }}

Things get a bit better if you write your own "h" function:

    function h($var) { echo htmlentities($var); }

The htmlentities issue isn't anything a little upstream logic couldn't fix; just the same as Django's templating engine does.

<?= $name ?> is my preferred method of printing inline, which shortens it up quite a bit.

Mine, too, although I usually do my escaping/encoding in the template itself, so it becomes:

  <?= h($name) ?>

Which isn't that terrible.

The PHP developers don't make this easy though, as "short tags" are officially recommended to be disabled, so to write portable PHP you'd have to do

  <?php= h($name) ?>

Every time, which adds visual noise that gets worse the more tags you write.

I am not here to defend php (Okay, I guess I am...) but the form

<?= htmlentities($name) ?> is a lot better...

We have to have an i18n layer anyway for all output so it ends up being a lot of <?= Msg('message-name') ?> calls. Use some code gen macros and it's tolerable.

Also, XHP seems pretty rad. It gives me ideas. :)

`htmlentities()` defaults to ISO-8859-1 encoding, so the short form is useless in practice, and you need:

    <?= htmlentities($name, ENT_QUOTES, 'UTF-8'); ?>

Adding an extra layer of abstraction to have somewhat nicer looking source code doesn't seem worth it though.

I definitely agree. Especially when I'm passing my code to designers who are scared of code.

Giving them a template file with something like {$CustomerFirstName}. Which they can then move around without fear of breaking the page makes sense.

And let's be honest there aren't that many websites in the world which have to really worry about the performance implications of using smarty.

I'm with you there...I like that Smarty covers up some of PHP's quirks, like htmlentities($var) vs urlencode($var) becoming {$var|escape:'html'} and {$var|escape:'url'} respectively.

There are also nice little shortcuts in Smarty, like wrapping templates in {strip}{/strip} to strip newlines and whitespace which would be tricky in PHP without using output buffering.

Not only that, it was also that Smarty2 is PHP4 code, and in recent years anyone reasonable moved to PHP5 and its' reacher OOP features - you still could use Smarty there but a) it could produce some technical problems B) it was totally not cool. In the meantime some other template engines were made (e.g. Dwoo or Twig) and they were better written, probably faster and have some great, new features (template extending). What further undermined Smarty's position was that php.net stopped to support the project (though I don't remember when it had happened exactly, might be well before 2008).

But aside of all of that, the 3rd version of Smarty puts it back on the right track.

Reply on news.ycombinator.com