The inner platform effect is reminiscient of the Ouroboros
Many of us who use PHP began by using it as a templating engine, the practice of interspersing our HTML with snippets of PHP to achieve a website with dynamic content. At first it is satisfactory, but then the code between the HTML grows, and it ends up being PHP interspersed with HTML, making it difficult to see where the display and business logic are. Here is where many people decide to either use a templating engine, or roll their own. Ignoring the fact that writing your own is a massive case of reinventing the wheel, the general solution is to pick up Smarty or reinvent it.
Today I was attempting to determine the templating engine I was going to use for two projects I am currently working on, so I decided to look at Smarty and a few others, and then decide if the engines I’ve written in the past would be better. I spent a little while comparing the various templating engines, trying to gauge public opinion of which was preferred. Then I looked at the Smarty syntax comparison page and it hit me. These template engines are an example of the inner-platform effect. They essentially replicate the functionality of PHP within itself.
What is the gain? According to Smarty; a few less characters of syntax, making it “easier to read”. For who? The people who know neither PHP or Smarty? Certainly not the developers, who will be clearly accustomed to PHP. Then on the other hand we add a fairly large parsing overhead on each page request to parse this template. Given that Smarty is probably one of the more mature, featured and speedy template engines for PHP, we have to wonder about all of those home grown template engines that you see on various projects. Most developers I have met have one of their own. Those are likely to be less useful and slower than Smarty, so they confer even less benefits. This leads me to the obvious conclusion; in most cases, PHP should be the template engine of choice.
"But the designers don’t know PHP" is something you may hear in response to my statement, but that begs the question; if they know neither PHP, or any other template engine, why can they not learn the very basic syntax that is required for templates? This leads me onto another much more important point; templates should be simple. For any significantly different version of a given page structure you should have a separate template, even if in the business logic for the templates seem to be a single semantic unit. Design logic should be displayed as simply as possible, and be separate from the business logic. This is the very basic tenant that is often ignored by new developers which leads them to believing they need a dedicated template engine in the first place.
For those that prefer examples; keep your PHP template files separately from the rest of your business logic, and simply include them at some point in your business logic where you can successfully state that you have enough information to complete the template, just as you would in any other templating engine. This will mean designers can edit them without having to see vast amounts of more complex PHP, and it means that they will be separated from the business layer. Teaching the designers PHP will not be too difficult. If they would be able to understand Smarty, they would be able to understand PHP.
From today I will be using PHP as my default template engine whenever I am developing in PHP. Rather than reinventing the wheel, or succumbing to over-engineering desires, I will use the fastest, simplest, and most powerful template language available. or reinvent it.