Misgivings About Templating Engines

14 Jun 2015

Work on Iron Blogger 2 has been ongoing. First a logistical announcement: A few of the URLs have changed. If you’ve bookmarked the RSS feed for the test instance, you’ll need to update your bookmarks; the new feed url is https://ironblogger-idenhardt.rhcloud.com/rss.

The website is built on Flask, which uses Jinja2 for templating. I have some misgivings about templating engines in general, which have come to the front of my mind lately as I’ve been working on this.

My main gripe can be summarized as “Stop trying to take away my programming language!” most modern programming languages are perfectly capable of building up html output in a way that’s perfectly readable, without resorting to custom parsers or external files. I wrote a proof of concept for python a few months back, though I haven’t revisited it recently:


The README gives a pretty good feeling for the flavor of the thing. If I’m building a web app by myself, with no other developers, I’d much prefer something like this to a templating engine. (I’d also probably use something weirder than python, but that’s a whole ‘nother can of worms).

I can think of a couple of arguments against doing things this way:

  1. Generating html in the programming language proper means that, if you have a separate design team, the design team needs to learn your backend programming language.
  2. Templates are useful for things besides html/xml
  3. If your templates have lots of programmatic logic in them, it’s a sign that you aren’t doing proper mvc; your layers should be less tightly coupled.

(1) is possibly valid, but I’m a little skeptical that learning enough python to do this sort of thing is actually harder than learning one of these templating engines. I’d actually like to hear opinions from designers on this one; It’s hard for me to evaluate a claim like this.

(2) Is 100% true, but has no bearing on most web apps — I rarely use templates for anything other than html in a web app. With things like puppet or ansible, programmatically generating kickstart files, and other things, templates are great. That doesn’t mean they’re the right tool for every job.

I don’t really buy (3). Even very cleanly written templates are going to have calls out to functions defined in the host language (e.g. join), and the fact that you’re defining every helper function in a separate file and using the template’s screwy syntax for calling it doesn’t mean you’re not putting logic in the templates. You should be keeping non-presentation logic out of the views, but that’s orthogonal to whether you’re writing them in Python or Jinja2.

(1) is the real sticking point. Working with other people is lot of why I use python as well. Hrm.