Logicless Templates: LOL

Logicless: To be devoid of logic.

Merriam-Webster’s Dictionary

Babies are logicless, right? They eat and they shit. They throw toy blocks to and fro. They slap randomly at the Tower of Hanoi you bought them, not giving a damn about your shitty computer science references.

But logicless as they seem, they aren’t really, are they? I mean, not even bogosort is. We just call babies logicless, as maybe some sort of harmless insult. “Oh, Suzy, that baby of yours, he’s just so… logicless.” It almost sounds nice! The chic thing to say. The alternative, “Hey, Suzy, that baby of yours, he’s just such a… stupid bitch…” that’s probably gonna land you a swift smack from yours truly, Suzy.

And if you’ve fallen for the promise of logicless templates, you probably deserve a swift smack as well. “Logicless” has a negative connotation. So it’s no coincidence that logicless templates are severely flawed. They have their uses, sure. I use Handlebars in a few projects. But they belong nowhere near a large web application (most the time). Here’s why:

Logicless? ORLY?

First of all, let’s just get one thing straight. The very idea of calling Handlebars and Moustache “logicless” is… well… logicless. Retarded even, if you prefer. We’ve had logicless templates, long long before Handlebars was a thing. We called those templates HTML. And HTML worked fine, thank you very much. Handlebars, though, is not what the cool kids are calling HTML these days. No, it’s a templating library, and it has logic. It has ifs and fors and anybody who’s anybody these days adds in pluralization helpers, i18n… The list goes on. But when it comes down to it, in most cases, logicless templates are just a bad, underpowered frameworks.

When I was 16 and Handlebars came onto the scene, I fell for that logicless bullcrap hook, line, and sinker. Naive, 16-year-old me ate that shit up. Separation of concerns? Yes please. That whole promise of having your designers be able to edit your markup without knowing code? That totally worked out. Cause checking in changes and navigating through codebases in general is oh so much easier than understanding trivial if clauses. Cause, you know, non-engineers are completely incompetent. And retarded. (Except not really…)

No. Logicless templates don’t even make sense. They have all kinds of logic. And you know what else they have all kind of? Broken, empty promises.

You remember that one about designers taking over the templates? Well, they changed things and wondered why the code didn’t work if the h1 was an h2 (because we wrote shitty selectors), or how come the link stopped working when they changed an anchor to a div (because we care about semantics).

Plus they fucked up the commit log.

I’ve talked to exactly zero people employed with the sole task of marking up HTML and merrily committing this with their magical surprise knowledge of Git… No, this person is a rumor. That designer that can magically commit changes, navigate the codebase, and knows HTML and CSS and logic… we have a special title for that type of designer: “engineer”.

There’s an inherent coupling of semantics (markup) and events (code) in well designed applications. And separating it isn’t always necessary, and is sometimes very, very wrong.

Logic Is Unavoidable

Wouldn’t it be great if our apps didn’t need logic? Wouldn’t it be great if we could just smash our foreheads on the power button of our servers, and the paycheques would start flying through the cracks in the door, like Harry Potter’s letters from Hogwarts?

Cause those are the servers I want. So too bad they don’t exist.

Why? We need logic. Sometimes, we have logic we don’t need. A lot of times, sometimes. But the fact remains: we need logic.

Logicless templates at best just shift this logic into some separate layer, the presentation layer, or–worse–to the controller. Probably the only thing worse than bad templates is bad controllers.

Presentation layers help slim down your OMG-fat views. They’re not a bad thing. But there’s certain logic, render-logic, that belongs at the render level: pluralization and date-formating are prime examples.

It’s possible to imagine a blog post with a created_at timestamp attached to it. It’s possible to imagine you’d display this in three separate places, in three different formats. What benefit do you get from hiding that in the presentation layer? Zilch.

And don’t even get me started on pluralization… It usually only takes one time before you, a sane developer, has the thought cross your head, “Weeeeeell, pluralization isn’t really logic…” And you go fishing through Github for a pluralization helper, trying to con yourself into believing that Handlebar Moustaches are still cool.

There’s a very debatable line about which mutations should be done in the presentation layer and which at the render level. But the line that says “none of this should happen at the render level” … that line is imaginary, and hardly ever followed even when using “logicless” templates. The separation of concerns there, is a lot of times, just separation for the sake of it. It’s just a big waste of time and bad design.

But I can see the headlines now: “ALL YOUR LOGIC ARE BELONG TO TEMPLATES”. I can see them already. It’s not what I advocate. It’s not what I say. But whatever.