
Why Jinja is not Django and why Django should have a look at it - apgwoz
http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-and-why-django-should-have-a-look-at-it
======
teilo
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_.

~~~
piranha
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.

~~~
teilo
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.

~~~
shadytrees
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.

------
arthurk
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").

------
shabda
For context, [http://groups.google.com/group/django-
developers/browse_thre...](http://groups.google.com/group/django-
developers/browse_thread/thread/4f5b01719e497325/a60123ee5af0c566#a60123ee5af0c566)

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.

~~~
snprbob86
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.

~~~
blasdel
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.

~~~
snprbob86
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.

~~~
blasdel
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.

~~~
snprbob86
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...

------
superjared
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.

~~~
apgwoz
I forgot that Jinja had some C speedups. I think the last time I installed it,
I was in a rush and there was an error.

It makes me wonder if [http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-
django-an...](http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-and-
why-django-should-have-a-look-at-it#comment-66) is using the speedups or not.
It seems that 400 ms might be slow with them all enabled...

------
erlanger
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.

