Why Django Sucks

I think something the author didn't really cover was upgrades. When elements are highly decoupled, it's easy to go and upgrade piece by piece. API changes can be factored in and dealt with relatively easily. (I believe this is something Amazon did right as well..)

I know this for a fact because upgrading a massive django deployment from 1.1 to 1.4 was a huge project for us.

That said, I still love all the out of box defaults that django provides and the fact that extending them is relatively painless as long as you spent a few years learning the ins and outs of the system ;)

Out of curiosity, what kind of shape is the average Rails app in after a few years?

While it is true that Django may be quite a large framework, a 'kitchen sink' in a way, I feel that many people often miss the point of what a framework is, in that you don't have to use all of it.

In my few years of developing in Django I have had my frustrations and joys, many of the frustrations coming from the idea that I should do things how the framework wants me to, only to realize that it is still python that I'm writing code in. The idea of Django is not to be some utopian framework where all of your pythonic dreams come true, it is to enable you to build applications quickly and with ease.

While Django may have been created to be a publishing platform, our primary use for it is a genetic analysis application, which is complicated enough without having to worry about the framework, and trust me, Django is not anywhere near a problem in the app. We also use Django for a separate report delivery system, which has API endpoints and is constantly being fed data from 3 other applications, and again, Django has never been an issue.

Sure, you can roll your own libraries with something small like Flask, and reinvent the wheel many times over, but do you actually get features rolled out? Or are you constantly patting yourself on the back for keeping such a small codebase while maintaining a home-grown system and hoping you can get a feature out the door while fixing all of the bugs that not only the system may have introduced, but your features as well.

Here are my biggest worries of a very customized/home grown framework: 1) Does the knowledge of the framework transfer to the next project you work on? 2) Are you writing documentation so that the next person can understand the code? If so whats the time cost for that? 3) Are you spending more time building the perfect system or rolling out features?

Don't get me wrong though, I love working with small polished libraries and connecting them together, namely in node.js, but it is entertaining more than productive.

There's humor, and there's LCD pandering. Despite that, this submission did get me to try out Flask. Nice and straightforward to get started with, which is good because I'm stupid.

I'm yet to see a Django based website that outgrows any old rdbms for auth. Care to back up your claim that it's bad? Same for admin. You do realize that Django's admin is just a search result of objects defined in its ORM, and that objects defined in its ORM are very obviously stored in an rdb - right? What would you like admin to use for managing data stored in an rdb? There's barely anything other than the models being managed that touches the database.

Edit: just before my comment gets skewed, my question is: why would you ever use django for a website big enough to warrant this sort of worry? Let's recap: big websites make money which is used to hire coders. Those people are at that point probably porting your website to Agda, or some other cloudscale technology. Sounds like you're the same kind of person who complains that Bash doesn't support OpenMPI and that JavaScript doesn't do fib() well enough and that this here carpentry hammer can't break diamond. Wrong application, dude. Django is for medium-small websites, not for your Cloneddit, Clonebook, CloneSpace, or news.yclonebinator.com; get a different hammer.