The mess Django's in

I've only looked at a small portion of the underlying django code and from what I've seen there were definitely some complicated parts, but it was far from being messy. Perhaps the author is confusing necessary complication with messiness? After all, isn't the purpose of a high level framework to hide the messy details and allow you to express your ideas clearly and efficiently?<p>I have read and understood all of web.py and am currently buried up to my head in rails actionpack routing code, both contain some hairy bits of code. By pushing all these messy details down into the library they allow the application developer to be more expressive and concise. As long as there are tests, comments, and documentation to back up the complicated bits, I don't have a problem with a library or framework not being obvious to understand at first glance.

I couldn't disagree more that Django's code is horrible. In my experience (which isn't much to be honest), Django's code is a pleasure to read.<p>That said, I do think that a case can be made that Django's architecture has some definite warts. Whether or not they are a huge deal is largely a matter of opinion. For instance, I do agree with the author that Django does have a bit of an overreliance on import-time side effects. I particularly don't like the fact that I can't even <i>import</i> some parts of Django without having a settings.py defined. On the other hand, I don't know how difficult it would be to change it.

Not sure I could disagree much more with this. Firstly, I think the power of Django's inbuilt functionality more than makes up for whatever aesthetic problems there might be (I haven't checked) with the underlying code. That's a trade-off I'm very willing to take. Secondly, I'd rather go with messy code and an active bug-fixing and development team than beautiful code that no-one touches. Plus, there's no 'kool aid drinking' going on here. In fact there's surprisingly little razzle-dazzle about Django. All I know is that it helps me build what I want to build, fast, and the documentation is the best I've ever seen for just about anything.

I mostly agree with the author of the article: ever try to modify the User object to accept an email instead of username for login purposes? It's a complete hack.<p>The thing is, it didn't <i>need</i> to be a hack, but some of the core components are really tightly coupled together when they don't need to be, so it ends up being a hack. This tends to happen a lot when you 'go outside the box' of Django's codebase.<p>For example, everyone says you can 'use SQLAlchemy' in Django. On paper this is true. But then you lose the admin, the user auth system, the messages system, model forms, and all of the other batteries that make Django useful.<p>That said, the alternatives to Django are so incredibly lacking that (for the moment), I'd rather stick with Django than roll my own everything else. Pylons and Turbogears are an ugly mish-mash of third party libraries that don't work well together. In some cases there are good third party libraries (SQLAlchemy is indeed quite an amazing piece of software), but many other pieces are lacking:<p><pre><code> - Authentication/authorization libraries are terrible. (You want to bury that in the middleware layer and use query string parameters to indicate login failure? What?) - Nothing out there is as good as Django's model forms. - There is no equivalent to sorl-thumbnail, for basic image processing. - The boatload of third party Django apps. Yes, most of these are poorly written and not modular enough either but there are some really useful ones out there like django-pagination and django-compress. </code></pre> Django is far from perfect but unfortunately, taken as a whole, it's still better than the current alternatives.

It sounds like a lot of the complaints are about their ORM layer. I'll point out that Rails (a very comparable project) has a lot of cruft in ActiveRecord, their ORM layer, as well. I can't directly compare it to Django's, but it's a bit of a hairball. Some of it is just that it's hard to write a good ORM layer.<p>Let's hope that Django can also take a Rails 3-esque approach -- make the ORM layer modular, then use whichever you like. That's a surprisingly good way to disentangle the internals of the ORM from everything else. And once you do that, it gets a lot easier to polish up the code, or if necessary replace it with something prettier.<p>I imagine a fair number of the Rails 3 folks will be replacing ActiveRecord with DataMapper, for somewhat similar reasons. I plan to.

What? How about an example?<p>The Django code is concise, readable, and pretty modular. I rarely read the docs anymore; just browse the code. In fact, I feel like a better programmer for having read most of the Django code.<p>This appears to have been written today, but it reads like it's from 3 years ago.

ORMs are like sausages. You really don't want to know what goes into them.

SQL and Objects are a problem in the first place. SQL is optimized when working with sets. So unless simple one-record read/write, most queries should fall to direct SQL which is really easy to do in Django and in Python. And for the one-record transactions, the ORM does not really matter that much. Bottom line: SQL is an essential programming skill.

Just because you don't understand the code it doesn't mean it is awful. I am not defending django at all since I use webpy.<p>Saying the code is awful without proving why is just a way to explain to yourself why you are not understanding the code. It makes you relieved that it is not your fault. However it is your brain deceiving itself.<p>Blame it on yourself first then on the code.

Completely disagree. Most of Django's components are so simple that you can tear them out and replace them for your own thing. I've done it several times now and I never felt confused about it.

&#62;Even simple things like setting up and tearing down the database is awkward. You have to actually make an outside call to a command-line script to do it.<p>... Because I want to be able to do that WITHIN my webapp?<p>As a side note, I wish this guy would of pointed to some specific examples instead of speaking in generalities.

Google uses Django on its AppEngine, at least some parts of it. Seems that it is not so badly written.

Can't say I agree with this either.