Premetto che fino a qualche hanno fa, dalla mia bocca, o dalle mie dita in questo caso, non avresti mai sentito dire/visto scrivere qualcosa del genere: già c'è php che fa da template engine

Sono sempre stato un fermo sostenitore dei template engine e me li sono sempre scritti per i fatti miei fino a quando non ho fatto un pò di test di performances: mediamente un template engine aumenta il tempo di elaborazione da qualche centesimo di secondo fino a qualche decimo di secondo, senza considerare l'aumento spropositato di memoria e del processore

In quel momento ho capito che se ne poteva anche fare a meno di un template engine inteso nel senso tradizionale: mi sono scritto un "wrapper" che simulasse le funzionalità di un template engine, aggiungendomi il supporto per la cache, ma che per effettuare l'elaborazione non facesse altro che l'inclusione (piuttosto che l'eval)

L'inclusione è dovuta al semplice motivo che un file incluso può essere messo in cache da componenti come APC, eAccelerator, WinCache e via dicendo ... codice interpretato con eval no!

Detto tutto questo, come ha detto k.b., tutto quello che fai con un template engine utilizzando un pseudo linguaggio lo fai normalmente anche con php ... anzi ... ti dirò di più ... certe cose con un template engine non puoi farle linearmente!

Per farti un esempio pratico: realizzi un framework sul qualche costruisci un CMS estremamente flessibile ... per un cliente hai bisogno di far comparire informazioni aggiuntive in una pagina che devi estrarre dal database ... ma non vuoi cambiare la bussiness logic perché questo significa che dovrai farne una versione "ad-hoc" solo per il cliente avendo poi problemi con gli aggiornamenti! Che fai? Lo fai lato template engine ... ma sul template come fai a interagire con il layer del database se viene utilizzato un pseudo linguaggio? dovresti scrivere un componente per il template engine che ti mette a disposizione le funzionalità del layer di astrazione del database!
Siccome, almeno per quanto mi riguarda, gli strumenti che uso mi devono semplificare il lavoro e non rendermelo più complicato ... utilizzare un template engine non è sempre la scelta migliore ... soprattutto se si parla di Smarty

Qui trovi dei numeri "concreti"
http://209.85.129.132/search?q=cache...&ct=clnk&gl=it

Speed.

Well, i won’t bother to attack the fact that it takes time to parse and compile smarty-code into PHP — since Smarty caches the result anyway.

It (sadly) takes time to include and parse PHP-code, so on heavy sites you may want to keep it on a minimum. Obviously, Smarty contains a lot of code to parse and handle all it’s magic, which slows it down. Let’s make some simple tests.

benchmark-smarty-include.php:

Codice PHP:
<? include_once( '/usr/share/php/smarty/libs/Smarty.class.php' ); ?>
<? print 'Hello world!'; ?>
As you see, we don’t actually do anything with Smarty, we just include it. Now, lets see how fast this goes:

The command i run: ab -c 10 -n 100 http://localhost/benchmark-smarty-include.php

*snip*
Requests per second: 49.23 [#/sec] (mean)
Time per request: 203.112 [ms] (mean)
*snip*
And using our engine created in the examples below, benchmark-smarter-include.php:

Codice PHP:
<? include_once( 'smarter.php' ); ?>
<? print 'Hello world!'; ?>
Again, we don’t do anything. The class just gets declared.
Apache benchmark, with the same parameters gives us..:

*snip*
Requests per second: 423.35 [#/sec] (mean)
Time per request: 23.621 [ms] (mean)
*snip*
Now, how about that! The script which includes Smarty uses 179.491 milliseconds more than our small template engine which uses PHP! Thats not good..

The tests was runned on a basic linux+apache2+php5 installation (my laptop), without any accelerator.
Detto tutto questo, usare direttamente gli include non è molto conveniente, piuttosto usare una classe che si occupi di gestire le variabili accessibili dal template, effettuare i caricamenti ed infine gestire la cache lo è parecchio