7 ms·

Why Jinja is not Django and why Django should have a look at it

37 points by apgwoz 17y ago

superjared 17y ago
This post is a bit old but still 100% valid. Jinja is a bit smarter than Django templates in some areas, includes Django support, and is wicked fast with the C speedups.
- apgwoz 17y ago
  I forgot that Jinja had some C speedups. I think the last time I installed it, I was in a rush and there was an error. It makes me wonder if http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-and-why-django-should-have-a-look-at-it#comment-66 http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-an... is using the speedups or not. It seems that 400 ms might be slow with them all enabled...
shabda 17y ago
For context, http://groups.google.com/group/django-developers/browse_thread/thread/4f5b01719e497325/a60123ee5af0c566#a60123ee5af0c566 http://groups.google.com/group/django-developers/browse_thre... My reasons for choosing Django templates over pretty much anything comparable. Everything else tries to make things easy for developers, Django templates makes things easy for designer.
- snprbob86 17y ago
  As a small team (read: 2 hackers), I have no desire to make things easier for the designers... because we have none. We're trying to get some work done and we can't really afford to hire anyone who can't wear every possible hat. Clearly, we aren't the target customers of Django templates, so we use Jinja2. Even if we had designers, I'm not sure they should be writing templates. I'd rather they be writing CSS and that the dev team be responsive to template change requests. If a designer needs a div or span or move some stuff around into a table, they should be able to handle basic template manipulation in any language... and those changes need to be code reviewed by a developer anyway. On a related note, I just wish there a more mature Haml implementation for Python. We use SASS and love it, but Haml is strongly tied to Ruby. GHRML doesn't seem to be well supported or maintained.
  - blasdel 17y ago
    Django was written for a newspaper, where the most important external feature of the CMS was that users be able to mess with html templating without any input from the developers.
    - snprbob86 17y ago
      Django templates make sense in that context, but Jinja2 templates are 90% the same. You need to know one or two more rules about () and other metacharacters, but there isn't much cognitive dissonance in a switch-over. It is easier to call arbitrary code from Jinja2, which simplifies the life of programmers even when having to work with laymen editors. Django is no longer a newspaper-centric framework. Far more users of Django want a hacker-centric template language. Markdown and other markup languages are far closer to the needs that the Django template language once filled.
      - blasdel 17y ago
        I do prefer Jinja templates, and I plan to convert the Django-templated projects I have to them the next time I hack on them. I hate the parenthisis-avoiding dispatch mechanism that does a bunch of wasteful dynamic type-checks, all to make the syntax more obnoxiously clever. I hate the fact that it implements it's own shitty interpreter. It feels Ruby-ish in the most pejorative way. But Markdown doesn't fit the 'newspaper' usage model in anywhere near the same way -- Django templates let the writer do all kinds of layout fuckery in an idiot-proof, dev-supported, maintainable, extensible, {%benificent_adjective%} way.
        snprbob86 17y ago
        But they aren't idiot proof. That's exactly the problem. If you can't trust the template writer to understand {{ foo.bar }} vs {{ foo.bar() }} how could you trust them to not do something with HTML, CSS, JS, or Django-templates which breaks the page? Either you trust your designers because you hire smart, multi-talented people. Or you want something simple, predictable, and completely impotent... you know... like a rich text editor...
teilo 17y ago
The biggest problem with Jinja2 are the template tags. If you don't need template tag libraries, Jinja2 is the obvious choice. If you do, however, then good luck. Django Template custom tags are easy to implement, even if you are not using the decorator helpers. Jinja2 custom template tags are, to quote their website "non-trivial" to implement, and so poorly documented that you are stuck trying to figure out how the tags work from source. In my CMS I have a number of tags which I make available to my users (for things like named content blocks, menus, named images, etc.). I attempted to migrate my tags to Jinja2, but finally gave up. With proper caching, Django templates are good enough.
- mcxx 17y ago
  Also, you can't have multiple inheritance with Jinja2. That's a showstopper for me.
- piranha 17y ago
  A lot of cases where you need template tags in Django just does not exist in Jinja. And while Django tags are quite easy to implement, there is a problem that they are completely inconsistent because you need to parse input string yourself. Jinja tags are harder to grok, but after that they are starting to make sense.
  - teilo 17y ago
    This is like the old Opera argument: Our browser obviates the need for most extensions, so why should we provide an API? In my example, a CMS for Pete's sake, there is a very real and pervasive need for custom tags that are in no way obviated by Jinja2's architecture. Jinja2 is a great developer template library, but, as a previous poster noted, a very poor Designer library. I code my platform for Designers. So do a whole lot of other CMS programmers. So this line of reasoning, while accurate, is moot.
    - shadytrees 17y ago
      That wasn't piranha's argument though. The argument was that Jinja's tags API is more difficult to use because it provides structured access to the code whereas Django just gives you a string. That Opera analogy doesn't apply because the API clearly exists.
deleted 17y ago
[deleted]
erlanger 17y ago
Django templates are very flexible, so I like them. I have no need to insert real programming logic within my templates, but as a designer, I love to break everything down to the nth degree, which Django templates encourage. I prefer chainable filters to any other transformation style I've seen.
arthurk 17y ago
I met Armin Ronacher (the author of Jinja) at this years EuroDjangoCon. He was actually hacking on Django's template system himself and closed one ticket after another (though he was told that he couldn't "just replace it").

37 points by apgwoz 17y ago

This post is a bit old but still 100% valid. Jinja is a bit smarter than Django templates in some areas, includes Django support, and is wicked fast with the C speedups.

apgwoz 17y ago
I forgot that Jinja had some C speedups. I think the last time I installed it, I was in a rush and there was an error. It makes me wonder if http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-and-why-django-should-have-a-look-at-it#comment-66 http://lucumr.pocoo.org/2008/9/16/why-jinja-is-not-django-an... is using the speedups or not. It seems that 400 ms might be slow with them all enabled...

shabda 17y ago

For context, http://groups.google.com/group/django-developers/browse_thread/thread/4f5b01719e497325/a60123ee5af0c566#a60123ee5af0c566 http://groups.google.com/group/django-developers/browse_thre... My reasons for choosing Django templates over pretty much anything comparable. Everything else tries to make things easy for developers, Django templates makes things easy for designer.

snprbob86 17y ago
As a small team (read: 2 hackers), I have no desire to make things easier for the designers... because we have none. We're trying to get some work done and we can't really afford to hire anyone who can't wear every possible hat. Clearly, we aren't the target customers of Django templates, so we use Jinja2. Even if we had designers, I'm not sure they should be writing templates. I'd rather they be writing CSS and that the dev team be responsive to template change requests. If a designer needs a div or span or move some stuff around into a table, they should be able to handle basic template manipulation in any language... and those changes need to be code reviewed by a developer anyway. On a related note, I just wish there a more mature Haml implementation for Python. We use SASS and love it, but Haml is strongly tied to Ruby. GHRML doesn't seem to be well supported or maintained.
- blasdel 17y ago
  Django was written for a newspaper, where the most important external feature of the CMS was that users be able to mess with html templating without any input from the developers.
  - snprbob86 17y ago
    Django templates make sense in that context, but Jinja2 templates are 90% the same. You need to know one or two more rules about () and other metacharacters, but there isn't much cognitive dissonance in a switch-over. It is easier to call arbitrary code from Jinja2, which simplifies the life of programmers even when having to work with laymen editors. Django is no longer a newspaper-centric framework. Far more users of Django want a hacker-centric template language. Markdown and other markup languages are far closer to the needs that the Django template language once filled.
    - blasdel 17y ago
      I do prefer Jinja templates, and I plan to convert the Django-templated projects I have to them the next time I hack on them. I hate the parenthisis-avoiding dispatch mechanism that does a bunch of wasteful dynamic type-checks, all to make the syntax more obnoxiously clever. I hate the fact that it implements it's own shitty interpreter. It feels Ruby-ish in the most pejorative way. But Markdown doesn't fit the 'newspaper' usage model in anywhere near the same way -- Django templates let the writer do all kinds of layout fuckery in an idiot-proof, dev-supported, maintainable, extensible, {%benificent_adjective%} way.
      - snprbob86 17y ago
        But they aren't idiot proof. That's exactly the problem. If you can't trust the template writer to understand {{ foo.bar }} vs {{ foo.bar() }} how could you trust them to not do something with HTML, CSS, JS, or Django-templates which breaks the page? Either you trust your designers because you hire smart, multi-talented people. Or you want something simple, predictable, and completely impotent... you know... like a rich text editor...

teilo 17y ago

The biggest problem with Jinja2 are the template tags. If you don't need template tag libraries, Jinja2 is the obvious choice. If you do, however, then good luck. Django Template custom tags are easy to implement, even if you are not using the decorator helpers. Jinja2 custom template tags are, to quote their website "non-trivial" to implement, and so poorly documented that you are stuck trying to figure out how the tags work from source. In my CMS I have a number of tags which I make available to my users (for things like named content blocks, menus, named images, etc.). I attempted to migrate my tags to Jinja2, but finally gave up. With proper caching, Django templates are good enough.

mcxx 17y ago
Also, you can't have multiple inheritance with Jinja2. That's a showstopper for me.
piranha 17y ago
A lot of cases where you need template tags in Django just does not exist in Jinja. And while Django tags are quite easy to implement, there is a problem that they are completely inconsistent because you need to parse input string yourself. Jinja tags are harder to grok, but after that they are starting to make sense.
- teilo 17y ago
  This is like the old Opera argument: Our browser obviates the need for most extensions, so why should we provide an API? In my example, a CMS for Pete's sake, there is a very real and pervasive need for custom tags that are in no way obviated by Jinja2's architecture. Jinja2 is a great developer template library, but, as a previous poster noted, a very poor Designer library. I code my platform for Designers. So do a whole lot of other CMS programmers. So this line of reasoning, while accurate, is moot.
  - shadytrees 17y ago
    That wasn't piranha's argument though. The argument was that Jinja's tags API is more difficult to use because it provides structured access to the code whereas Django just gives you a string. That Opera analogy doesn't apply because the API clearly exists.

deleted 17y ago

[deleted]

erlanger 17y ago

Django templates are very flexible, so I like them. I have no need to insert real programming logic within my templates, but as a designer, I love to break everything down to the nth degree, which Django templates encourage. I prefer chainable filters to any other transformation style I've seen.

arthurk 17y ago

I met Armin Ronacher (the author of Jinja) at this years EuroDjangoCon. He was actually hacking on Django's template system himself and closed one ticket after another (though he was told that he couldn't "just replace it").