> 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).
jinja2 is drop in by changing the template backend. You can actually run both at the same time (just can't mix them, ofc).
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
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!
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.