PHP ist auch eine Templateengine. PHP-Templates sind in nahezu jedem Fall die bessere Wahl. Dennoch ärgere ich mich jedes Mal über Teile des "Warum Template Engines nicht glücklich machen"-Artikels.
"Standardantwort" zu Bastian Frank:
Die Anmerkungen zum Sinn und Unsinn des Nachbaus einer Programmiersprache durch eine zusätzliche Templateengine sind sicherlich lesenswert und richtig und eventuell augenöffnend, nur zum Schluss des Artikels hin werden mehr und mehr Äpfel und Birnen verglichen und wichtige Aspekte nicht erwähnt.
Der "Über den Tellerrand"-Abschnitt ergibt im Prinzip keinen Sinn, da er von spekulativen Annahmen ausgeht. Gleiches gilt generell für die Darstellung von MVC als "Alternativentwurf" zu Nicht-PHP-Templateengines. Ein MVC-Entwurf mit PHP-View-Scripts ist strukturell identisch zu einem MVC-Entwurf, der in den View-Scripts nicht auf PHP setzt. (Wobei fairerweise gesagt werden muss, dass die meisten Nutzer von Templateengines wohl nicht diejenigen sind, die MVC programmieren.)
Das hauptsächliche Argument für Templateengines besteht darin, die View-Scripts frei von beliebigem ausführbarem Code halten zu können, also eine Sandbox-Umgebung zu schaffen, die die Funktionsweise des Backends nicht beeinträchtigt. Ein Beispiel, in welchen Bereichen das vorteilhaft sein
kann, wäre das Anpassen von View-Scripts durch den Seiten-Administrator in einem CMS.
Nicht-PHP-Templates sollten wenn überhaupt als nutzerorientiert angesehen werden, Entwicklern sollte man zutrauen können, mit PHP-Templates umzugehen.