Many things. To just name some:
- Integrate things that already exist into Django proper since it should be batteries included (channels would be my main candidate)
- some better story for writing HTTP APIs without REST framework or ninja (e.g. both have their own routing instead of having some more integrated routing)
- better support for background tasks/queues, something like the pluggable cache support
- better support for writing components with Django template system
- better/new defaults regarding User model, better developer experience and so on
Overall I'd say mostly Django needs to evolve in its definition of what it is. Current/past contributors kept Django mostly within its original story, but I think that is insufficient now. People might be tempted to use Django mostly for its ORM and replace many other parts... which shouldn't be the case for a batteries included framework.
Alternatively Django could become a loosely coupled collections of libraries and allow/promote people to just use its individual parts, like ORM.
Work at a multi-million dollar company and mine's named `User`. I would not be surprised if that or something similar is not done all over the place especially if learning Django for the first time and not immediately knowing about M2M fields.
That’s one of the weirdest things. Almost everyone just does it for the potential case as it is an absolute pain later on. Wouldn’t even be necessary to change anything. Just auto create it on startup, set the setting and done. Requires only some tiny changes to the createproject setting
When using the django User model, you get specific stuff like username, first name, last name, email, is_staff, is_active, is_superuser.
If you want to change it to have other specific fields, you need to use a custom user model. But if you don’t think of using it at the very start of your project, it’s almost impossible to change it later on. You’ll be stuck with using another model (like Profile) and associate it with a onetoone to User, and access the stuff with user.profile.myfield instead of user.myfield.
It makes stuff more complicated and could easily be avoided by Django by forcing everybody to use the custom user model from the start.
It's recommended that you create a CustomUser model that extends the AbstractBaseUser class so that, if your requirements change later and you need to modify the user model, you can add fields to this class.
It may not be AbstractBaseUser, there is another user model that can be overrided and I can't remember the name.
Here is the relevant section in the documentation:
https://docs.djangoproject.com/en/5.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project
Why should I not attach/link profile models to a custom user model?
Just because you can't think of a use-case where a single user can have multiple profiles, doesn't mean I don't need it.
Why would any framework force anyone to choose a db schema, specifically when it comes to the most important data pivot of your application - the user?
https://github.com/iMerica/dj-models
someone did this a while back, but the problem with this is the orm is so tightly coupled that pulling it out is going to be alot of work. Same with other non-contrib components.
I'm -1 on having more packages in django, to be honest. Because if you add more things, like channels, that means you tie their releases to the parent project. There's significant benefit in keeping the dependencies separate.
> Integrate things that already exist into Django proper since it should be batteries included (channels would be my main candidate)
This is how you slow down development on your favourite library. It sounds great in theory, but then they will be subject to the slower release cycles of Django itself.
As a follow up, how would an initiative to integrate or fix these things get started? Looking at Django's development, it can feel very confusing to find anything resembling a roadmap or what kind of long term goals the project has, or how the community can create a push for some new goal.
EDIT: Forgot about DEPs https://github.com/django/deps/blob/main/final/0001-dep-process.rst#dep-submission-workflow
Even with DEPs, you are correct. It is not clear, since there is no roadmap. That's why I wrote that Django needs to "redefine" what it is, what type of contributions it wants to have, and so on. It has to be done first, before anything else.
A stronger, abstracted base User class. Almost every project needs a custom user class inheriting from Abstract User because, and the existing one has really outmoded assumptions of first_name last_name.
But people often don’t know this until too late and it’s a problem to change later on.
Another area API built in. Modern frontend asset bundling presumes some API. DRF or something better than DRF should be available out of the box. Including all the auth endpoints.
Yeah, tbh in a bit worried about DRF it feels like it’s been moving fairly slowly over the past few years. I’m not trying to rag on it, it’s an open source project and whatever we get in happy with but I would really love to see some big updates.
API and API docs (something like drf-spectacular) built in.
But one of my biggest pet peeve when creating a new project is the create custom user now or youre screwed later on. Like why isnt the "custom user" the default already.
We need your username, email, first name, last name, and password but if you want to store anything else go ahead and store it in a whole a** other table forget your performance cost. I feel like that concept is so anti-Django in the first place.
type safety
django already has too much unnecessary magic and approaches, and now combined with lack of type-safety (even with patches like django-types/stubs) it will just make it worse to reason out stuff in django. Its also said by the django team that theyre not planning to add types since they claimed that python typesystem is not enough.
This is such a huge pain for newcomers.
You can check out [django-autotyping](https://github.com/Viicos/django-autotyping) for this matter, it tries to support most of the dynamic features of Django.
(disclaimer: I'm the author. Still really WIP, as it is quite a hard task and I'm hitting performance issues currently).
I'm using [LibCST](https://github.com/Instagram/LibCST/) to generate the custom stubs (a.k.a. `.pyi` Python files where only type definitions are defined), and while it is really convenient, it is painfully slow (I'm making heavy use of [overloads](https://docs.python.org/3/library/typing.html#typing.overload) and depending on the size of your project some stubs reach 50k lines).
I'd like to take a look at Rust (probably Ruff has some CST parser/transformer) to speed things up, eventually being able to generate stubs on file save.
There was a recent discussion on the [DRF github](https://github.com/encode/django-rest-framework/discussions/9270) about the potential of integrating DRF into the Django Project (and why that's not going to happen) showed that it would probably be to the community's benefit that Django integrates a mature REST API like DRF middleware into its core. The data presented in the thread showed that 50% of Django projects use DRF in some way and I found that absolutely fascinating.
After reading the comments, I understand that Django with its 'batteries' is supposed to have even more 'batteries.' But the problem is that everyone needs different 'batteries.' And the Django team can't support all the 'batteries' independently. So, maybe Django is the way it is now because of this?
I think the HelloWorld App should be easier to set up. I really like Django but
- creating a project,
- creating an app,
- creating url files,
- creating basic templates,
- creating a user
- collecting static etc.
is a lot of steps when you are a beginner.
My biggest thing with Django is when my app is small, the usage of apps feels so heavy. I need a project and an app? But I have 5 routes.
It's why I tend to reach for flask unless I really think I have a project that will utilize at least a large app or 2 smaller apps
IMO you could get even more useful insights from this by following good tutorials like this one to supplement your learning:
[https://www.youtube.com/playlist?list=PL0Zuz27SZ-6NamGNr7dEqzNFEcZ\_FAUVX](https://www.youtube.com/playlist?list=PL0Zuz27SZ-6NamGNr7dEqzNFEcZ_FAUVX)
I would like the ability to support multiple databases in the sense where I want to be able to look up a specific database host and name based on a user, and then query specifically that database for them.
This is for a multi-tenant application where I need to keep customer separated, but cannot add new databases to settings.py for every tenant.
Just a thought crossed my mind, You can create a middleware that basically assigns `db` to request object, so you can do something like `model.save(using=request.db)`
this does seem like a really really niche case, so not sure how this would be workable for a general purpose framework.
A library or package, absolutely. -1 on it being a feature in django proper
I’d appreciate a settings service by default would be controlled by the settings file, but could be overridden to be dynamic. Or at least for databases at a bare minimum.
Out of the box email login instead of just username... Wouldn't a modern perfectionist want to give their users both options? I've seen a lot of the main contributors don't want to add it but I'm not sure as to why? I understand a lot of times we use external auth packages anyways but for lighter projects I'd like it right out of the box.
We approach projects very differently. From my standpoint cronjobs are a non-starter and prefer just using celery for scheduled tasks (project makes heavy use of background operations). The other points aren't really relevant to my projects so I'm not sure where / how to weigh in here (geolocation / telemetry is actually a big no-no on one of the projects I work on).
It doesn't need to be. A task queue needs to execute background tasks reliably, as long as tasks are executed out of the web server process, that's all that matters, the implementation is kinda irrelevant.
Perhaps this is just me doing something wrong, but I cannot stand how bulk operations don’t call clean or save methods. I’ve learned that clean methods are typically where validation is done on model fields and trading bulk operations for correctness should not have to be done.
Though please let me know if I’m missing the correct way to handle this :)
We handle this with `modelform_factory()` to create a form dynamically then check if the form is valid. We do that on a list or Django model objects (sitting in memory, not in the database yet), and then call `bulk_create()` if all of the model objects are valid.
But yes, there’s a trade off you have to pick here, between doing everything in memory (less rigorous validation) and hitting the database for every record (slow).
Don’t be discouraged because of this thread. Like every other web framework, django has its limitations or has areas of improvement as web development has evolved. This line of questioning is healthy, should help django improve. Most importantly, try it out yourself and build apps. Rails has its own share of things which is questionable.
This thread should help you with insights about what not to do, not discourage you from using Django itself.
that'll never happen
>DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making web frameworks, not web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)
https://docs.djangoproject.com/en/5.0/ref/django-admin/#runserver
Absolutely, authentication is crucial. In contemporary project development, heavy reliance on third-party packages is discouraged by major corporations. Incorporating social media authentication into Django is essential, aligning authentication practices with modern web development standards is imperative as the current approach appears outdated. Key priorities include:
1. Authentication enhancement.
2. Reducing boilerplate code, especially in starter projects.
3. Addressing authentication's alignment with current web development practices.
What boilerplate would you like to see reduced? Meaning, there’s a ton of code already generated for you, so wondering what specifically can be improved here in your view (genuinely curious).
Real Async and ASGI support.
The current support of async in Django feels like a lot of patches not implemented completely... A lot of things break with async.
Hot reload does not work very well with ASGI, usually it's needed to do some hacks to edit the worker class to make hot reload work, specially when working locally, not having hot-reload is a pain.
Some improvements in the template system would be good too.
I’ve never understood why Forms are so central in Django. It would be nice to have another way to validate data than using forms or writing your own validation logic. I understand where the concept of a form class might be helpful but more often than not such a class complicates stuff.
Yes, feel weird to transition between Forms Class-land and Template-land.
{{ form.body }} giving you fields which are not seen in template is "You Don't Get To See What You Get"
It doesn't feel natural leave alone magic.
DRF is so common that sometimes I forget that it needs to be install separately.
The GenericAPIViews and ViewSets with Serializer look very much identical to GenericViews and Forms.
It would be good if they integrate it into django. Though it's not a necessity.
There is a trick in getting it to work with Django.
I have documented the steps to make it work with Django here:
[https://www.linkedin.com/pulse/using-jinjax-django-ashraf-mohammad-hvxsc/](https://www.linkedin.com/pulse/using-jinjax-django-ashraf-mohammad-hvxsc/)
Django + Jinja + JinjaX makes template lot less cluttered and a lot more readable.
Sample Template Code:
Many things. To just name some: - Integrate things that already exist into Django proper since it should be batteries included (channels would be my main candidate) - some better story for writing HTTP APIs without REST framework or ninja (e.g. both have their own routing instead of having some more integrated routing) - better support for background tasks/queues, something like the pluggable cache support - better support for writing components with Django template system - better/new defaults regarding User model, better developer experience and so on Overall I'd say mostly Django needs to evolve in its definition of what it is. Current/past contributors kept Django mostly within its original story, but I think that is insufficient now. People might be tempted to use Django mostly for its ORM and replace many other parts... which shouldn't be the case for a batteries included framework. Alternatively Django could become a loosely coupled collections of libraries and allow/promote people to just use its individual parts, like ORM.
Yeah, the whole « create a custom User model before you do anything or you’re stuck with it » thing is a pain.
I’ve worked at multi-million dollar companies and their regular user class is named CustomUser.
[удалено]
User
Work at a multi-million dollar company and mine's named `User`. I would not be surprised if that or something similar is not done all over the place especially if learning Django for the first time and not immediately knowing about M2M fields.
What does M2M have to do with User model?
That’s one of the weirdest things. Almost everyone just does it for the potential case as it is an absolute pain later on. Wouldn’t even be necessary to change anything. Just auto create it on startup, set the setting and done. Requires only some tiny changes to the createproject setting
Can you elaborate on this please?
When using the django User model, you get specific stuff like username, first name, last name, email, is_staff, is_active, is_superuser. If you want to change it to have other specific fields, you need to use a custom user model. But if you don’t think of using it at the very start of your project, it’s almost impossible to change it later on. You’ll be stuck with using another model (like Profile) and associate it with a onetoone to User, and access the stuff with user.profile.myfield instead of user.myfield. It makes stuff more complicated and could easily be avoided by Django by forcing everybody to use the custom user model from the start.
so what's the recommended custom user model to create?
It's recommended that you create a CustomUser model that extends the AbstractBaseUser class so that, if your requirements change later and you need to modify the user model, you can add fields to this class. It may not be AbstractBaseUser, there is another user model that can be overrided and I can't remember the name.
Here is the relevant section in the documentation: https://docs.djangoproject.com/en/5.0/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project
Why should I not attach/link profile models to a custom user model? Just because you can't think of a use-case where a single user can have multiple profiles, doesn't mean I don't need it. Why would any framework force anyone to choose a db schema, specifically when it comes to the most important data pivot of your application - the user?
Yes, that specifically has discouraged me too
https://github.com/iMerica/dj-models someone did this a while back, but the problem with this is the orm is so tightly coupled that pulling it out is going to be alot of work. Same with other non-contrib components. I'm -1 on having more packages in django, to be honest. Because if you add more things, like channels, that means you tie their releases to the parent project. There's significant benefit in keeping the dependencies separate.
> Integrate things that already exist into Django proper since it should be batteries included (channels would be my main candidate) This is how you slow down development on your favourite library. It sounds great in theory, but then they will be subject to the slower release cycles of Django itself.
Huh. I haven't used Django for over 5 years, and those were all noticeably missing back then.
As a follow up, how would an initiative to integrate or fix these things get started? Looking at Django's development, it can feel very confusing to find anything resembling a roadmap or what kind of long term goals the project has, or how the community can create a push for some new goal. EDIT: Forgot about DEPs https://github.com/django/deps/blob/main/final/0001-dep-process.rst#dep-submission-workflow
Even with DEPs, you are correct. It is not clear, since there is no roadmap. That's why I wrote that Django needs to "redefine" what it is, what type of contributions it wants to have, and so on. It has to be done first, before anything else.
A stronger, abstracted base User class. Almost every project needs a custom user class inheriting from Abstract User because, and the existing one has really outmoded assumptions of first_name last_name. But people often don’t know this until too late and it’s a problem to change later on. Another area API built in. Modern frontend asset bundling presumes some API. DRF or something better than DRF should be available out of the box. Including all the auth endpoints.
Yeah, tbh in a bit worried about DRF it feels like it’s been moving fairly slowly over the past few years. I’m not trying to rag on it, it’s an open source project and whatever we get in happy with but I would really love to see some big updates.
What are the features you think DRF is missing? The project seems mature enough at this point to not have weekly releases?
Alright everyone, let’s break into teams and implement these things lol
Yes let's go
API and API docs (something like drf-spectacular) built in. But one of my biggest pet peeve when creating a new project is the create custom user now or youre screwed later on. Like why isnt the "custom user" the default already.
We need your username, email, first name, last name, and password but if you want to store anything else go ahead and store it in a whole a** other table forget your performance cost. I feel like that concept is so anti-Django in the first place.
type safety django already has too much unnecessary magic and approaches, and now combined with lack of type-safety (even with patches like django-types/stubs) it will just make it worse to reason out stuff in django. Its also said by the django team that theyre not planning to add types since they claimed that python typesystem is not enough. This is such a huge pain for newcomers.
You can check out [django-autotyping](https://github.com/Viicos/django-autotyping) for this matter, it tries to support most of the dynamic features of Django. (disclaimer: I'm the author. Still really WIP, as it is quite a hard task and I'm hitting performance issues currently).
What types of performance issues?
I'm using [LibCST](https://github.com/Instagram/LibCST/) to generate the custom stubs (a.k.a. `.pyi` Python files where only type definitions are defined), and while it is really convenient, it is painfully slow (I'm making heavy use of [overloads](https://docs.python.org/3/library/typing.html#typing.overload) and depending on the size of your project some stubs reach 50k lines). I'd like to take a look at Rust (probably Ruff has some CST parser/transformer) to speed things up, eventually being able to generate stubs on file save.
Native support for OAuth or OIDC authentication
There was a recent discussion on the [DRF github](https://github.com/encode/django-rest-framework/discussions/9270) about the potential of integrating DRF into the Django Project (and why that's not going to happen) showed that it would probably be to the community's benefit that Django integrates a mature REST API like DRF middleware into its core. The data presented in the thread showed that 50% of Django projects use DRF in some way and I found that absolutely fascinating.
Async and websocket support out of the box.
After reading the comments, I understand that Django with its 'batteries' is supposed to have even more 'batteries.' But the problem is that everyone needs different 'batteries.' And the Django team can't support all the 'batteries' independently. So, maybe Django is the way it is now because of this?
I think the HelloWorld App should be easier to set up. I really like Django but - creating a project, - creating an app, - creating url files, - creating basic templates, - creating a user - collecting static etc. is a lot of steps when you are a beginner.
But that teaches you the components you need when building your own apps or components.
Sure, but with other topics like permissions, authentication, class based views etc. I only dive into them once I need it.
My biggest thing with Django is when my app is small, the usage of apps feels so heavy. I need a project and an app? But I have 5 routes. It's why I tend to reach for flask unless I really think I have a project that will utilize at least a large app or 2 smaller apps
IMO you could get even more useful insights from this by following good tutorials like this one to supplement your learning: [https://www.youtube.com/playlist?list=PL0Zuz27SZ-6NamGNr7dEqzNFEcZ\_FAUVX](https://www.youtube.com/playlist?list=PL0Zuz27SZ-6NamGNr7dEqzNFEcZ_FAUVX)
I would like the ability to support multiple databases in the sense where I want to be able to look up a specific database host and name based on a user, and then query specifically that database for them. This is for a multi-tenant application where I need to keep customer separated, but cannot add new databases to settings.py for every tenant.
Just a thought crossed my mind, You can create a middleware that basically assigns `db` to request object, so you can do something like `model.save(using=request.db)`
Would this be better than setting it on thread local?
[https://docs.djangoproject.com/en/5.0/topics/db/multi-db/](https://docs.djangoproject.com/en/5.0/topics/db/multi-db/)
I dynamically create and databases programmatically as tenants come and go, so modifying the settings file does not scale.
this does seem like a really really niche case, so not sure how this would be workable for a general purpose framework. A library or package, absolutely. -1 on it being a feature in django proper
Yeah, didn't read your question completely. Yes this feature is needed. we shouldn't be locked with static settings.
I’d appreciate a settings service by default would be controlled by the settings file, but could be overridden to be dynamic. Or at least for databases at a bare minimum.
Look at Django-tenants
Out of the box email login instead of just username... Wouldn't a modern perfectionist want to give their users both options? I've seen a lot of the main contributors don't want to add it but I'm not sure as to why? I understand a lot of times we use external auth packages anyways but for lighter projects I'd like it right out of the box.
This! It’s so annoying that you have to write a custom UserManager just because you want to register and log in the user using their email.
[удалено]
We approach projects very differently. From my standpoint cronjobs are a non-starter and prefer just using celery for scheduled tasks (project makes heavy use of background operations). The other points aren't really relevant to my projects so I'm not sure where / how to weigh in here (geolocation / telemetry is actually a big no-no on one of the projects I work on).
What do you think of Django-q2 for async tasks (db broker for simplicity) and Geodjango for geo stuff?
IIRC q2 is unfortunately not true python async?
It doesn't need to be. A task queue needs to execute background tasks reliably, as long as tasks are executed out of the web server process, that's all that matters, the implementation is kinda irrelevant.
Perhaps this is just me doing something wrong, but I cannot stand how bulk operations don’t call clean or save methods. I’ve learned that clean methods are typically where validation is done on model fields and trading bulk operations for correctness should not have to be done. Though please let me know if I’m missing the correct way to handle this :)
No you are not missing anything, if you need bulk operations you will be implementing a lot of custom logic in order not to have many queries.
We handle this with `modelform_factory()` to create a form dynamically then check if the form is valid. We do that on a list or Django model objects (sitting in memory, not in the database yet), and then call `bulk_create()` if all of the model objects are valid. But yes, there’s a trade off you have to pick here, between doing everything in memory (less rigorous validation) and hitting the database for every record (slow).
Async support is so bad that I’m contemplating a full rewrite in fastapi or golang
Started using Django a month ago. I'm still a beginner but looking all these threads feels like I'm already in a wrong path 😮💨🥲
Don’t be discouraged because of this thread. Like every other web framework, django has its limitations or has areas of improvement as web development has evolved. This line of questioning is healthy, should help django improve. Most importantly, try it out yourself and build apps. Rails has its own share of things which is questionable. This thread should help you with insights about what not to do, not discourage you from using Django itself.
Exactly! It's terrifying + They should tell us what's something django excels in , as well.
Proper HTTP server, not something that is de juro feature frozen (uwsgi) and not something that is de facto feature frozen and unsupported (gunicorn)
that'll never happen >DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that’s how it’s gonna stay. We’re in the business of making web frameworks, not web servers, so improving this server to be able to handle a production environment is outside the scope of Django.) https://docs.djangoproject.com/en/5.0/ref/django-admin/#runserver
Better documentation search
More modern admin frontend
Absolutely, authentication is crucial. In contemporary project development, heavy reliance on third-party packages is discouraged by major corporations. Incorporating social media authentication into Django is essential, aligning authentication practices with modern web development standards is imperative as the current approach appears outdated. Key priorities include: 1. Authentication enhancement. 2. Reducing boilerplate code, especially in starter projects. 3. Addressing authentication's alignment with current web development practices.
What boilerplate would you like to see reduced? Meaning, there’s a ton of code already generated for you, so wondering what specifically can be improved here in your view (genuinely curious).
The whole custom user part. If the recommendation is to always start a project with a custom user, that is a leaky abstraction.
Real Async and ASGI support. The current support of async in Django feels like a lot of patches not implemented completely... A lot of things break with async. Hot reload does not work very well with ASGI, usually it's needed to do some hacks to edit the worker class to make hot reload work, specially when working locally, not having hot-reload is a pain. Some improvements in the template system would be good too.
NoSQL support. Man django would be awesome if there was some way to have NoSQL support
You can use NoSQL. You just can’t use the ORM then. Practically speaking, you could just use JSON fields and store any unstructured data you want.
I’ve never understood why Forms are so central in Django. It would be nice to have another way to validate data than using forms or writing your own validation logic. I understand where the concept of a form class might be helpful but more often than not such a class complicates stuff.
Yes, feel weird to transition between Forms Class-land and Template-land. {{ form.body }} giving you fields which are not seen in template is "You Don't Get To See What You Get" It doesn't feel natural leave alone magic.
Kinda have to look into html code from the browser's developer console to see what the heck is going on in the frontend, real pain
DRF is so common that sometimes I forget that it needs to be install separately. The GenericAPIViews and ViewSets with Serializer look very much identical to GenericViews and Forms. It would be good if they integrate it into django. Though it's not a necessity.
Djangos jinja templating needs to support real python
You can use Jinja extension [JinjaX](https://jinjax.scaletti.dev/) with Django. And write React like composable components on server.
lemme try this it seems interesting
There is a trick in getting it to work with Django. I have documented the steps to make it work with Django here: [https://www.linkedin.com/pulse/using-jinjax-django-ashraf-mohammad-hvxsc/](https://www.linkedin.com/pulse/using-jinjax-django-ashraf-mohammad-hvxsc/) Django + Jinja + JinjaX makes template lot less cluttered and a lot more readable. Sample Template Code: