Why Django Sucks, and How we Can Fix it [slides]
scribd.com
scribd.com
Eric's slides should not be taken on their face as a damnation of Django; rather Eric likes Django, and simply wants to make it better.
I wish he hadn't posted the slides; instead waiting for the video.
In fact, we've had a "what's wrong with Django" talk at every DjangoCon -- the first had two, actually: Cal Henderson's hilarious talk, and Mark Ramm's incredibly insightful analysis of how Django can avoid some of the mistakes Zope made.
It's a bit of pet project of mine: I'm firmly convinced that we need a steady stream of constructive criticism. I unfortunately wasn't able to attend Eric's talk, but the slides have some great and valid points, and I suspect the video will be even better. Many of his conclusions (and the points made here) make me uncomfortable and unhappy about the status quo, and that's exactly the point.
If you look over the history of the "what's wrong" keynotes, in most cases the issues raised get fixed in the next release or two. For example, past "what's wrong" keynotes have complained about a lack of multiple database support, the weak "if" template tag, and puny CSRF protection -- all things fixed in Django 1.2.
So look, y'all can look on this as a set of complaints, or reasons not to use Django, or whatever the heck you want. To me, it's a todo list.
[edit: typos]
The Rails core team and the dev process is totally open and the DVCS-centric model makes it really easy for anybody to jump in and contribute. I can't see why this wouldn't work for Django too.
Plus the addition of AppEngine with doesn't play nicely with Django due to BigTable means people look at other solutions.
Also, the Django community, especially some of the core developers do seem to respect the opinions of these other people and groups. I have seen in mailing lists and IRC where core devs agree that Django to a wrong turn here or there, but correcting that turn is a slow process. Overall, I think the philosophy of "Do it right, not right now" is a great one, and it needs to be considered with correcting mistakes.
Opinionated may not be the best term, but it is close. I really mean people that are vocal, that are respected in the community, and groups or projects that great support and communities.
*There are ways to use Django with AppEngine but all have issues. Also, AppEngine now has some sort of SQL support, but I haven't looked into it.
Perhaps I'll look at Django on AE again in the future, once I have a better understanding of how to build things correctly.
EDIT: I don't think the advent of App Engine should have a major effect on Django development; my general thought when developing AE projects is to wish I was using a real server, one under my full control.
[1] http://www.allbuttonspressed.com/projects/djangoappengine
Django really benefits from the ability to swap out everything. People who hate the default libraries just find something better to use.
No migration? Use South. Some people run Django on Twisted or Tornado. There are different template libraries that people use. I'm not sure if the model layer can be swapped out so easily (without messing around with custom user authorization), but there's nothing to stop people using django models for authorization, and a separate database interface (even a no-sql one) for other data.
Only a group of core maintainers can merge those contributions into a core, shipping release. So how does the DVCS make that core think, work or release any differently?
Like you said, anyone can contribute, and core developers will be responsible for reviewing and integrating those contributions, regardless of the VCS. There are even unofficial mirrors on Github and Bitbucket if someone wants to go that route.
All that said, if Git or Hg (or other DVCS) would make some of the developers tasks easier, like reviewing patches (in the form of pull requests on Github), managing branches, tagging releases, etc, I think it is a worthwhile switch.
Edit: Changed core developers to developers in the last paragraph/run-on sentence because it might benefit all contributors.
They may be perfectly comfortable with their current tools - we agree though, this is not a source control issue. It's is a personnel, and social issue. DVCSes are not magical, and github isn't a cure-all.
If the problem is with the people; we have to fix the people, get new ones - not change the tools.
If you can, could you point to any specific moments -- mailing list threads, blog posts, responses on HN, IRC conversions, whatever -- that you felt to be hostile? I want to learn from my/our mistakes. Please feel free to post 'em here, or if you don't feel comfortable doing private email (jacob@jacobian.org) is fine, too.
All the issues are big, but those that touch on the nature of the closed nature of the Django community are, I feel the most important criticisms. A project like Django cannot scale effectively (in terms of pace of innovation, willingness of people to contribute, mindshare, etc) unless they address the community issues they have.
The current setup is not perfect. The core team, especially Russel, have been very forthcoming about this. They are openly talking about things that need to change and how to change them.
It's a pity, django could go a lot faster than it does. I would not be surprised at all to see a mambo / joomla style fork happening to django if the core team does not heed these warnings.
There has been limited work on it. Essentially I just fixed the demented logging system... though I will probably fix the demented templating system, and ORM in due time.
Is it web2py, flask, cherrypy ... maybe even pylons ?
I've been developing with Django for the last two years (a screencast series by ericflo is actually what got me started), and I just recently started work on a major Flask project. Flask is terrific.
What Armin is doing with his curated extensions gallery is one of Flask's biggest strengths. You get all the awesome flexibility of a no-batteries-included architecture, but with a great set of fallback tools if you just want to get up and running fast.
Not to mention SQLAlchemy is just a ridiculously awesome piece of software, and it integrates with Flask very well.
I also think that getting started with Django is harder than it could be. There are a lot of things you're forced to do, and decisions you're forced to make about how to structure your code, that should be made for you. For example, reading thedjangobook, several times the authors tell you "you can put that code in this file, or in this other file, or maybe do it like this". As a new user, you want there to be a consensus on code structure, and for that consensus to be forced on you: one less thing to worry about.
One point I would like to mention: I haven't taken part in the Django community at all, but if jacobian's comments to this thread are any indication, it looks like it's a great community. Seems to be a really helpful and open person.
The PHP community seems to be happy with a rich ecosystem of frameworks offering different approaches to problems - from Drupal and Wordpress, through Symphony, Zend, CodeIgniter etc. Maybe it's because Python is such a smaller community, but it's a shame there has to be one-framework-to-rule-them-all (yesterday Zope, today Django).
Different frameworks offer different approaches and suit different projects. As Python developers we should be much more open minded.
I think writing a python web framework is a rite of passage.
Reading the correspondence on the following bug really turned me off to the project. http://code.djangoproject.com/ticket/5172.
Specifically: "Please do not reopen a ticket that's been marked "wontfix" by a core developer;"
I'm not sure how the issue jives with the whole Django philosophy, but with that much interest in changing the templating language, I found that a bit harsh...
What else do you propose developers should do? I may disagree with this decision, but someone has to lead the project.
I'm curious though. Why not just fork the project and be more open in terms of getting patches in?
Less is more. Choices lead to confusion. Let's continuing making the less even better.
None the less, I dont see how / why this is django's fault ?
https://docs.google.com/fileview?id=0Bwm9XbY0OR2wZjc1YjQ3Mzg...
That said, the framework is not a terrible choice, just not mine.
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.
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.
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).
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.
Interesting observation. Ruby and Python do seem to attract somewhat different personality types. Functionally they're actually very similar.
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.
The ORM has quite a few failings. Granted I like the API, though the backend code is nothing short of a cluster-fuck.
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.
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.
> not for making queries like other templating systems
WTF ?
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.
Without hype and stimulation individual developers are passive.