Hacker News Reader

Comment by jnoller | Hacker News Reader

From some Rails/Ruby guys (who are also Django people) Rails, and the Rails community gets the same criticism, or at very least the same themes. Python core gets it too, etc, etc. Sooner or later Node.js will get it, and so on.

I think accusing the Django core as being incestuous attributes a lot more malice to what they say and do then is warranted. All communities have scaling issues, and all open source communities have growing pains.

The sad part about this is that people who didn't get "their thing" into core is going to use this as self-validation, even if the idea really was bad to begin with.

View on HN

It's a lot easier to get the 'top stuff' from the community to the top if it the core team is inclusive rather than exclusive.

The examples you give are from communities that have for the most part learned how to deal with those issues (python itself especially, in the talk GvR is actually quoted as having reversed his position on specifically that point).

Communities tend to be one or more orders of magnitude larger than the core team of most projects, and to disregard such an enormous pool of talent is a loss. So what if 90% is junk, let the community sort it out and come to a consensus on which things deserve to be part of contrib or core, and then respect that decision, unless there are really earth shattering reasons not to.

I know, I'm a member of python-core, and I was happy with the change. And Django core is here, and listening, and was in the audience of the talk.

It's growing pains - and even python-core, despite guido's recent change of mind, is still learning, and finding ways to reduce friction. Django core is listening, and will change. There's nothing much to worry about.

And if they don't, they die, and we move on (see, past python web frameworks, and other things which wander into the woods to die).

"The sad part about this is that people who didn't get "their thing" into core is going to use this as self-validation, even if the idea really was bad to begin with."

Most of what is mentioned in this talk are not that much of an improvement, non-issues, or all around horrible ideas.

The fact is though there are major issues with the framework (not mentioned in this talk), and much of it is due to how things are being managed at the moment rather than a lack of ready, willing, and able contributors.

What do you see as the major issues?

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.

lol

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.

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.

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.

No doubt, the Rails community has issues, although on the whole, it seems to me larger, more dynamic, and open. I saw the django issues as coming from the fact that it was tightly held for a specific purpose for a specific company for a long time.

People were generally really nice in the community. Some of it may also be the more introverted characters attracted to python.

Also, I have lots of friends who are django fans and I hope that django improves on all these fronts. The character of a community is both hard to quantify and hard to change.

The rails community has grown so fast and been so open that it doesn't even seem to have a specific character, which is something I quite like about it.

Some of it may also be the more introverted characters attracted to python.

Interesting observation. Ruby and Python do seem to attract somewhat different personality types. Functionally they're actually very similar.

Python limits what can be changed at runtime: Ruby doesn't. That in itself attracts more outgoing, adventuresome people, whereas Python is changeable enough to be flexible, but not unstable -- which attracts people more interested in stability and security.

Reply on news.ycombinator.com