> Armin has repeatedly talked about how much slower Django's template rendering is than Jinja's, and I want to cut out our inefficiencies to bridge the gap.
Why not simply switch to N^HJinja2? (Okay, probably not that simple, but still.)
Why not simply switch to N^HJinja2? (Okay, probably not that simple, but still.)
If you have to ask why Django would not switch to (or even make any effort to allow the use of) any externally developed tool in place of its own, you might not have noticed that almost everything in Django is self-developed and that the officially given reason is that they are "perfectionists. with deadlines."
The reason why not is the Django project's philosophy
Jinja2 follows this same philosophy of a sandboxed engine and the syntax matches django's almost exactly (it was actually based on django templates). The designer wouldn't even notice he is dealing with a different templating language.
So, it looks the same from a designer perspective, is at least an order of magnitude faster and is much simpler to extend. So, why not switch?
Coffin ports some template tags as well: https://github.com/coffin/coffin/
That said, PyPy is 16× times faster rendering Django templates, which probably makes Jinja2's code-generation cleverness moot: http://speed.pypy.org/timeline/?exe=1&base=2%2B35&be...
It's jinja2, not ninja. If you want, you can use Jinja2 in your projects, but the other plugins you use will most likely be using django templates.