My biggest missing features that should be built-in are probably types and tenancy that doesn’t expect a separate settings file.
But I’d probably slim down on the “built-in” batteries if given a fresh slate, and have more official or recommended batteries, recommended in our documentation and part of our search, navigation, and tutorial, that would still be separate packages from core Django. I think that would likely provide the best balance between maintaining an extremely stable core, encouraging innovation in our community, and making the discovery of 80% tools easy to find.
5 Likes
On-and-off Django developer here. I think those are what you would expect from a major webserver in 2025:
- authentication that just works. Or just nothing at all, and instructions to install a package that provides it. Possibly to be picked from a list vetted by Django
- decoupled settings for development and production, declarative if possible
- simpler, saner deploy to production. Maybe bless/recommend whitenoise ? Maybe a
check --production, that would check for ALLOWED_HOST, CORS headers, TLS, all those things that make that your website that worked stopped stopped working when DEBUG switched to False
- native solution for background job, because you need them for tasks that django consider vitale (sending mails) (I know this one is coming, pfew)
- easier handling of static assets. I am a dev backend, I have no idea of how to handle static assets, I would love a django command that does all the cruft for me
- Less rigid NIH policy. Maybe bless and embrace whitenoise, wekzeug, debug-toolbar
I worked with Rails for two years recently, and, wow, it was a eye-opening experience:
- everything you need to startup a website just work.s You can go to production with the default generated template immediatly
- declarative and decoupled settings, with an escape hatch to do computations or take value from environment variable
- background job are a first class citizen, core functions that should be background (like
send_mail) are async by default. Just pick an async job runner from the list Rails gave you, and you are good to go
- builtin pipeline for static assets. It’s not awesome but it will do what you need
- of course you don’t need a special NGINX configuration for static assets or a 3rd part package
- it has the equivalent of django-storage builtin. This one and many others
- bonus: Rails has “object-level” scaffolding and I felt in love with them. Imagine,
./manage.py scaffold Person name age:int birthdate:datetime, and voila, I have a model, CBV CRUD view, form and a HTML templates skeleton
Of course it’s not perfect, the cracks start to show when your app becomes big, and most importantly: it’s not python.
1 Like
You might already know about these third-party libraries, but I’ll link them just in case.
all I want is a hook for a build step and I’ll write its code myself
I created a filter for django-compressor (inheriting from CallbackOutputFilter) as my hook like this: refreshcss/refreshcss/filters.py at main · adamghill/refreshcss · GitHub. There isn’t great docs around this from what I remember, but it worked well for my purposes, ymmv.
strict Django templates
GitHub - boxed/django-fastdev: An app to make it safer, faster and more fun to develop in Django by @boxed
first-time deployments
GitHub - django-simple-deploy/django-simple-deploy: Deployment, for Djangonauts with deadlines. by @ehmatthes
3 Likes