• Why Django Sucks, Except When It Doesn’t

    by  • 8 June 2012 • Articles

    Ken Reitz is a smart man. Very smart. Smarter than me. He’s responsible for some of the best, most widely-used Python libraries out there. So when he talks, I listen.

    And recently, he talked about why Django sucks.

    Ken made some really excellent points. Among them:

    • Django is too monolithic, and so…
    • it encourages big, tightly-coupled apps.
    • Everything depends on the Django ORM, whether it’s front-end stuff like sessions or back-end stuff like data persistence.
    • Broad knowledge of the system is required.
    • All components get deployed together.

    He also had plenty of nice things to say about Django, but (and Ken, correct me if I’m wrong) the point seemed to be that we should take a page from Steve Yegge’s infamous rant and try to separate concerns (e.g. why do user sessions have anything to do with data persistence?) which means building smaller silos that talk over APIs (maybe HTTP, because it’s easy).

    These silos are easier to understand, can be deployed, scaled, and updated independently, provide more opportunities for fault-tolerance, and have a number of other advantages.

    So why on earth would you just use Django as-is?

    Because for a lot of people, none of that matters.

    If you’re prototyping a new project, or if you’re a start-up and need to ship something, or if you’re just one person working on a little app with a few (even a few tens of thousands) of users, odds are that none of those benefits are worth losing the nice stuff Django gives you, or the time it takes to build APIs (even using existing apps to do it) or abstraction layers between the silos.

    A while ago, someone tweeted something to the effect of “while you were arguing about Rails vs Django vs Flask vs Erlang, a bunch of people shipped with PHP.” That’s my sentiment here. 99% of the time, for 99% of web apps, the benefits of doing things the “right” way are just never going to show up. Start with the easy, fast way.

    Twitter is the perfect example. Today, the website is a web client that talks over APIs to the real messaging service and yadda yadda yadda, but on launch day, it was a Rails app, and, from the outside, it didn’t even seem like a particularly clever Rails app.

    Django (or Rails, or even Flask with some packages from its ecosystem) gives you a lot in the box. Unless you know that you’re launching to millions of users, it’s OK to take that box and start building.

    If you end up in a place and at a scale where that’s technical debt you really need to pay off: congratulations!

    • http://www.domenkozar.com Domen Kožar

      What most readers realized from the talk is only shameless plug of Ken to promote Heroku as an alternative or more abstractly the service approach.

      However the message is that sooner or later components of Django are not enough because of various decisions they take, you start scratching them out. Later you realize Django is a burdon to your development and you should use something else. Maybe service approach or flexible framework as Pyramid. In other words “best tool for the job”.

    • http://jamessocol.com/ James

      I think Ken did make some very fair points–having only read the slides and not the talk–about the disadvantages of monolithic architectures.

      However the message is that sooner or later components of Django are not enough because of various decisions they take, you start scratching them out. Later you realize Django is a burdon to your development and you should use something else. Maybe service approach or flexible framework as Pyramid. In other words “best tool for the job”.

      I think your assumption here is that “sooner or later” you will have these problems. I’ve run a moderately successful little app (TodaysMeet) for 4 or 5 years without it ever growing to a point where a more complex and robust architecture is worth the time and effort. (It averages around 10k uniques/day, and has… at least since its NYTimes mention [shameless].)

      But assuming that you will have to do make those decisions is a form of pre-optimization, and a potentially very costly one.

    • Federico Mendez

      Plus… Django does scale (http://stackoverflow.com/a/886645/741933). Sure, maybe it won’t be as naturally as if you rolled everything you needed from the ground,… but it doesn’t make it an inadequate tool for 98% of the websites/apps (aka: most of the apps that won’t be getting +100k a day)

    • http://jamessocol.com/ James

      Django absolutely scales. One of my recent talks was about building really big sites with Django at Mozilla. At the very edges, you may have to strip away a bunch of the framework (we do) you still get well into Alexa Top-500 territory, traffic-wise, before that happens.

    • Pingback: Actually, everything sucks. | Matt_ptr *

    • http://farmdev.com/ Kumar McMillan

      I dunno, I think Django actually encourages a healthy separation of concerns. In fact, unlike Flask, it forces you to separate your project into smaller components. You don’t even get a choice. It’s easy to plug in other apps from the community. It’s not so easy to rip out the core building blocks of Django but if you’re forced to do so you can make it happen.

      I worked for 3 years on a Pylons app and, you know what, pretty much everything had to be built by hand or you had to write custom glue to use this one library over in this one non-standard part of your project that you hacked up willy nilly. Every time you had to add some new feature you had to make all these decisions on how to do it. When you looked it up in the docs you saw some hack of a solution and when you asked on the mailing list the reply was “no no no we don’t do it like that anymore, here’s a better way.” Compared to the quality, docs, and flexibility of Django, Pylons was terrible for productivity. (Granted, I hear Pyramid solves a lot of Pylon’s problems.)

    • http://jamessocol.com/ James

      @Kumar: I think building the same application as a single Flask app or as a single Django app, you’re right. In fact, I don’t even know how to build big Flask apps. How do you separate out components like you do with Django? Just… lots of modules? Install everything in the same virtualenv?

      Which is kind of the point, I guess. Flask (or other small frameworks) would really encourage you to write a bunch of apps that talked to each other over HTTP instead of importing each others’ models.

      But importing each others’ models is a much faster way to get a product built. It’s why Mozillians Phonebook and Taskboard were originally apps in the same Django project.

      Talking over HTTP (or whatever) APIs lets you swap one of those apps with Erlang, or Ruby, or just different Python, if you need to, later. Which I call pre-optimization. 99% people are never going to need to swap a Django app for an Erlang process. And if you do, congrats, go do it.

    • Pingback: High MySQL CPU Load Today? Quick Fix « Coffee on the Keyboard

    • J

      Grails is even better than Flasky, to me, after reading. Maybe web2py is similar to Flasky.

      But Flasky seems just a PoC.

      Cherrypy+SQLAlchemy+DB+Python offers the same.

    • J

      I meant for webservices. Since in the video flasky is recommended for webservices.

    • bedrockq

      You should ask all those people who picked Pylons over Django back when Pylons was the new shiny object what they think of that decision now. Pylons is dead ended and there is no straight forward upgrade to Pyramid.

      Pyramid is run by the same people who abandoned Pylons as far as I can tell. Think about it. I know it made my decision to stick with Django that much easier.