Why Django Sucks, and How we Can Fix it [slides]

http://www.scribd.com/doc/37113340/Why-Django-Sucks-and-How-we-Can-Fix-it

by twampss • 16 years ago

208 105 16 years ago

scribd.com

j_baker2• 16 years ago

Aside from the title being a bit on the link-baitish side, this isn't too bad a set of suggestions.

jnoller16• 16 years ago

Well, that was the talk name, so I don't think it's linkbaitish :)

j_baker2• 16 years ago

Talkbaitish?

enjo• 16 years ago

Wasn't there a keynote at Django-con a year or two ago with the same title even?:)

mikeklaas• 16 years ago

You can't link to a talk?

weaksauce• 16 years ago

Anyone have any idea if the roadmap is going in the direction of smaller more focused apps? Maybe easier configuration of them as the way they are configured now is a bit awkward.

jnoller16• 16 years ago

If you want this, you have to get involved either on the dev or the users list, and advocating this. Eric was setting forth a set of suggestions to make things better; but it still takes manpower, which is more than likely missing right now.

matrix2• 16 years ago

Based on the presentation - and the evidence is pretty compelling - it seems the manpower is there; it's just that the core developers don't want it.

brianimmel• 16 years ago

I'm glad a talk like this is encouraged. How else are you going to move forward without a little humility?

jnoller16• 16 years ago

Yes, and I hope more people realize this, the Django community is good at this, and in large part, so is the wider Python community. It's one of the traits that makes me proud to be a member of it.

jnoller16• 16 years ago

For those that don't know, this was a keynote at DjangoCon, and was pretty well received. There's a common theme emerging from everyone that there are some warts, and that they can and should be fixed (both code-wise and socially).

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.

jnoller16• 16 years ago

I also need to point out: Even core committers here admit there are issues which need to be fixed.

Mod_daniel• 16 years ago

Do you know how long it will be before the actual video is up?

jnoller16• 16 years ago

Maybe a week or two at the most (I hope) - looking at the slides alone strips ALL of the context off of the talk, and results in serious confusion.

I wish he hadn't posted the slides; instead waiting for the video.

mst• 16 years ago

Of course. Those of us who're closely involved in a project can see areas of wrongness very clearly. I'll happily explain to my classes what I hate about the software I'm teaching them - doesn't mean I don't think it's still less hateful than the alternatives :)

jacobian2• 16 years ago

To add a bit of context, I suggested Eric as a keynoter and encouraged him to give this talk, so the idea that the Django core team -- of which I'm a member -- isn't responsive is bullshit.

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]

Locke1689• 16 years ago

One thing: I would consider Mercurial first, Git second. Python has a very close relationship with Mercurial already (obviously) and I find that Bitbucket is as good as or better than Github in the most important ways.

matrix2• 16 years ago

I'm so glad this presentation is getting attention. The presentation really nails it, and I can only imagine the well-deserved awkward moments it caused a few people.

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.

duke_sam• 16 years ago

If the Django community is so closed why are over a third of the attendees new to Django? If the community was closed and insular we wouldn't be seeing so many people who are at their first DjangoCon and who are eager to contribute to Django.

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.

unohoo• 16 years ago

I guess a lot of the initial slides are in terms of reusable django apps out there. While what Eric is saying is not wrong, I just think that its hard to enforce certain programming style on these app developers. Some of the apps are coded to be generic enough and can be plugged in easily, others not so much.

None the less, I dont see how / why this is django's fault ?

bigfudge• 16 years ago

I think his point is that, together with settings issues, the structure of apps makes it hard to make them generic.

aneth2• 16 years ago

I dumped django for rails after a brief foray, and even participated in the Pinax group at Pycon in Atlanta. This presentation hits all the major issues, and is particularly strong regarding community. Incetuous communities support personal interest over quality, and that's reflected in the mess of django core.

That said, the framework is not a terrible choice, just not mine.

jnoller16• 16 years ago

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.

jacquesm2• 16 years ago

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.

aneth2• 16 years ago

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.

orangesunshine4• 16 years ago

"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.

jawngee3• 16 years ago

Are they finally fixing their nomenclature?

jawngee3• 16 years ago

C'mon really? That's one of the most broken parts of Django ... a view is a controller, a template is a view?

andybak• 16 years ago

I suspect some people think it's more problematic to force web apps into a MVC pattern that was meant to describe conventional desktop apps.

jacquesm2• 16 years ago

The apps stuff is dead on, even Drupal does this better (but they have their own problems), the "Design decision needed" and "wontfix" attitude is another one of those 'signals to the community', for the most part the community is forced to patch the django core after each release in order to keep going.

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.

jnoller16• 16 years ago

Not all ideas are good ideas. Just like python-ideas threads that crop up, not everything belongs in the framework, and some things are better off elsewhere.

alttab2• 16 years ago

Where though? Django lacks and clearly defined interface for framework plug-ins, python eggs don't exactly ooze with win here...

orangesunshine4• 16 years ago

There already is a fork (django-experimental), though interest seems to be limited at the moment.

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.

jnoller16• 16 years ago

Isn't the logging system being fixed in 1.3?

cageface7• 16 years ago

The overwhelming dominance of Zope back in the day really held back the Python web development world and I worry the same thing is happening again with Django. Django could really benefit from a Merb breathing down its neck.

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.

alttab2• 16 years ago

I agree that the Rails model seems to be working well for them (especially since seeing Rails 3), but it always comes down to the accepted decorum of the community. Its really up to them.

zzzeek• 16 years ago

Django has plenty of not-so-alternative projects breathing down its neck and they're well aware they have to keep up. Personally I think it helps the rest of us to some degree for Django to be out at the front accommodating all the crushing masses of new users while smaller projects, not as quickly discovered (but discovered enough) enjoy moderate but well-tempered userbases.

varikin4• 16 years ago

I think there is plenty of other opinionated* people/groups in the Python web developer community to keep the Django community on their toes. For example, Flask which was mentioned in the slides we are currently discussing. Flask is from the same person/group that did Jinja, Werkzeug, and a couple other cool things. Pylons has a good user base and plenty of steam. There is also mavericks like Ian Bicking who wrote Webob and Paste (which Pylons is build on) who prefer the sans-framework approach because it is simple in Python to glue together the various libraries needed for a "framework".

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.

vosper2• 16 years ago

I've avoided Django on AppEngine due to the vagaries of the AE datastore, and the extra time and planning it takes to get things working efficiently; I'm wary about using any framework not specifically designed for AE. Fortunately the webapp 'framework' that comes with AE is quite usable, though not exactly feature-packed.

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.

wisty• 16 years ago

Zope seemed to have great people behind it, and was very solidly built, but it seemed a lot more monolithic, which ended up polarizing people.

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.

cageface7• 16 years ago

I've built a couple of small Flask apps and I like it too. Django doesn't really seem to have a direct competitor in the same sense that Merb was for Rails though. Merb and Rails provided a similar developer experience but had some significantly different architectures. Things like Pylons and Turbogears are much more roll-your-own than Django and microframeworks like Flask are great for what they cover but usually app requirements will dictate Django vs Web.py, for example, and not developer preference.

jnoller16• 16 years ago

Anyone can contribute to Django right now; just like anyone can contribute to Rails.

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?

varikin4• 16 years ago

I think the DVCS issue is not part of "what is wrong with Django."

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.

budwin• 16 years ago

I really feel what they said about the community and core developers:

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...

viraptor• 16 years ago

Someone has to make a decision and since here that person is a django-core developer, I'm not sure there's much to argue with. If they don't want to do that, bug will get marked "won't fix" every time it's created.

What else do you propose developers should do? I may disagree with this decision, but someone has to lead the project.

rohitarondekar• 16 years ago

How else will a core developer let it be known that this feature/issue won't be fixed? The "wontfix" tag/state is there for this very reason. And the core developers are there for this very reason -- to make decisions.

I'm curious though. Why not just fork the project and be more open in terms of getting patches in?

butterfi• 16 years ago

I'm surprised at how nascent the Django developer community is portrayed in the slides. I've spent a fair amount of time in the drupal community, which seems to have addressed some of the issues that are presented. (Please -- this is not a "Drupal" vs "Django" question.) I more interested in how we share development processes across projects. Given all that we've learned from the various open source communities (Apache, Plone, MySQL, etc), it would be interesting to develop a "project framework." Not a framework for code,or the management of it, but rather for the community around it. How to set up an event, how to encourage collaboration, etc. Is anyone familiar with anything like this?

rbanffy• 16 years ago

I think Django was started with that kind of "project framework" in mind. It's evolving and, like any project that breaks new ground (it's a metaproject in that sense) it's bound to hit a couple snags.

bsdemon4• 16 years ago

Django people should really look how it's all (configuration, reusability) done in Zope/repoze.bfg. The problems, mentioned in keynote was solved 4-5 years ago there.

zeemonkee7• 16 years ago

And what's happened to Zope since then ?

bsdemon4• 16 years ago

It's all ok with it — there are two successors — bluebream and repoze.bfg. I prefer the latter. ;-)

sandGorgon2• 16 years ago

What is the merb for the django world ?

Is it web2py, flask, cherrypy ... maybe even pylons ?

zeemonkee7• 16 years ago

More likely WebOb or Werkzeug. Maybe Paste.

ericflo2• 16 years ago

IMHO it's Flask.

jokull3• 16 years ago

Seconded. Flask is really awesome. The guy behind it (Armin Ronacher) is a beast of a programmer.

c00p3r• 16 years ago

Some big Django shop like Discus could create a team and sponsor the development. Something called Django2 Django-ng.

Without hype and stimulation individual developers are passive.

jnoller16• 16 years ago

Why not just have Disqus sponsor the DSF/Django core. Forking it is exceedingly short sighted.

intranation• 16 years ago

I pretty much agree with all of the points raised here about Django, and I've been using it professionally for almost 3 years. The core development team is incredibly hostile to improvements that don't fit some fluffy definition of where they see Django going, to the point where some of the best coders I know are incredibly discouraged from contributing patches or improvements, and just release their stuff on GitHub instead. That's the wrong way for an open source project to be, in my opinion.

jacobian2• 16 years ago

I'm really sorry that you found us to be hostile, and I apologize for any part that I played in that. I hope you believe that hostility isn't at all our intent -- in fact, I try very hard to be open to criticism -- so if you experienced hostility that's a failure.

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.

halo• 16 years ago

PDF link: http://dl.dropbox.com/u/277867/37113340-Why-Django-Sucks-and...

india2• 16 years ago

Is there a non scribd version of this pdf? Scribd says "all download limits exceeded from your ip" and won't let me download or read anything beyond slide 26.

simonsarris• 16 years ago

I have downloaded it from Scribd and put it on Google Docs publicly:

https://docs.google.com/fileview?id=0Bwm9XbY0OR2wZjc1YjQ3Mzg...

india2• 16 years ago

Thanks!

bobx11• 16 years ago

I like how the author keeps mentioning Flask - I've used flask and liked it a lot.

peterbe• 16 years ago

Major reson Django sucks much less than Zope3: There's "only" one way to do things.

Less is more. Choices lead to confusion. Let's continuing making the less even better.

edanm• 16 years ago

Great slides. As a relatively new and inexperience Django user, the points I found most troubling are the points on Apps, and the points on the Auth model.

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.

2mur• 16 years ago

It really is a great community. The django-user mailing list and #django on freenode are very newbie-friendly. I would recommend lurking on both and picking up a lot of best practices by osmosis, then asking questions when you get in a bind.

gawker• 16 years ago

As someone who just very recently began to use Django extensively, it seems like the issues mention do carry some weight. While Pinax is a great help in avoiding to reinvent the wheel, I have had to copy the app out of the package into my own to customize it. I'm not sure if this is prevalent in other frameworks but it didn't seem to be too much of a hassle. But of course, maintenance-wise it might create more problems.

Why Django Sucks, and How we Can Fix it [slides]

Related Stories