Python is a language that gives us a lot of liberty in how we solve problems, but Django is a set of cookie cutters for doing things a certain way. Django's cookie cutter patterns and extensions don't lend themselves well to doing things outside the way that Django intended them to. It's why a lot of us prefer Flask or Pyramid as framework of choice.
It's nice to dabble around Pyramid and/or Flask, but everytime I use, or someone I know uses them for not completely trivial microservices, they are always reinventing those 'cookie cutters' from scratch on their own (or choose a set of 'cookie cutters' made by someone else).
Django can work as a 'microframework', i.e. 'hello world' in one file and in ~10-15 LOC.
Not to mention Django's 'stability', i.e. stable releases at known time, with known ahead roadmap and forthcoming changes, great documentation, etc., whereas Flask has not been released for 2years and 9months (!!!), master is 900 commits ahead (2400 commits in total) of latest version, documentation is not the best (especially for current `master`)... Pyramid is made by true rockstar programmers, though it did not stand against hip image of flask and it suffers from the fact that I must reinvent all the 'cookie cutters'. IMHO this 'microframework' approach is good only for trivial microservices and/or completely non-trivial, crazy custom apps, where overriding Django would be just too much.
No, there are several. But all of them should strive to be Pythonic, including in the sense of offering "one, and preferably only one, obvious way to do something".
>Dumb comment.
Oh, the irony.
>I was talking about architectures not syntax.
And the Zen of Python is about architecture and APIs too, not just the syntax of the language. They are generic guidelines about how to write Pythonic programs.
I think the objection is referring to Django unequivocally as "bad news", rather than saying that your personal preference is for Flask.
(I work in a shop which has used both, and generally try to avoid claiming one or the other is objectively better; they're not quite at the apples-and-oranges level, but pretty close)
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.
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).
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.
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.
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.
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."
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.
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.
I work with various languages and frameworks. Django is great for general web CRUD systems. It being opinionated and somewhat inflexible is a blessing and a curse. No framework is perfect.
Flask provides the basics to build Web apps. It's low on opinions and flexible. I mostly use flask for systems that are very specific about their functinality and use case.
It's a batteries included framework, but at the end of the day it's just Python. You can integrate with whatever library is best for the job.
I've worked on Django apps that use SQLAlchemy instead of the Django ORM, Django apps that use Mako instead of the Django template language, and I'm currently exploring using Marshmallow instead of Django forms for some cases.
Is there anything in particular that you feel you can use with Flask or Pyramid but you couldn't use with Django?
I view it from the other direction. If you aren't using the ORM, or the templating engine, or the admin interface, why would you choose Django? If your answer is for a plug-n-play RESTful api or authentication, you might want to check out PostgREST with PostgreSQL 9.5's row level security features, it's just plain better.
Because at that point, Django is a superset of Flask. It can do everything Flask can do, but it also has additional access to the Django ecosystem of tools and libraries.
I really like Django, but you're right that if you for whatever reason needs to make Django do something that's it's not exactly designed for, you're going to have a bad time.
What I found is that if you can manage stay within the confines of Django, you will be rewarded and can avoid writing a ton of code. There really isn't to many situation where you can't just to things "The Django Way". If you find one, then maybe rethink your solution. I had a ton of code where I tried to fight the Django Rest Framework, when I stopped and just accepted that Django and the Rest Framework is opinionated I was able to reduce complexity and line count.
Of cause there are problems where Django is simply the wrong solution.
That's one of the reasons I recently made a pared-down Django project, to highlight that you don't need to use all of the tools Django offers: https://github.com/rnevius/minimal-django