

Why Django Sucks, and How we Can Fix it [slides] - twampss
http://www.scribd.com/doc/37113340/Why-Django-Sucks-and-How-we-Can-Fix-it

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

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

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

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

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

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

~~~
singingwolfboy
If you're going to swap out everything, are you really using Django to begin
with? Why not just use TurboGears[1], which seems based on the idea of
swapping out standard components?

[1] <http://www.turbogears.org/>

~~~
cageface
Yeah, you lose the full-stack benefits of Django pretty quickly once you start
swapping out components. If I wanted a more customizable Python stack I'd pick
one that was designed to work that way from the beginning.

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

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

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

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

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

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

~~~
jnoller
Isn't the logging system being fixed in 1.3?

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

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

------
sandGorgon
What is the merb for the django world ?

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

~~~
ericflo
IMHO it's Flask.

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

~~~
mattdawson
Thirded(? Sorry, that's probably a bit too reddit-ish for HN.)

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.

~~~
sandGorgon
I'm kinda confused - from the homepage, it looks like Flask is Werkzeug plus
some extensions. Is Armin, the great thing about Flask ?

~~~
jokull
I and a lot of people trust his judgement and understanding of the problem
domain. Flask uses Jinja2 and Werkzeug (both awesome libraries, and again by
the same author and display an amazing understanding of what and what not to
do for the respective solution).

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

------
halo
PDF link: [http://dl.dropbox.com/u/277867/37113340-Why-Django-Sucks-
and...](http://dl.dropbox.com/u/277867/37113340-Why-Django-Sucks-and-How-we-
Can-Fix-it.pdf)

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

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

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

~~~
jnoller
I don't think it's that cut and dry - especially talking to all of the core
people (and near-core) here at DjangoCon, and even Django core is well aware
and willing to change, it's just not as easy as adding commit bits.

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

~~~
zeemonkee
And what's happened to Zope since then ?

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

~~~
zeemonkee
I like repoze.bfg as well. My point was that Zope has dropped in usage and
mindshare in the last 5 years, and the community was unable to prevent that
(for technical reasons, the Zope2/Zope3 confusion, easier frameworks like
Django, etc).

~~~
bsdemon
The problem with Zope is that it's not scale down to simple tasks. Repoze.BFG
can do that, but it's Django-time now, sadly...

~~~
zeemonkee
I think this is a major problem with Python (and Ruby, for that matter). Why
does it have to be an all or nothing ? Why "Django-time" to detriment of all
else ?

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.

~~~
jnoller
Actually, we're far from "one framework" - just because one has a lot of
mindshare doesn't mean we have like 30 of them floating around. Web.py,
Django, Repoze, Flask, on and on and on.

I think writing a python web framework is a rite of passage.

~~~
zeemonkee
I was referring to mindshare, and related jobs market, rather than the number
of frameworks.

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

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

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

------
unohoo
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
I think his point is that, together with settings issues, the structure of
apps makes it hard to make them generic.

------
jawngee
Are they finally fixing their nomenclature?

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

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

~~~
jawngee
By calling it something different, even though it's the exact same thing?

------
india
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
I have downloaded it from Scribd and put it on Google Docs publicly:

[https://docs.google.com/fileview?id=0Bwm9XbY0OR2wZjc1YjQ3Mzg...](https://docs.google.com/fileview?id=0Bwm9XbY0OR2wZjc1YjQ3MzgtYmNhYy00OTgyLWFjMzQtYWFmNTI5NDE2ZjAw&hl=en)

~~~
india
Thanks!

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

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

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

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

~~~
ericflo
Close. It was "Why I Hate Django" by Cal Henderson in 2008. He is way funnier
than I am: <http://www.youtube.com/watch?v=i6Fr65PFqfk>

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

~~~
jnoller
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_.

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

~~~
jnoller
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).

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

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

