Fabien Potencier: PHP does need a template engine

Fabien Potencier’s latest blog post is yet another entry in the popular debate in the PHP community over templating. Recently, conventional wisdom has swung back to the use of PHP itself for templating, rather than one of the popular but resource intensive template engines like Smarty.

I discussed this myself here. At the time Brian Lozier wrote his article, his approach was probably in the minority. Other than the use of short tags, however, PHP for templating has seen a renaissance.

Fabien’s angle on this, however, is anti-popular sentiment. He argues that PHP is too verbose to be a good template language, its syntax is not concise enough for templating, and it lacks sufficient reusability in a template context. I find the first two of these positions pretty subjective, and you’ll find from the blog comments there are plenty of opposing opinions on this.

I posted my own comments over there, and re-print them here for your consideration. I think I made some valid points, but then again I have no perspective but my own, so I could be way off.

I’ve been templating directly with PHP for some time now using Brian Lozier’s. I’ve since ditched the short tags, but for me, working in a solo environment, I’d rather have simplicity (don’t have to learn a template engine syntax), control, and save the performance to spend later on things like actual application features.

Further, I’m not sure what all the heartburn over escaping variables in the template is about? IMO you should never be doing real work in the template anyway, any variables should be prepared in your controller class/script BEFORE being sent to the template. You’re violating your own rule of separation of concerns by doing that much PHP work in the template. Likewise, making a function call in the template would violate the same principle. I’ve yet to encounter anything in two large scale enterprise apps that I couldn’t template with PHP.

I also agree with the comments above that its not going to hurt the designer to learn a bit of PHP. Its really not that hard and it is a translatable skill. The en-vogue template engine of the day may or may not be in use in 5 years, but PHP will be.

I would argue that a very small percentage of total PHP developers are working in an environment where there is a separate templater that ONLY does the template work and has no knowledge of or role in application coding.

In the end, Fabien announces he’s built upon some prior work by another developer to create yet another “magic bullet” template language. I had to re-think the intent of the article in its entirety once I realized at least part of his motivation must be to encourage folks to try out his new template engine. I do not fault Fabien for this (we all want to promote and share our work), but it causes me to reach the conclusion that his critique of PHP for templating is perhaps not 100% impartial.

Update: Eli White has also posted a response to Fabien.

Update 2: Padriac Brady has now posted a rather brutal response to Fabien:

Fabien’s article triggered the urge once again to challenge the status quo, the continued view of something in PHP being necessary when in truth it simply isn’t. The article takes that view to extremes, going to some effort arguing against the recent slide towards templating with PHP with arguments which are so biased as to misinform readers. [trackback]

And, now Fabien has posted a follow up to his original post:

Before I try to answer some questions, I’d like to reinstate that I like PHP templates. And you should remember that symfony has only used plain old PHP templates since the beginning. As a matter of fact, I’m been advocating about using PHP templates since my first PHP project, and I have never used any other PHP template engines. So, I’m not against PHP templates; I just find that some PHP limitations as a template language are more and more irritating for me.

delicious | digg | reddit | facebook | technorati | stumbleupon | chatintamil

Leave a Reply

Your email address will not be published. Required fields are marked *