My Django wishlist explained

Disclaimer

Most of my job revolves around building Django-based applications. A lot of the tools you use to build applications are different than the tools you need to build websites.

This post is written mostly from the perspective of an application developer.

With that out of the way, let's dig into the wishlist, my wishlist is based on the choices and libraries I include in a majority of project I start.

Deployment

Documentation

As far as deplyment goes, I usually deploy directly on an Ubuntu Server VM. Ubuntu comes with nginx, Apache and uWSGI packages, my favourite combo being nginx + uWSGI.

Most of the info to perform such a deployment is on the documentation website but it's scattered around several pages. Django is supposed to opinionated, I'd love to have a documentation page like "here's a recommended deplyment on baremetal/VM", heck why not a management command that would generate the 2 config files needed.

I know that for a while, it has been popular to deploy Django over Docker, why not include a Dockerfile example in the docks (or a management command to produce one).

I feel like these 2, together would get 99% of people out of the woods. If your jam is WhiteNoise, include it in the Docker setup (I feel like it's unneccesary for nginx+uWSGI), the idea is mainly to provide an easy copy-paste for the people doing their first deployment, nothing fancy!

Static exporter

I love static sites, they come with many perks like speed and security but having a static exporter provided as a battery has another big advantage: it's a free smoke test!

We all know we should write tests for our sites and applications, and before the need arises for anything more specific, the first test I write is usually along the line of "check the page renders". Being able to add an export-to-static step to your CI, would give you that test for free.

Static websites are not suited for everyone though, a lot of sites and most applications are not completely static by nature but... at least a few pages for every one of those can be static (think "About" page or "Legal notice"). With a clever nginx config you can even get the best of both worlds, mixing static and dynamic pages.

Feature flags

In 2024, it seems like feature flags are part of many application workflows, some might even argue they are a good practice. I know some packages already cover this, but which one should I choose? Should I implement it myself in my settings.py?

I'd love to see this as a contrib package but at least an opinionated recommendation would be nice.

And that's just for people using Django. If this was built-in, this could have a positive impact of Django's development itself: "Here, we've been working on this feature and you can already test it in your app by turning on the XX-FEATURE in your settings". Or its counterpart: "you're not using X and Y, you can now disable them in your settings".

API support

As far as API support goes, it seems like the idea was there but was never fully implemented. By this, I mean Django has a lot of builtin tools to create APIs with no external dependency, things like JSONResponse but is missing an important part: serializers.

Serializing a Python object, or even worse a Django Model instance is not trivial!

There are well-known packages that manage serialization (like Marshmallow) or more (like DRF or Ninja) but...

Most of the work to have serializers natively in Django is already there, it's the forms framework as pointed here, I believe a bit of love and documentation could go a long way, not just for REST but for GraphQL as well.

Tooling

htmx

I understand this one is controversial as I remember all the work that went into removing JQuery from Django admin... but htmx seems to be widely adopted by our community and could bring a few batteries along, the first thing that comes to mind would be a dynamic ForeignKey widget which, in 2024, feels like a battery Django should include.

There is currently django-htmx but it is very barebone.

Documentation

I've recently published django-classy-doc so it probably comes from a pretty biased place for me to recommend this to be part of Django.

The reason I published it though comes from a real need and, if similar tooling is not included in Django, I feel an easy win would be to officially endorse CCBV and similar sites in the documentation.

Debug

I hear Django Debug Toolbar has recently found its way into the official documentation after many, many, many years.

For such a prominent tool, I feel it is not enough though. It feels like this library should benefit from a "special treatment" and that every new release should check if it works with Django Debug Toolbar and be considered blocked if it doesn't, eventually provide support to the maintainers to remove the block.

Advanced authorization

This one is a weird one. Django's permission system has never felt adequate to me.

I broadly run into 2 opposite cases:

• it's too complex:
  • All I need is logged-in users (admins) vs anonymous - think CMS for a small business.
  • Maybe I need admin and non-admin users - think small e-commerce website.
• it's too simple:
  • not only do I need users of group X to have access to a limited set of resource but with edit permission only on the records they created themselves.
  • I need users of groups X and Y to have access to the same resources but I want users of group Y to only see certain fields
  • as manager, user XX can only see records from their managees
  • ...

So, I'm not sure where I stand here... probably something along the lines of having something simpler by default (superuser/non-superuser) in the basic User model and alongside, provide the current Permissions/Groups version with more Permission classes out of the box and documented examples?

Advanced forms

I guess there is a reason django-crispy-forms is one of the most-commnly used Django package, yet I don't see it in the docs.

I know Django forms are evolving so this all might already be on the roadmap but building forms I often find myself missing more advancesd features, here are a couple examples that seem to be present in tools like google forms or others:

• conditional display fields (only ask for an e-mail address if "send me an email" is checked)
• linked drop-downs (think country/city combo)
• file field with preview
• multi-page forms
• editable one-to-many (somewhat trivial in the admin, much more complex outside of it)

django-formsets brings a lot of those but it feels very dense at times.

Forms being a "first-class citizen" in Django, it feels that the included battery is now a bit leaky after all those years.

Datatables

Django lures us in with the admin and search/filter/sort included... But then if you are a "good student" and don't want to expose the admin to your end-users, you are left on your own with just the generic ListView that has none of those things.

django-filter helps bring back a lot of those but... I feel cheated loosing all those features, that potentially attracted me to Django in the first place, and having to use external libraries.

django-tables2 and iommi are there also but none of the 2 have felt right and Django-ish enough to me.

I would definitely like to see django-filter become a contrib library and see the generic ListView supporting it out of the box.

CSV import/export

Django import / export is definitely a robust library and, CSV features being one of the request I face with almost every project, I would love to see it as a recommended library.

Components (not included in my original list)

With over 10 django-components libraries to my knowledge, it is clear that the community is interested by the concept, going beyond the standard {% include %}.

I certainly have my preferences among those libraries but I haven't found the one for me yet.

Given the obvious interest, maybe a working-group could be a good solution to coordinate all the efforts of the many maintainers currently experimenting with the field. Funding might also be a good idea as it is clearly something a lot of Django users are interested in.

If you'd like me to expand on any of those, feel free to ask!