And if you’re at risk of your template editors hacking your site, then they shouldn’t be editing templates..

I have written piles of Django template tags for my own site, including a recursive control structure, a “bind” tag to do the same thing as the Jinja “set” tag, and many others… these are utility things really lacking in Django, and I have to say the more I work with Django the more it feels like a real lack.

A couple patterns are really common when writing template tag libraries for apps. One is a tag which calls a function and branches based on the result, e.g., to test user privileges. I rewrote this tag so many times that I developed a generic function caller control structure. Probably the biggest one, though, is writing tags that do a database lookup and bind a data structure to a variable for off-side content that isn’t related necessarily to the main content of the page and therefore inconvenient to handle in every view.

This is a bloody massive amount of overhead for what turns out to be an extremely common task. In Jinja, though, you can bind axctual functions to the context and by using the set tag and calling the function retrieve and this kind of information in the template. With Django integration, you could use context processors to place the necessary functions in all contexts and presto, vastly less boilerplate to achieve this common and simple objective.

I mostly really like Django and even the Django templates, but I’m thinking twice right now.

while probably sufficient for most web development, the django template language lacks the standard functionality desired for an application, mainly a complete set of conditionals and operations and the ability to easily pass arguments to function calls.

this is necessary because templates house the app rendering content, and need to make decisions about what to show the user by examining and processing the context that is passed.

this gets very messy and laborious without complete logic, operations and function calls – you end up writing a lot of functions to create strings the templater is too awkward to produce and having to pre-compute series of flags in views to add to the context for operations that are a pain to do in the template. this causes problems when multiple views render the same template – you end up with a ‘respond’ layer in-between that processes the context and generates the strings and flags the template needs – added complexity and dependency with little or no added value.

again, these issues are probably minor or negligible for most django web projects, but they become debilitating for applications (our typical small app is 100-200 source files).

i’m just checking out jinja, but after one app on the django template engine, i realized it wasn’t a viable solution for an application scale project.

oh, and it’s slow as all hell.

First is macros, with support for recursion. Writing template code for producing trees is difficult, making it tempting to produce markup in a view or templatetag. That’s a pretty glaring omission on Django’s part, IMO. Jinja’s loops support recursions too.

The second is that with a normal parenthesized parameter syntax, you can pass more than one argument to a filter or method. This is absolutely necessary for for some kinds of filters which in Django have to parse an argument string. The filter syntax is nice looking, but without parentheses it’s very limited to a strict left-to-write precedence rule. This also encourages more view logic and templatetags.

I’m not trying to flame here, but I really don’t see what Jinja can do for me that Django can’t. I don’t think you should ever have Python code or extensive logic in template files, either.

Again, no flame intended, but one has to be really careful when telling new (or old) Django developers that something is better when there isn’t much here to substantiate that notion.

And again, I don’t see any valuable (for me of course) reasons to switch to Jinja. So all others reasons are more subjective than objective.