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.
3 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:

4 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.

1 Like
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