[Django]-Any drawbacks or gotchas to using Jinja2 templates in Django?

I use Jinja2 in some of my projects and love the extra expressiveness it gives me. I can keep my presentation logic and application logic separate, but I don’t have to bend over backwards to call into a function/method I’ve designed specifically for my presentation layer.

In addition to what’s already been listed by other posters, here are some things that I’ve found:

• The Admin app is tightly coupled to Django templates
• The default views and decorators that come with the Auth app (and elsewhere) are coupled to Django templates, so you may have to duplicate the effort if you want to use your Jinja2 templates for login/logout/etc

Behaviorally, Django templates will escape its output by default whereas Jinja2 will not. I think either approach has its own merits, but you have to keep this in mind if you are switching between the two.

I’ve documented several of the syntax, config, filter, and interoperability considerations for Django -> Jinja2 on my wiki

Extending Jinja2 is much harder than Django template system (I’m talking about templatetags). While most of inclusion tags functionality can be achieved using macros in Jinja (they even seem to be more appropriate), writing bit more complicated tags is really hard in Jinja (see the docs for yourself).

Other than that, the only obstacle are Django-based habits… 😉

There’s been some new code added in the Django trunk that lets you write TemplateLoaders and Template classes that can be used to work with different template languages. Docs have been added for it at http://docs.djangoproject.com/en/dev/ref/templates/api/#using-an-alternative-template-language, and it will be in the 1.2 release. This should cut out most of the gotchas with things like using custom templates for login, logout, admin etc.

An alternate solution is to use a layer on top of Django, like Chouwa or Djinja2. You will have issues getting Django’s builtin views to use your templates, but it works if you don’t want to use Django trunk.

Once you’ve done either of those, the only really major issue is that most of the stuff Django exposes to templates (especially for the comments framework) is exposed in custom tags, which don’t translate to Jinja2. Sadly, backwards-compatibility concerns don’t see this changing anytime soon.

For me, the most annoying thing from using Jinja2 in Django is that you won’t be able to use some Django apps when they come with their own templates or template tags (e.g. django-uni-forms).

This can be frustrating some times, when you find a great app that solves your problems but you can’t use it because it’s not compatible with Jinja2.

BTW, it seems that Armin Ronacher (the author of Jinja2) will be working on a new template engine backend that will sit behind both Jinja2 and Django, replacing the current infrastructure but preserving backwards-compatibility. https://www.djangoproject.com/weblog/2011/apr/25/gsoc/

re: the lack of {% spaceless %} in jinja2, check out the jinja2htmlcompress module:

# In shell:
fetch -o myapp/jinja2htmlcompress.py https://raw.github.com/mitsuhiko/jinja2-htmlcompress/master/jinja2htmlcompress.py

# In your app:
app = Flask(__name__, static_path='/static')
app.config.from_object('myapp.default_settings')
app.jinja_env.add_extension('myapp.jinja2htmlcompress.HTMLCompress')

As April 2015, Django 1.8 supports rendering templates with multiple engines within the same project, and has built-in support for Jinja2. So it doesn’t have to be an all-or-nothing decision anymore.

(While this isn’t directly answering the question, since this was previously the case I thought it merited more than just a comment).

I had some issues getting crispy-forms to work with Jinja2. There is a pretty easy way to solve this however.

django crispy forms with jinja2

I think in general downside will most likely be similar often used Django packages that just don’t play with Jinja2