Blog of Jeff A blog about programming and random other things.

9Feb/10link

Django’s Flaws

This is a response to Brandon Taylor. It was a bit lengthy, so I thought a post would be better off.

Like you, I felt this "poor" design pain from Rails. The less then spectacular docs (although that's changing too) made me prefer Django over it.
With that being said, the settings.py of Django is a crutch. There's quite a bit of needless configuration: You need to set template directories, installed apps, etc. While that's less than Java, why can't there be some reasonable defaults? Make template point to a local 'templates' subdirectory; default directory for media files; default to sqlite3 database config; time-zone defaulting to your computer's time settings; etc.
No migrations. Sure there are third party, but an official version would be nice. Most projects would be greatly aided by such a feature.
Django's reverse URL lookup system (for templates) is a pain. Besides the fact that the {%url%} is usually long with all the parameters (imagine a date-based a blog post URL). get_absolute_url in models seem dirty and hackish, but it's a lot shorter. Rails' routes provides this style of url referencing (by model instance).
Why no JavaScript integration with Django? Sure you can say it provides free choice, but that's why Rails has an advantage: it's not using the best javascript framework, in my opinion, but something is better than nothing. It's far easier to write simple javascript code through Rails then it is in Django.
Tying along the JS issue, is the templating problem. How would one go around supporting themes? What about different templates based on the incoming client? This has to be manually handled by custom-view code. Rails supports this pretty simply.
Django's admin is particularly amazing; however, it's more towards data entry and site admin (hence the name) but not regular usage -- it's not designed for web apps which have users "managing" their own content: for that you want to create a polished experience for the end user. Validations for both frameworks are done through the model.
Recently, the admin interface has gotten a lot more extensible, but it's still designed for the site admin in mind. While Rails' scaffolding isn't great, it's closer toward user-generated content, you're improving the design on behalf of the end user going to see it. Writing basic HTML for this stuff is pretty repetitive if you ask me.
If you like the argument from more of a Djangoist, I'll refer you to one of the creator's of Django.
http://simonwillison.net/2009/May/19/djng/
I've shared many of his pain points.
But Django's documentation is second to none in comparison to any open source project. Django's querying system through models is also great in comparison to Rails -- something that Rails 3 is also going to deliver.

Like you, I felt this "poor" design pain from Rails. The less then spectacular docs (although that's changing too) made me prefer Django over it.

With that being said, the settings.py of Django is a crutch. There's quite a bit of needless configuration: You need to set template directories, installed apps, etc. While that's less than Java, why can't there be some reasonable defaults? Make template point to a local 'templates' subdirectory; default directory for media files; default to sqlite3 database config; time-zone defaulting to your computer's time settings; etc.

No migrations. Sure there are third party apps, but an official version would be nice. Most projects would be greatly aided by such a feature.

Django's reverse URL lookup system is a pain. Besides the fact that the {%url%} is usually long with all the parameters (imagine a date-based a blog post URL). get_absolute_url in models seem dirty and hackish, but it's a lot shorter. Rails' routes provides this style of url referencing (by model instance).

Why isn't there JavaScript integration with Django? Sure you can say it provides free choice, but that's why Rails has an advantage: it's not using the best javascript framework, in my opinion, but something is better than nothing. It's far easier to write simple javascript code through Rails then it is in Django.

Related to the JavaScript issue is the templating problem. A view function usually only directs to one template. How would one support themes? What about different templates based on the incoming client? This has to be manually handled by custom-view code. Rails' render_to dispatcher in the controller makes this a lot easier.

No doubt Django's admin is awesome; however, it's more towards data entry and site admin (hence the name) but not regular usage -- it's not designed for web apps which have users "managing" their own content: for that you want to create a polished experience for the end user. Validations for both frameworks are done through the model.

Recently, the admin interface has gotten a lot more extensible, but it's still designed for the site admin in mind. While Rails' scaffolding isn't great, it's closer toward user-generated content, you're improving the design on behalf of the end user going to see it. Writing HTML isn't fun -- for me at least.

If you like the argument from more of a Djangoist, I'll refer you to one of the creator's of Django.

http://simonwillison.net/2009/May/19/djng/

I've shared many of his pain points.

But Django's documentation is second to none in comparison to any open source project. Django's querying system through models is also great in comparison to Rails. Rails 3 intends to copy Django on that respect.

The merb probably slowed the progress of Rails in the recent years.

  • Share/Bookmark
Tagged as: , , Leave a comment
  • imanc
    I too am glad that Django doesn't come bundled with a JS framework, and find Rails integration with Prototype off-putting.
  • Although rails comes bundled with prototype, the next rails 3 decouples this allowing drop-in replacements of jquery or any other js library.

    That being said, I still prefer python over ruby.
  • roopeshv
    I feel django developers have conveniently followed 'import this'. and sometimes sticked with the line 'practicality beats purity'.
  • Are you saying that Rails is more "pure" than Django? How so? Rails is a Domain-Specific-Language.

    Django is very Pythonic. Rails, is not at all pure Ruby.
  • roopeshv
    I am only talking about Django, I haven't used Rails yet.
    here is briefly what I feel how Django has made choices it made.
    (Referring Zen of Python)
    1) Explicit is better than implicit:
    like settings.py requires few explicit settings as to what template directory, what modules. They could have also done so with some magic, by choosing some defaults.
    2)Special cases aren't special enough to break the rules. Although practicality beats purity.
    like choices use magic because that eases some development use cases.
    etc. etc.

    These are some of the conclusions I came to. But I still think both Django and Rails are good.
  • First, everything that follows is simply my opinion, having used both frameworks over the past couple of years.

    I don't consider settings.py to be a crutch at all. It's infinitely easier to use than setting up an Ant script. For me, settings.py is a good compromise between Rails' "magic" and something like Ant.

    South (migrations for Django) are better than Rails' migrations. Why should I have to define fields not only in my migration, but also in my model? That isn't DRY. South takes a look at the model and offers the same functionality, in a more efficient way.

    Again, I don't feel that reverse lookups are a pain at all. URL patterns can have a name. You have to supply parameters to Rails' link tags as well. Being able to call reverse and hand it a name, *args, **kwargs is quite simple.

    Why is not being tied to a JavaScript framework a bad thing? Convenient, yes, but Django doesn't consider that to be it's job, at least not at the moment. I would prefer that JavaScript integration with any framework stay out of Django. It's more agnostic and flexible that way. RJS is a great feature of Rails, but if writing JavaScript proxies through Ruby isn't hackish, I don't know what is.

    A view can return whatever you want. Which template to return can be a variable. It is pretty trivial to return different content based on the incoming client in a Django view, or across all of your views.

    Rails scaffolding is absolute trash compared to Django admin. Rails form handling is about as bad. It just NOW has nested forms - oy vey. I don't see how you can say that Rails scaffolding in any way improves user-experience design.

    All that being said. I think Rails has some good ideas, but I've had far more success and my clients have enjoyed a much higher ROI on their sites thanks to Django. The dev cycle is so fast, and Django's admin kicks so much ass for 90+% of what I need to do. Of course there are exceptions. Of course there are instances where it doesn't do everything.

    Django isn't perfect, but in this developer's opinion, it's hands-down better than Rails.
blog comments powered by Disqus
« Moved Clojure »

Recent Posts

Topics

Archives

Following

Links