If Django were created today, which batteries would you expect to be included in core?

Django Internals
1

Hey everyone,

Prompted by a couple of conversations on the Fediverse yesterday, this question popped in my head and thought it appropriate.

Put another way: What batteries are missing from core that you would expect to be there?

To be clear I’m not looking for specific packages (that comes later), but general feature names.

I will go first with a few:

  • Feature flags
  • Payments & billing
  • Deployments & Hosting

What do you think?

10 Likes
2

Hello everyone,

being one of the actors in the lively discussion that prompted this post, I’ll go first…

  • As part “Deployments & Hosting”, I’d really like to see an “export to static” option
  • Feature flags, definitely
  • APIs (REST or GraphQL, even if we are moving to preferring HTMX, APIs are still a must when supporting native clients)
  • HTMX tooling
  • Documentation / Debug ToolING
  • Advanced authorization (eg: per record / per field / etc)
  • Advanced forms (presentation / custom fields /etc)
  • Datatables (record lists with sort / search / filter / paginate)
  • CSV import/export

I’ll stop there but those are things that I find needing quite often when working on Django projects

4 Likes
3

Whitenoise.

It hurts new people a crazy amount that this isn’t recommended clearly in the docs. I have sometimes stood by to see what happens when a few people on the Official Discord tries to get nginx configured for static. It often leads to hours wasted.

We are letting perfect be the enemy of good. Just recommend whitenoise as step one.

8 Likes
4

So this comes under deployment & hosting as an area?

5

I suppose so. And here comes another sentence so satisfy the 20 character limit on this forum…

6

Role and permission framework

The current feature is too simple. It’s inadequate for me.
I often develop the feature that includes role and permission.
That specification is complex, then I think to need a new framework.
It’s like django-role-permissions.

3 Likes
7
  • background tasks (it’s coming! I hope!)
  • sane static asset serving (aka whitenoise)
  • .env file support
  • per-environment settings files
7 Likes
8

A few devex niceties:

  • Listing all URLs
  • More extensive typing integration
  • A more “monolithic” runserver command / docker image, that does all required startup tasks automatically and in the background (running migrations, collecting staticfiles, etc)
  • A blessed integration with frontend build processes
  • Organization of management commands
  • Recommended app structure, i.e. where does your business logic live?

On the ops side, I’m not sure if it would be part of core, but I would expect a good story for:

  • JSON logging
  • Cloud object storage
4 Likes
9

Great question!

  • In my dreams, signals living in signals.py are read without having to import them, just like models
  • Advanced forms, here too
  • per-environment settings files, here too
  • Migrations being valid for black
  • filtering and searching in list views, as in admin panel
  • built-in history on fields!
  • Saw something about making emails sending more modern, can’t wait!
  • Saw something about making login/logout more out-of-the-box, can’t wait either!
4 Likes
10

I agree with and second almost all of the mentioned above, plus

  • template components
  • task queues based on db
  • Having official tooling/recommendations for development like templates formatter, docker wrapper, editors extensions (vim &vs code) and front-end task runner.
  • more illustrative error messages (templates not found, db columns not found when migration is needed, etc) and links to the docs
  • In general, Django should learn more from Laravel and maybe Rails regarding DX
4 Likes
11
  • background tasks with pluggable backends (redis,file,db)…
  • APIs related tooling (e.j. auto schema, renderers) without going as deep as rest-framework.
4 Likes
12
  • A clear build step for static assets that can be hooked into with custom code. It doesn’t need to do anything by default, but there should be one obvious place to run esbuild or whatever. Right now, I’m running build steps outside of Django’s framework, but I would prefer it if Django knew to call the build step in the right places. A lot of the Django extensions are too opinionated when it comes to compiling static assets, all I want is a hook for a build step and I’ll write its code myself. (If this feature already exists, I’ve somehow failed to discover it.)
  • I would love more strict Django templates that don’t silently fail when variables are missing or when there are typos in variable names
  • Anything to make first-time deployments easier

I also heartily agree with some of these other suggestions, including: whitenoise by default and background tasks.

2 Likes
13

Ok, I’ll bite:

  • some type of serialization for APIs built-in
  • cleaner user authentication story (see here for more)
  • a basic local to production settings toggle that allowed for simple deploys
  • an option for an enhanced startproject that has more features, similar to DjangoX and other such efforts

Payments and billing sounds amazing but I have to admit that seems tough to implement/maintain as an open source project.

But I think the biggest thing is Django needs help marketing/maintaining itself, which means hiring an Executive Director :grinning:

4 Likes
14

This. :100:

And a clearer story about plugin/extensions, since no-way can we add even half the things mentioned here to core.

And then, some kind of Here are the popular extensions — so folks can find all the good things to install. :battery:

5 Likes
15

Yes, true. Sooo many even quite experienced Django devs I know are unaware of many third-party packages that are de-facto part of core. For example, a dev I know who has been using Django for a year but has 20+ years of experience at the highest level, didn’t know about django-debug-toolbar until I told him about it at lunch. And he was like, I’ve trying to figure out how to do that!
A long way of saying, helping with discovery/marketing is key.

1 Like
16

This is my summary post of this thread so far…

This post was inspired by some chat on Mastodon and a blog post or two.

100% this! I think is this my goal. The goal is not to add most of them to core, but to identify existing packages or gaps for new ones, then highlight or ‘bless’ those in the docs at the appropriate points.

2 Likes
17

The two things that projects I work on always seem to need are per-environment configuration settings (e.g. production vs staging vs development/testing) and feature flags. Not hard to implement but they definitely feel like batteries to include.

2 Likes
18

I’m a bit late to the party but have been thinking on and off about this, and here’s my take: I think there are a few areas where things could be added to Django, but that would mean that the fellows / mergers would have even more responsibilities for even more features, and I’m not totally sure this makes sense. Django already does a lot and does sometimes move a bit slow for my personal taste (I don’t want to step on anyones toes here.)

I think there should be a list of recommended, curated or even blessed third party packages, something like djangopackages or awesome-django, bu. I don’t know how to get there since there are so many choices to be made and especially opinions to be considered.

If I had a magic wand I would maybe want to make Django async from the bottom up but that’s basically it. (I’m not even sure this would improve things all that much, since async isn’t required everywhere and does complicate things, but if everything was async we’d have ironed out the wrinkles by now, I’m sure.)

4 Likes
19

Hi all, this is a great topic.

I think that Django needs:

  • First and foremost a strategy. What Django wants to be? If it wants to be still batteries-included web framework then for sure there are things that need to be added or changed as the world of web development has changed a lot. I have seen some great suggestions by community and they get rejected so I think it makes sense to be more clear what the strategy is moving forward.
  • For batteries-included modern web framework there are a couple of things that would be great if Django addressed. That includes ergonomic components in templates (something like django-cotton), at least basic support for building JSON/REST APIs, modernized authentication and authorization (talks are already going about login but I also think the authorization is kinda strange/limiting or I don’t understand it - how do you use it in a multitenant saas app for instance?), possibly have channels merged in core.
  • Some quality of life improvements without installing third-parties would be great. Commands like shell_plus (I saw PRs are coming), typing definitions in core, .env file support out of the box, easier form customization (more in templates rather than having to declare widgets or subclass heavily everything). Also there could be more development/debug tooling.
  • ORM is one area where it seems Django gets improvements in every release which is great. However there are still things that could be improved since the ORM was designed at the time when some database features didn’t exist. Recently I couldn’t use update_or_create for instance. I had to resort to pure SQL code since the Django implementation didn’t seem safe in concurrent scenarios.
  • Documentation needs some examples on actual real-world usage maybe. If it is a framework it should guide users better. I come from more enterprise-oriented architectures and I am often not sure what is the “django way” of doing something. So basically all individual “libraries” of Django are documented but the “framework” bit of putting it all together is often a bit unclear.

The reason why some things like components should be in core is that then the Django ecosystem can supplement e.g. pre-built components as third-party. But the current ecosystem is just fragmented and Django imho doesn’t benefit from having 10 different component external libraries. It would be better to have a bit more in core - my opinion.

All in all, I think Django lacks a little bit of an appeal for modern startups that need to build saas features like multi-tenancy and modern front-end experiences. And if Django won’t get new companies on board who will fund the project? And not just with money - but also with more developers that could contribute. But the framework needs to be attractive for it to happen.

1 Like
21
  1. Some kind of tiered support for the third party package ecosystem. It should be easier to identify “the canonical solution” type packages and have faith that they’ll be there so long as the need and Django exists. Its early days but django-commons is definitely a step in the right direction but ultimately there’s going to need to be DSF support for such an endeavor.
  2. UI template components
  3. API serialization
  4. Typed interfaces (I’m ambivalent on this myself, but I think its becoming more important to stay relevant and does make some things easier - and others harder). This is also hard because theres a lot of meta magic in Django and Python typing can’t natively work for some of it so we have to rely on plugins but not all major type checkers have a plugin system (pyright).
2 Likes