4 ms·

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

by Yaggo 15y ago

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

irahul 15y ago
> Why not simply switch to Ninja? 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.
asto 15y ago
If you want something faster, why not try Pyramid? It's a modular framework that lets you pick any component you want! http://www.pylonsproject.org/ http://www.pylonsproject.org/
obtu 15y ago
Mozilla does it with their Jinjo (template loader applying Django's layout conventions to Jinja templates): http://jingo.readthedocs.org/ http://jingo.readthedocs.org/ Coffin ports some template tags as well: https://github.com/coffin/coffin/ 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&ben=django&env=tannit&revs=1000 http://speed.pypy.org/timeline/?exe=1&base=2%2B35&be...
rlander 15y ago
Better yet, why not deliver first-class support for multiple templating engines, something like ruby's Tilt?
reuser 15y ago
The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" rather than fearing that they would generate a great variety of new tracebacks for you to look at. 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
- rlander 15y ago
  The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" 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?

by Yaggo 15y ago

irahul 15y ago

> Why not simply switch to Ninja? 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.

asto 15y ago

If you want something faster, why not try Pyramid? It's a modular framework that lets you pick any component you want! http://www.pylonsproject.org/ http://www.pylonsproject.org/

obtu 15y ago

Mozilla does it with their Jinjo (template loader applying Django's layout conventions to Jinja templates): http://jingo.readthedocs.org/ http://jingo.readthedocs.org/ Coffin ports some template tags as well: https://github.com/coffin/coffin/ 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&ben=django&env=tannit&revs=1000 http://speed.pypy.org/timeline/?exe=1&base=2%2B35&be...

rlander 15y ago

Better yet, why not deliver first-class support for multiple templating engines, something like ruby's Tilt?

reuser 15y ago

The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" rather than fearing that they would generate a great variety of new tracebacks for you to look at. 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

rlander 15y ago
The specific reason not to switch to Jinja2 was that Django's templating language was originally intended not to be that powerful, so that you could feel reasonably safe handing it to non-technical "designers" or "writers" 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?