Hacker News Reader

Comment by orangesunshine | Hacker News Reader

The templating engine is around 10 times slower than similar competitors.

The ORM has quite a few failings. Granted I like the API, though the backend code is nothing short of a cluster-fuck.

The template engine isn't that slow anymore, and it's easy to swap in Jinja2.

The ORM also works quite well for what it does. It doesn't allow you to construct real SQL queries and non-existant objects, but that's it.

Jinja2 is indeed much faster and offers a more flexible expression syntan than Django's template engine. However, Django's native template engine has one huge advantage right now - when there is a syntax error in the templates, it almost always gives informative errors the correct location. Jinja2, as it is right now, often gives no errors and completely wrong locations for the problem. This has been a serious disadvantage for me when dealing with more complex templates. This is surely temporary, but is the state of affairs right now.

The speed of the template engine isn't really the problem (it's unlikely to be a major bottleneck anyway, compared to database operations).

It's the restrictiveness compared to e.g. Jinja2 or Mako. With those engines, I can just drop in a Python function and be done with it; with Django template engine you end up writing tons of template tags for the simplest things. It's designed for a particular work environment (designers work on templates, so should not be allowed to do anything dangerous) that I've found to be quite rare in most projects.

I think if your writing more than a couple template tags and for simple things you're doing it wrong. I would really limit templates to being primarily HTML. Put any advanced python functionality in your view function, Django templates are minimal and not for making queries like other templating systems (a good thing IMO). If you need to do anything crazy advanced like recursively display stuff for items, don't write a template tag, use a simple include tag to insert HTML for subelements. Using the include tag when possible is also great for AJAX, as you have the HTML for a subelement sitting in a file if you want to render just that to return to a XML request.

OK, come back when you have done something moderately more "crazy advanced" than recursion.

> not for making queries like other templating systems

WTF ?

I was not implying that the concept of recursion is at all advanced. I was implying that the problems to be solved in the template layer are very simple.

I won't be able to come back to you because it would be too inefficient doing something more advanced than that in the template layer. Because rather than write the python to write template syntax to be interpreted back into python, I simply wrote the logic in one-pass python in the view function. It's more direct, runs faster, and your templates are clearer to designers if you're working in a group project.

lol

I've also never seen a project where the templating engine was a noticeable part of performance. I did see one where the decision was made to switch to Jinja2 which brought a huge amount of work duplicating a bunch of existing Django template tags – which didn't make much of a difference in the face of the 8,000 database queries needed to generate a page.

I have a friend that runs a popular music-related startup and template rendering has been their #1 bottleneck.

If template rendering is your major pain point you have either an amazingly well tuned system or are doing something very very wrong.

This is definitely an extremely well-tuned system.

Reply on news.ycombinator.com