This is a terrific article, that does a pretty good job of explaining why template engines generally do the wrong things, and so are a bad idea.
The need for templates comes from the need to reconcile two opposed positions:
1- Site performance is dependent on: bandwidth, disk i/o, memory, and mips (in roughly this order).
2- Development performance is dependent on: abstraction, expression, composition. (All of which are increased by expending more disk i/o, allocating more memory, or using more mips.)
Instead of saying 'img src="path/foo"' it's easier for me to write and call a function "show_image(foo)".
I then build up to
show_image_palette(foo, bar, baz)
and from there to
and from there to
Every time I increase the distance between the developer and the HTML, I improve the performance of my "development engine" -- more expression per byte written.
But doing so in "pure php" comes at the cost of burning mips and memory and disk i/o to pull in all the classes and templates and who-knows-what needed to translage
The solution, of course, is to use "software judo" to put abstraction and expression to work on the whole mips/bandwidth expenditure issue.
The best answer to date is of course the one proposed in the article:
1- Provide an abstract interface to the separation of business from presentation logic. Partitioning the code into "business parts" and "display parts" is a good idea, regardless of what languages are used for either part. (You could get away with a big horizontal line in your source code, if it comes to that:
----------- HERE BE PRESENTATION ----
2- Develop a caching mechanism so that abstract code like page_header(...) only has to be converted to html once.
Someone made the comment that caching was just covering up inefficiency. This is untrue. Caching is to PHP what compilation is to 'C++'. PHP doesn't get compiled to binary code, despite what the Zend wonks tell you. PHP is compiled to HTML, every time the user clicks the mouse. THAT is the ultimate output, so that's where the highest benefit is derived.
To restate: This is a fine article, and a nice start at recognizing the 'real' requirements for a templating system. Kudos!