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. 😬
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.