Hacker News new | ask | show | jobs
by leetrout 6 days ago
> Is Jinja2 a practical alternative or there's friction to using it?

jinja2 is drop in by changing the template backend. You can actually run both at the same time (just can't mix them, ofc).

https://docs.djangoproject.com/en/6.0/topics/templates/

1 comments

It's a practical alternative, but definitely not a drop-in replacement! I've been working on migrating a django project to jinja2 lately, see the diff: https://framagit.org/la-chariotte/la-chariotte/-/merge_reque...

A few notables differences:

- many controls are now functions/variables (that's good!), and some change name, for example `{% csrf_token %}` -> `{{ csrf_input }}`

- calling methods without parenthesis does not work (that's good!), for example `query.all` -> `query.all()`

- in tests` response.context` is replaced by `response.context_data`, which is not set when calling `render` directly (need to return a proper `TemplateResponse`)

- template folders need to be renamed from `templates` to `jinja2`; there may be a way to change this behavior, but i did not find it, and this change is written so small in the docs i lost an entire day over it

Yea, I was unclear. That's what I meant by "you can't mix them"... just meant using jinja2 is drop it for the backend.

I believe you just set the dirs property in the backend config to look in whatever directory / directories you want it just defaults to jinja2 as you discovered.

From what i understand `DIRS` is only for the top-level app. I couldn't find a way to apply it to inner apps (eg. `auth`, `order`, `etc`). I'd be happy if you know the way i don't have to rename all the template folders!
Thanks! Any noticeable downsides?
For now, no. But to be fair, it hasn't reached prod yet. So far, only great upsides: developer experience (in templates) is considerably better, and djlint/j2lint make it even better (one for HTML validation through the templating, the other for jinja syntax).

Also, it should be considerably faster to render, but i haven't properly measured yet. I just know on lower hardware, the django template "static" homepage (rendered, but no conditionals and no DB calls) takes average 23ms to serve with variations 14-53ms, while a real static page takes 3ms average with 1-6ms (that's all on localhost so no network instability is measured). Can't wait to have the jinja stats!