Consider the origins of PHP. It began as a lightweight way to drop bits of dynamic data into static HTML. It was not trying to be a language or a framework. It was a convenience layer, essentially a templating system for inserting data into HTML pages. But convenience expands. Once people realised they could slip in a conditional here, a loop there, PHP started to grow. And grow. And grow again. Before long, the humble templating glue had become a full programming language with objects, exceptions, namespaces, attributes and a sprawling ecosystem.

Yet even as PHP evolved far beyond its original scope, the problem it was created to solve never disappeared. Developers still wanted clean separation between logic and presentation. They still wanted templating. They wanted HTML that did not look like a rat’s nest of interwoven PHP tags. So the community built another layer. Templating engines written in PHP such as Smarty, Blade and Twig appeared, each promising clarity, safety and simplicity. Twig matters especially now because Concrete CMS is moving in that direction.

But developers are developers. They want simplicity until they hit a limitation, then they want power. They want to avoid logic in templates, yet they also want templates that express increasingly complex logic. So templating engines accumulate features: filters, functions, macros, inheritance, custom tags, custom token parsers. Every attempt to keep things simple eventually bends under real world requirements.

At this point it feels as if PHP’s history is repeating itself. Templating was meant to be minimal, light on logic and focused on presentation. It restricted what you could do. It enforced boundaries. It was supposed to prevent the very mess PHP could become when mixed directly with HTML.

Templating engines are following the same trajectory PHP once followed. With enough time and user pressure, they grow in expressive power until they become full programming languages in their own right, complete with new security bugs, syntax quirks and libraries. Instead of programming in PHP, we will be programming in a collection of heavily pimped templating dialects.

When that happens, someone will invent a new templating language written in whatever Twig or Blade have become, all in an effort to restore the simplicity the previous templating engine originally promised.

And so the cycle continues...

As for whether I will use Twig in Concrete CMS, I expect I will. I will try to resist drifting into full programming with it, although I know how these things tend to go. I began web development using Perl and CGI, so I have seen this cycle before.

Topics and Tags
Discussion

If you would like to discuss any of these thoughts, please start or continue a thread on the Concrete CMS Forums.