I have been a user of Django for 15 years, I think I first used version 0.95 just after the “magic removal”. I wouldn’t say any of these are “harmful”, there a

I have been a user of Django for 15 years, I think I first used version 0.95 just after the “magic removal”. I wouldn’t say any of these are “harmful”, there are certainly some things here that have valid arguments for doing differently, but most is rubbish. But it needs to be taken into account that Django is an incredibly mature framework with literally millions of projects built on it. Large changes are hard, and Django has had to make many of them before. All of these have been debated and haven’t changed either due to immovable technical debt, a decision that there isn’t at this time a need, or there is valid arguments on both sides. A couple of examples: the user model, providing a default is important but it is also well documented that if you want to extend it you should subclass it from the beginning to make your life easier. There are ways to migrate later, they aren’t exactly easy, but it is doable. Multiple small apps, this architecture is due to the history of Django and its development at LWJ. They wanted a way of being able to quickly build new websites out of pre-defined “apps”, and this system works for that. At the time the Python packaging ecosystem was very different, hence then slightly odd design. I’m sure in hindsight the founding team would have done things differently, but this is 17 years ago. The general rule of thumb for “app” architecture now with Django is if you are a consultancy/agency building multiple similar sites for multiple clients (this is a huge use case for Django, closest to it original vision) it makes sense to package up your functionality into reusable apps. If you are a “startup” or building an internal app for a company with no need for reusability it’s best to just have one “core” app to contain all your functionality. It comes down to your personal needs, but it’s easy to make both architectures work.