[pmclanahan]

That's the impression I got as well. He didn't seem to "get it." I can't see complaining about Django being poorly decoupled, only to then go on to describe how little of it you're still using. How tightly-coupled can it be if you're only using small pieces?

Also, it seems like a lot of the complaints are about contributed apps like authentication and the admin. It seems to me that he never really tried to learn the admin, or was using a very old version. And you don't have to use authentication at all, you can completely write your own, or fork the one that comes with it and make it work for you.

But the main thing that bugs me is that he obviously doesn't get opensource either. If you think you have a better way, get on the mailing list and suggest it, create a ticket, or implement your changes and submit a patch. Writing your own stuff, not releasing it, and complaining on a blog doesn't help anyone.

[ubernostrum]

Well, with auth I think there's an easy confusion to fall into, because we conflate a couple things:

1. The default backend stores information through the User class, persisted to the auth_user table.

2. All backends are required to return instances of User when asked to find the user who matches a given set of credentials.

So in the first case, we use the User class as a persistent object store. In the second case we use it as a consistent API implemented by records coming out of auth backends.

Where the confusion comes in is people assuming that, since you have to return an instance of User out of your custom backend, you must also have to persist that instance to the auth_user table. Which isn't correct; you're free to just chuck information into an instance on the fly, and Django will neither know nor care (third-party code may make bad assumptions about being able to save that object, but third-party code should be introspecting to find out where the object came from before trying that).

Any rate, this is on my list of things to document more completely, and hopefully that'll help.

[mrshoe]

While I agree with the premise of this comment, I'm not sure it necessarily applies to this specific situation.

Web frameworks do their best to provide useful, general abstractions for writing web applications. Sometimes you need different behavior on a lower level to which the framework provides no interface. In other words, your particular application breaks the general mold in some way. It doesn't necessarily make sense to change the framework for each of these application-specific needs. Writing those portions yourself and not contributing them to the project seems like a sensible way to go.

If the framework is really trying to work for the entire universe of web applications, it will quickly become too bloated to be useful for getting simple, common apps off the ground. As a framework maintainer, you have to strike a balance between the set of applications that your framework can accommodate and the usability of the framework.

That said, the author's tone does seem to suggest that Django is doing a poor job as a web framework because it doesn't fit his needs. That's an unfair criticism. Django fits a lot of people's needs. It's not supposed to be all things to all people.

[snprbob86]

The admin is bar far the biggest offender of tight coupling: primarily to authentication and the ORM. Being "contributed" isn't an excuse. Everything is "contributed". It's open source!

I haven't got time to actively participate in Django's development. Especially because I'm not particularly interested in the details discussed on the mailing list and I've already found components I'd prefer to work with (and, by extension, contribute to). I've got a product to build. I took some time to write down my thoughts and the key contributors are welcome to read my rant, ask questions, and learn from it.

[jbronn]

Open source software is not a one-way street. If you had spent as much effort on this gripe post as participating in the community (or even reading the docs!) then you would have had the answers to your questions rather than having to roll your own framework.

[jasonkester]

But now he has something better than django that he can use on his next project. It works well for the kinds of projects he builds, and does what he expects. He wins.

There's no reason to contribute it back to the community, because it's specifically targeted to his needs (and therefore wouldn't be considered better by anybody outside his team). Spending even an hour polishing it up for somebody else's consumption would be a distraction.

[turtle4]

But if he would contribute back, then -everyone- would have something better than the (current) django. That is how it works. I agree with grandparent poster that more people should take the time to contribute and/or make their changes available.

That said, at least he documented things and presented his issues cogently so that the dev team can see where issues are, and possibly address them in the future.

[jasonkester]

Not likely. I'm a big advocate of rolling your own framework that meets your (and only your) needs.

The thing we use at Expat is incredibly fast and turns out really good code. It's the reason we can move so fast, and it's a competitive advantage. But I wouldn't release it to the world.

It just has too many optimizations for the way we like to do things. And there's still the matter of the order-of-magnitude gap in level of effort between something you use in house and something you can release as a product.

Right now, this guy has something stripped down to the bare essentials to do what his shop does. Ideally, he's shed all the useless garbage that naturally accumulates in any commercial framework the size of django. And as a result, the final product probably isn't of any use to anybody outside his team.

[eculver]

If I could vote this comment up a thousand times I would.