[jessegreathouse]

I just get tired of seeing the same thing play out time and time again. Developer A picks Django because business described a project that can easily be handled by CRUD and thinks the Admin will be perfect for product owners and users to manage their data. 6 months go by, Product owners go off the rails of the original requirements, request changes to the admin and/or changes to the data source and/or changes that require a fundamentally different data model. Developer A bails and Developer B, C, and D get stuck with this mess that should be been developed with a more flexible solution. The more people use Django without recognizing this, the more I want to not even look at Python shops.

[ryannevius]

Flask and Pyramid don't help in that situation either...In fact, I switched from Flask (after years of being an avid Flask proponent) because I ran into too many projects that were a mess due to the lack of constraints / standard ways of doing things. After 5 years of solid Django use, I have yet to run into a situation where Django is too inflexible for a client's needs. No, the Admin isn't for everything (and that's even outlined in the docs); but it's not difficult to roll a custom dashboard (just like you would when using Flask or Pyramid).

[CuriouslyC]

The flask community really needs to rally around a project layout/boilerplate set-up; it took me a lot of trial and error to really nail scalable, intelligent flask projects and that is the #1 issue people run into with it.

[bliti]

Over the years I've used Flask for smaller projects with very specific requirements and simple web GUI requirements. Its my de-facto tool to prototype and/or deploy JSON APIs. It works perfectly for that because it does not impose anything on me. For more complex projects, or projects that use a web GUI (even if they are rendered with client side frameworks) Django proves to be more effective. It has a standard toolset that takes care of a lot of the edgecases one would face. For example, Flask lacks a default CSRF implementation whereas Django makes explicit use of one. Logging is also very simple with Django, something that gives some people grief. In Flask you have to setup logging from the bottom up. Both are quite different but good for what they were meant for. In fact, I tend to look for the Django or Flask of other languages to try and see how a specific type of application with look in that language. Not long ago someone posted a project that mimics flask in Rust. It was a very nice codebase and it made Rust very approachable because I could map what I know about Flask over to Rust and make a connection between language constructs and patterns.

[zeemonkee3]

If "product owners go off the rails" you have a management and process problem, not a Django problem.

That's not to say there are projects where another framework/language would have been better but no solution is going to save you from poor project management.

[cdelsolar]

I've been working with Django for years and I can't think of any way in which it is not flexible.

[Beltiras]

I wrote a CMS for a large newspaper where I deployed new code on almost a daily basis using Django(uWSGI)-redis-PostgreSQL-Celery. 4 developers were active at the time. Requirements were not set in stone, we tested tons of stuff out and iterated every aspect of the site both on the development and operations side. Django was never the problem during those 18 months.

Django is like any other framework/language. Bad programmers can make a hash of it with ill-conceived ideas.

[JustSomeNobody]

This isn't a problem with Django. This is simply how software business works. No matter how well architected your solution and no matter what platform you will always have the request to do something it wasn't designed to do. If you're lucky you don't have a manager who says "can't we just put an if statement in."

[trymas]

Yeah, right..

There is no boilerplate or constraint how those 'flexible' solutions should be created, thus every developer writes however he wants and if those developers have not made constraints for themselves you will have a total mess, written in so many styles as there were developers. Jeez, I've even seen messed up Django apps, where you usually must follow some patterns.

Patterns, constraints, models, architecture are for a reason and if a framework/language/library makes you use some specific styles, it's much easier to maintain such projects when there is more than 1 person working on them.

[natrius]

This isn't a Django problem. Just don't customize the admin. Ever. If the admin can't do what you want, pull out React and Django REST Framework and build something that does what you want.