[scardine]

The ORM is mediocre compared to SQLAlchemy, the template system is weak compared to Jinja2.

If you swap Django's ORM with SQLAlchemy and replace Django Templates with Jinja2, you end up with something like Flask.

The killer feature for me is Django's "admin" app. When I'm not using the "admin", the rest of Django kind of gets in the way. Nowadays I prefer a less opinionated framework like Flask if I'm not using the "admin".

Also, Django lacks any concept of multi-tenancy and does not support composite primary keys nor schemas, which makes it a poor choice for SaaS projects. That said, Django REST Framework is awesome for API-first development and makes it a whole different game (in a positive way).

[megaman821]

I don't think Django should ditch their ORM, but for the time being simply re-implement it on top of SQL Alchemy core.

I think it would have at least three positive outcomes:

* It would greatly increase support for the number of databases and database drivers.

* It would give developers something in between using the ORM or forgoing it and using SQL strings in raw() or db.connection().

* It would provide an easier path forward to adding additional capabilities into the Django ORM.

[tga]

In my experience the true killer feature of Django is the "batteries included" approach. If you stay within the boundaries of the framework you get a standard project structure, a decent ORM, a template language (dogmatically crippled, but that's a different discussion), a forms handling library, and the typical assorted framework toolkit (internationalization, logging, development server, utilities, etc) -- all equally documented and maintained. Compare this with having to choose and figure out individual libraries for every one of the things above, each coming with different levels and styles of documentation, communities, and resources.

The end result is that you spend less time deciding on small things and can just use what's in the box. The real value is that the next person working on the code is already on the same page and can start working with it a lot quicker.

[thezilch]

Nah, I'm not sure having all the libs bound together is the killer. I think it's having all those libs with a cohesive set of docks and with a "single" voice. I'm not sure that packaging Flask, Jinja2/Babel, WTForms, SQLAlchemy, and Werkzeug (dev / debug server) together -- that should cover the non-admin Django -- would improve the usage. Technically, Jinja2 and Werkzeug are already dependencies of Flask, and their extensions page [0] are fairly instructive on what other libs to pull in for the other needs. There's also no reason one can't use Django, Jinja2/Babel, WTF, SQLA, and Werkzeug... we do!

[0] http://flask.pocoo.org/extensions/

[phonon]

Django 1.7 will support composite keys (it's been worked on for several years.)

https://code.djangoproject.com/wiki/Version1.7Roadmap