"We wouldn't ever hire a designer who couldn't pass a code review for some trivial template logic."
I've worked with four design firms now, three of them excellent, and none of them could have been expected to understand templating code. If you're asking your designers to work with a template language, you're doing it wrong.
This has nothing to do with whether you put logic in your templates or not. The designer's deliverable isn't a working site; it's HTML/CSS/PNGs, and it's a dev's job to pull that into the framework.
Those two opposing viewpoints on a designer's role probably have a lot to do with the type of application you are designing. If I was doing the hiring, I would expect more template language understanding for a web application than from marketing or traditional web site.
I think it's fair for him to say he wouldn't ever hire a designer like that but I think it's because he's only built sites where it makes sense to optimize for that.
Why on earth would you want to narrow your options? There are dozens of template languages. Why would you want to spend one cent extra, or sacrifice one extra cent of quality, to find a designer who was not only skilled in information design, graphic design, typography, and interaction design, but also Django (or Erb or PHP or Clearsilver) literate?
Django templates are significantly different than all the other ones you mentioned.
It was architected from the beginning to be friendly to non-programmers -- the idea was that someone writing an article for the Lawrence Journal-World (or a designer) could easily use custom templating in a constrained templating language that developers can augment with custom tags and filters.
It surprisingly works incredibly well for that use case. The templating language strictly enforces view-separation -- the template author can't do anything the developer didn't intentionally let them do.
It can be ridiculously frustrating if you're expecting it to be a normal language -- for instance __getitem__, __getattr__, and __call__ all use the same "obj.property: arg" syntax. It calls hasattr at every call site to figure this out, and you can't use () or [] even if you wanted to. Fuck, you can't pass multiple arguments to a function!
I've heard the refrain about keeping logic out of templates so many times, and yet professionaly I've never come across a situation where totally programming-clueless designers were actively editing templates. It always falls into one of two categories:
* the designer doesn't go anywhere near the real app and does all their work as mockups of HTML / CSS or even Illustrator / Photoshop. Developers do the work to integrate templates, designers at most fiddle with the CSS or bare HTML in the template and never touch any logic.
* the designer is reasonably competent to deal with the primitive programming in templates and is involved in the full lifecycle of product development
The bottom line is that if they are too leary of programming to cope with simple logic structures in a template then they are altogether incapable of working productively as part of the development lifecycle and should just hand their stuff to people who have those skills.
If you're going to have external designers: I agree, their deliverables include ZERO logic.
However, zero logic is even less than Django templates. If it is the devs jobs to retrofit the HTML/CSS/PNGs with templating logic, it is an even bigger argument for choosing a developer friendly template language instead of a designer friendly one.
I've worked with four design firms now, three of them excellent, and none of them could have been expected to understand templating code. If you're asking your designers to work with a template language, you're doing it wrong.
This has nothing to do with whether you put logic in your templates or not. The designer's deliverable isn't a working site; it's HTML/CSS/PNGs, and it's a dev's job to pull that into the framework.