The biggest problem with Jinja2 are the template tags.
If you don't need template tag libraries, Jinja2 is the obvious choice. If you do, however, then good luck. Django Template custom tags are easy to implement, even if you are not using the decorator helpers.
Jinja2 custom template tags are, to quote their website "non-trivial" to implement, and so poorly documented that you are stuck trying to figure out how the tags work from source.
In my CMS I have a number of tags which I make available to my users (for things like named content blocks, menus, named images, etc.). I attempted to migrate my tags to Jinja2, but finally gave up. With proper caching, Django templates are good enough.
Jinja2 custom template tags are, to quote their website "non-trivial" to implement, and so poorly documented that you are stuck trying to figure out how the tags work from source.
I agree that the parser API is not exactly pretty - but creating your own tag starting from that example is pretty straightforward. I have created many tags myself (mostly the standard case of mutating the enclosed content in one way or another) and can't complain. It took me literally minutes to get my first tag working - perhaps you are referring to an older version of jinja?
A lot of cases where you need template tags in Django just does not exist in Jinja. And while Django tags are quite easy to implement, there is a problem that they are completely inconsistent because you need to parse input string yourself.
Jinja tags are harder to grok, but after that they are starting to make sense.
This is like the old Opera argument: Our browser obviates the need for most extensions, so why should we provide an API?
In my example, a CMS for Pete's sake, there is a very real and pervasive need for custom tags that are in no way obviated by Jinja2's architecture. Jinja2 is a great developer template library, but, as a previous poster noted, a very poor Designer library. I code my platform for Designers. So do a whole lot of other CMS programmers. So this line of reasoning, while accurate, is moot.
That wasn't piranha's argument though. The argument was that Jinja's tags API is more difficult to use because it provides structured access to the code whereas Django just gives you a string. That Opera analogy doesn't apply because the API clearly exists.
I met Armin Ronacher (the author of Jinja) at this years EuroDjangoCon. He was actually hacking on Django's template system himself and closed one ticket after another (though he was told that he couldn't "just replace it").
My reasons for choosing Django templates over pretty much anything comparable. Everything else tries to make things easy for developers, Django templates makes things easy for designer.
As a small team (read: 2 hackers), I have no desire to make things easier for the designers... because we have none. We're trying to get some work done and we can't really afford to hire anyone who can't wear every possible hat. Clearly, we aren't the target customers of Django templates, so we use Jinja2.
Even if we had designers, I'm not sure they should be writing templates. I'd rather they be writing CSS and that the dev team be responsive to template change requests. If a designer needs a div or span or move some stuff around into a table, they should be able to handle basic template manipulation in any language... and those changes need to be code reviewed by a developer anyway.
On a related note, I just wish there a more mature Haml implementation for Python. We use SASS and love it, but Haml is strongly tied to Ruby. GHRML doesn't seem to be well supported or maintained.
Django was written for a newspaper, where the most important external feature of the CMS was that users be able to mess with html templating without any input from the developers.
Django templates make sense in that context, but Jinja2 templates are 90% the same. You need to know one or two more rules about () and other metacharacters, but there isn't much cognitive dissonance in a switch-over. It is easier to call arbitrary code from Jinja2, which simplifies the life of programmers even when having to work with laymen editors.
Django is no longer a newspaper-centric framework. Far more users of Django want a hacker-centric template language. Markdown and other markup languages are far closer to the needs that the Django template language once filled.
I do prefer Jinja templates, and I plan to convert the Django-templated projects I have to them the next time I hack on them. I hate the parenthisis-avoiding dispatch mechanism that does a bunch of wasteful dynamic type-checks, all to make the syntax more obnoxiously clever. I hate the fact that it implements it's own shitty interpreter. It feels Ruby-ish in the most pejorative way.
But Markdown doesn't fit the 'newspaper' usage model in anywhere near the same way -- Django templates let the writer do all kinds of layout fuckery in an idiot-proof, dev-supported, maintainable, extensible, {%benificent_adjective%} way.
But they aren't idiot proof. That's exactly the problem. If you can't trust the template writer to understand {{ foo.bar }} vs {{ foo.bar() }} how could you trust them to not do something with HTML, CSS, JS, or Django-templates which breaks the page? Either you trust your designers because you hire smart, multi-talented people. Or you want something simple, predictable, and completely impotent... you know... like a rich text editor...
Even if we had designers, I'm not sure they should be writing templates.
I've never understood this attitude. Maybe it's just because I've worked for places which seek out talented people who know their stuff, but it feels way too much like unjustified territoriality on the part of developers.
If you got a talented person who knows their stuff, then they should be able to handle whatever template language you throw at them. Gimping the power and expressiveness of your template language happens for 2 stated reasons:
1) To make it designer friendly
2) To force you to put logic into back one layer
If you have talented folks, #1 shouldn't be a concern. Any technical artist should be able to learn enough of any template language to be trusted to not break things. Just as one coder has to code review the work of another, someone should code review the designer's work. Maybe that's a developer, maybe it's a senior technical artist; it doesn't matter. Choosing the right tool for the right people puts a lot of trust in the fact that you choose the right people!
#2 is idealistic bullshit. There is HTML-specific view logic. If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose. But imagine the case were you have an "Export to CSV" button. That is simply two different templates over the exact same data. The HTML version might need to do some smarts about grouping or human-readable adjustments. There will surely be some javascript that depends on particular elements and structure. Forcing all of that logic into template tags is just silly.
If you have talented folks, #1 shouldn't be a concern.
On the contrary; we don't expect programmers to master design and become Photoshop gurus, for example, so why should we expect designers to master what is, essentially, programming? There's a lot to be said for having different groups of people whose strengths are in particular domains.
If you have a view which fetches some data, that same view should be re-usable for an API as json or xml or whatever you choose.
Actually, this only works in the most trivial (and thus non-real-world) of situations. Usually, API access needs to be mediated through additional logic (authentication, access control, rate limiting, etc.).
Forcing all of that logic into template tags is just silly.
I have to admit that I don't really know what you're getting at here. If you do have a case that's as simple as "use another template", well, you use another template. If you don't, no amount of program logic in templates is going to save you.
Anyway, here's how I see it:
1. Django's template language is designed to permit enough logic to handle presentation, and to be easily extensible for cases where you need something more.
2. Jinja is designed to permit quite a lot of free-form programming constructs, and is not particularly easy to extend when you run up against a wall.
These are fundamentally different approaches to "templating", and what I've found is that people who prefer, say, Jinja tend to just use it and move on. The people who stick around to argue are the ones who think that some particular tag or extra bit of logic should be made available by default in Django, and so are arguing about differences of degree rather than differences of kind.
This post is a bit old but still 100% valid. Jinja is a bit smarter than Django templates in some areas, includes Django support, and is wicked fast with the C speedups.
Django templates are very flexible, so I like them. I have no need to insert real programming logic within my templates, but as a designer, I love to break everything down to the nth degree, which Django templates encourage. I prefer chainable filters to any other transformation style I've seen.
If you don't need template tag libraries, Jinja2 is the obvious choice. If you do, however, then good luck. Django Template custom tags are easy to implement, even if you are not using the decorator helpers.
Jinja2 custom template tags are, to quote their website "non-trivial" to implement, and so poorly documented that you are stuck trying to figure out how the tags work from source.
In my CMS I have a number of tags which I make available to my users (for things like named content blocks, menus, named images, etc.). I attempted to migrate my tags to Jinja2, but finally gave up. With proper caching, Django templates are good enough.