The Curious Case of PHP Template Engines
Update: Since this post was written, serverless technology has become my go to choice for most projects. I still like and use PHP, but I would most likely not build another major project with it. 😬
I've been writing PHP code since 1998, so it feels very familiar to me. I built my last major web project in PHP, and if I had to do it again, I'd make the same choice. So whenever a task comes up that could be automated with some quick code, I typically default to PHP. Recently I found myself battling with some reporting templates I inherited that were coded as a mix of Python, SQL, HTML, and Javascript. The finalized reports need to be converted to PDFs, which means the PDF converter needs to be able to process Javascript. This has proven to be a problem since the prior developer was unable to find a good solution. So now I'm left with a highly inefficient, manual process.
The other problem I faced is that the templates are not really "templates" in the traditional sense. There are no variables to be filled in, just empty blocks that get populated with Javascript generated HTML. I don't like this approach at all. I now have two "templates" in a sense, one that defines "blocks" and the other in the Javascript that assembles the data grids. Do you want more bad news? The data grids are using Google's visualization Javascript to format the tables, which means I have to add additional Javascript code to manipulate the layout. So let's say I want to conditionally add an additional header row partway through the table (like I had to), well, Google's visualization engine doesn't make that super easy. Not only that, but I have to add the logic to the Javascript file.
Enter the Template Engine
I've been working with template engines since the dawn of time, so I know the ups and downs of using them. I've used everything from Smarty to Twig to many others. For my last startup, I wrote my own lightweight template engine, so I totally get it. They all have their advantages and disadvantages, but perhaps the biggest disadvantage, is the bloat. What I mean is that some of these template engines get so complicated that you end up putting a tremendous amount of logic in the templates themselves. I like to keep my data, logic and UI separate (something like MVC), but I also believe in allowing plenty of flexibility and reusability with the presentation layer as possible.
Many of these template engines allow for this. Lots of them allow for rapid development, which is never a bad thing. But for the purpose of what I'm trying to accomplish, I just need something simple. Something ridiculously lightweight that will parse Jinja-like templates so I can fix these report templates. I downloaded a simple framework called H20, and so far it seems like it will do the job.
For me, it really comes down to a judgement call based on what I'm trying to build. Template engines are great, and I use them when I need to, but reusability should be the number one priority. If I create a template with some simple conditional and for loop logic, I should be able to run that against any interpreter I want with a JSON (or similar) data structure. That way my templates are universal, and if I change the way I generate them (because maybe now I need to auto-convert to PDF), then most of the work is already done for me.