Template Engines – Learning when Not to Use One

template engines While researching this topic, I discovered more template engines than I care to know about. Some are language-specific (PHP or JavaScript or something else only) and some have versions for multiple languages and platforms.

I also discovered I don’t really need a template engine for my CMS project. I’m generating HTML files and I can manipulate the source files with PHP alone. Using a template engine would add a level of complexity that would make things harder to manage, not easier.

Template Engines

There’s a handful of template engines I looked at. Here’s the list:

PHP Manipulation

There’s a bunch of things on an HTML page the average visitor will never see. Some will because curiosity will cause them to look at the web browser source of the page. It’s that “invisible” stuff that causes all the headaches.

My solution is to use the index file to build each html page using the requested URI (like “/this-page.html”), including a header before it and a footer after it. Since all three sections will be in memory at the same time, I only need to replace “variables” with some lines included at the top of the HTML file.

It’s the header file that will cause me the most grief. Along with the stuff that’s been around forever, I also have to account for Open Graph items and structured data (schema).

If it ain’t broke, don’t fix it

I’ve tried to live with that philosophy most of my adult life. That started soon after Bert Lance coined the phrase in 1977. I can’t tell you how many times I’ve seen people change things just for the sake of change.

I’m not planning to change anything that I have in place now. The CMS project I’m working on is completely separate and something I want to perfect for other sites I may (or may not) create.

Share this: