Reasons not to use Django

Question

Have you considered using Django and found good reasons not to do so?

Answer 1

I personally don't like Django's ORM at all, and usually opt for SQLAlchemy if I choose it for a project. Also, I'm not sure if it's still an issue, but not being able to delete multiple items in the admin panel really ground my gears sometimes!

Answer 2

I have used it for a small website.

Since you're not asking for pros, here are some cons:

• It takes a while to get the hang of it, to figure out what goes where, etc. (But I suppose that this is the case with all web frameworks.)
• The template language is pretty restrictive. For example, you cannot check for arbitrary expressions, so you end up having some presentation code mixed into your Python business logic after all.

Answer 3

Django 1.0 has just been released.

Before, they were stalling at 0.96 from... March 2007 The Django Project itself was recommending to use the 0.97 version available from subversion... Needless to say, 0.97 was already not backward compatible.

Django is an awesome framework but a lot of people saw their code brocken with sometimes unnecessary changes.

We can however hope that the API will be somehow frozen with 1.0.

Answer 4

Because Cal Henderson told me not to.

My answer was somewhat tongue in cheek, but Cal Henderson gave an hour-long, funny, insightful talk about Django and where it may fall short.

Answer 5

Yeah, I am an honest guy, and the client wanted to charge by the hour.

There was no way Django was going to allow me to make enough money.

Answer 6

There is no any reasons not to use Django. Anyway, it depends from your project.

Answer 7

To me, the most serious competitor seems to be TurboGears. TurboGears isn't as all-inclusive as Django. You can pick your own ORM (default is SQLObject) and your own templates (default is Kid). I'd try to use SQLAlchemy and Mako, myself.

The distinction is that Django didn't (in older versions) have a proper WSGI pipeline for processing. Django's view functions are not very WSGI-like. Django can, however, plug into a WSGI pipeline. TurboGears and Pylons are more aggressively trying to incorporate WSGI into their frameworks.

For some kinds of web services, a proper, simple WSGI pipeline might be better than the Django-REST interface. Indeed, the Django-REST interface might not really save any coding when you get to more complex authorization tests and complex POST processing applications.

I'm starting to rethink our use of Django-REST, since I've had to apply a fairly large number of patches and extensions for our fine-grained authorization model.

Answer 8

I built the first generation of our internal web site using Django and at first it worked well. But over time I kept finding myself trying to work around its constraints and finally decided to move off of it. We now use CherryPy with Preppy templates and no ORM.

The problems started with the ORM and the inability to do any kind of useful aggregation. We are a financial company and need to do lots of reporting of detailed financial data, typically aggregated up in various ways. Because Django's ORM didn't support the things we needed to do, we started doing more and more direct SQL. But when you do that, other parts of Django don't work as well, like the templates. Pretty soon I found I was mostly using Django for it's URL mapping and very little else. So that's when I decided to look for something that was more of a library (choose the APIs you want to use) then a framework (fit your problem into the framework's way of solving it).

Some problems fit Django nicely (I wrote my first blog and that worked well) but it's not a good fit for every website out there.

Answer 9

The strongest argument leveled against Django at our organization -- which was previously a PHP shop -- was that it would be harder to find Python/Django developers in the future if any of us ever quit than it would be to find PHP devs. That's a business reason, not a tech reason, but it was a tough one to argue with the management.

Fortunately we were able to make a strong enough case that Django would solve so many of our current problems, in ways that would allow complexity to scale without creating rat's nests - that we won that argument and became a Django shop.

Answer 10

I am a big fan of Django, but I've found that as a project grows you quickly hit the resource constraints (mostly memory usage) of the few shared-hosting packages that support Django. This is a non-problem if your customer is ready to go to a dedicated server. But then you have the problem that a managed dedicated server means that you don't get root access, which often means you are stuck with the versions of things (Python, MySQL, Apache, Django, etc.) that the hosting service feels comfortable with. (Yes, this really is a problem.)

That means you end up on an unmanaged dedicated server (or VPS), and that means that your customer has to sign up for all of the ongoing, sysadmin-y things that go with it.

Because of this situation I still use PHP for most of my smaller customers.

Answer 11

I love Django. I think it is great for big projects, but for small ones the learning curve can be prohibitive compared to other python frameworks.

But once the learning curve is over, django becomes a nice option even for smaller projects.

I have my personal reasons for going with different python web frameworks listed here.

Answer 12

I've used Django for a small site.

• Personally I don't like its template engine, I'm a big fan of Mako templates. That's why I've changed template engine to Mako.
• Maybe it's not issue anymore but its ORM automatically adds Integer as primary key which I had to find a way to use UUID as primary key.
• Slugify wasn't working properly on unicode strings.
• It's not ease to use stored procedures with Django.
• Querysets are confusing. For me it's more ease to view the SQL query than looking to somekind of a Q object.

Answer 13

The only piece still lacking for me in Django (as of 1.0) is a definitive guide to using form and formsets combination with and without models.

The amount of time it takes to wrap your head around all the logic and special cases, javascript form duplication (if you need dynamic adding of forms), the differences in how the formsets constructed with formset factories behave for model or just plain unbound forms, the time it takes to learn all that is just huge.

I still have to reread most of the django/forms source code because I forget how to use the formsets with all the initial-forms, deleted, has_changed, initial-data, querysets, request.FILES and more!

On the other hand, if I had to deal with multiple forms per page from scratch without any kind of formset-type feature in the framework - I would probably kill myself.

It is kind of like this: because Django helps you a lot with trivial to medium complexity cases you find yourself using more and more advanced/harder functionality in your applications. That's the best I can put it if you know what I mean.

Answer 14

One negative about Django (not a reason to not use it) is that you cannot use hard-core regular expressions in your URL patterns, such as negative look behinds or it'll mess up the template tags like url.

Whoever voted my answer down isn't a real programmer. That really is a very bad negative about Django. It adds cruft to your URLs. For instance, I can't look for a ".html" at the end of a URL and then, if it exists, see what the characters preceding it to the last slash were.

Example: http://www.somewebpagewithdjango.com/somepath/someotherpath/itemid.html Instead, I need to do something like this with my URL:

http://www.somewebpagewithdjango.com/somepath/someotherpath/:itemid.html

or

http://www.somewebpagewithdjango.com/somepath/someotherpath/~itemid.html

Notice the tilde, and the colon.