Interesting, I take the opposite approach: As your project starts to grow, you end up ripping out the "batteries" of django and implementing other modules. The most notable one would be SQLAlchemy.

Yup. I switched to Flask mostly because I always ended up ripping Django apart:

- Jinja instead of Django templates.

- Custom (and sane) class-based views instead of Django's disgusting defaults.

- Custom class-based settings.

- There's no way to define app-only middleware in Django. Flask blueprints make it trivial.

However, 10 years later and no framework has come close to Django's true strength: built-in admin.

Just an FYI, the newest version of Django (1.8) now supports Jinja or Django templates by default and you can plugin other templating engines if you want.

Did you try to use Jinja2 templates in 1.8? There is hell of a bootstrapping to do until you can actually start working with these. Don't even try to use both at the same time within the same project. You'll end up crazy before you can make Django load the right template.

No I haven't, still on Django 1.6 at work but I keep up with the newest developments. That's a shame, from what I read it sounded like it was just a simple config setting that would allow you to use Jinja over Django templates.

You don't have to use Django's class-based generic views either. Nothing wrong with just inheriting from the base View if you really want.

You can also just skip the infinite inheritance and implement function-based views.

Interesting. Almost every experienced Django dev I know throws out the admin on their projects nowadays.

In favour of what?

I don't.

I am curious about this. I like Djangos ORM for the basic stuff, but it doesn't work on even moderately complex queries (conditional aggregates are a serious loss). Would I gain much by going to SQL Alchewy over just using raw SQL, which is what I do at the moment? (bearing in mind replacing the Python ORM completely, and you will loose the admin, which I use heavily).

It's a pretty recent development, but have you tried Django 1.8's Conditional Aggregation and Conditional Expression features?

https://docs.djangoproject.com/en/1.8/ref/models/conditional...

Not yet, I usually stay with the latest stable version. Sounds good though. Its been long overdue.

Exactly. I think that's why Flask needs more experienced devs for larger sites. This also means it's easier to hire Django devs.

In one project I worked on, I found this to be very true. We created an enterprise level application, with some constantly shifting specifications.

Flask vs Django was a huge point of contention between the two lead developers. One even quit over Django being chosen.

By the end of the project, we ended up using a ton of django's features. The business functional specifications changed, we did some research, and found out it would be easy to handle via slight extension of some already built-ins to django ex. template loaders,middleware,sites,and signals. It saved us a ton of time. I feel pretty safe saying I would use Flask for small very clearly specified projects, but otherwise I would probably choose Django.

When I started doing Django projects back in 2007 I certainly found Django very cumbersome - the lack of features in the ORM, the clumsy template language, the terrible authentication system (User.get_profile and so on). I preferred Pylons by a mile (the Flask/Pyramid of its day).

Django in 2015 though pretty much does everything I need. I still have gripes but when you factor in extras like the Django Rest Framework it's still my go-to for new projects unless it's something completely unusual.