Hacker News Reader

Comment by teilo | Hacker News Reader

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.

View on HN

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.

Poorly documented?

http://jinja.pocoo.org/2/documentation/extensions#module-jin...

I agree that the parser API is not exactly pretty - but creating your own tag starting from that example is pretty straightforward. I have created many tags myself (mostly the standard case of mutating the enclosed content in one way or another) and can't complain. It took me literally minutes to get my first tag working - perhaps you are referring to an older version of jinja?

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.

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.

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.

Also, you can't have multiple inheritance with Jinja2. That's a showstopper for me.

Reply on news.ycombinator.com