## News

Announcing the Search for a DSF Executive Director

The Django Software Foundation is hiring its first Executive Director, and we have the Django community to thank for making it possible.

Six Django web development agencies have jointly pledged $47,500 to help fund the Executive Director's first year: Caktus Group, Lincoln Loop, Six Feet Up, Cuttlesoft, OddBird, and Two Rock. This is the financial foundation we needed to move from "we should hire an ED someday" to "we are hiring an ED now."

I'm delighted to rejoin the Sovereign Tech Fellowship

Hugo van Kemenade returns to the Sovereign Tech Fellowship after being one of six participants in the 2025 pilot, calling out how dedicated time helped ship Python 3.14 and 3.15 releases, mentor triagers, and improve release automation and accessibility. The post also tracks a wide set of community and governance work, and looks ahead to a larger 2026 cohort spanning maintainers, community managers, and technical writers.

Python Software Foundation

Python Software Foundation News: PSF Board Election Dates for 2026

PSF Board elections for 2026 open for nominations on July 28 (2:00 pm UTC) and voting runs September 1 to September 15, with voter affirmation due August 25. The Packaging Council election will run in parallel under PEP 772, and PSF member voting eligibility is handled via psfmember.org.

Updates to Django

Last week we had 24! pull requests merged into Django by 11 different contributors.

This week's Django highlights 🦄:

• Added --using option to sendtestemail management command. (#37141)

• As a performance optimization, add an option to cull the DBCache only on every n queries. (#32785)

• Reduced false positives in strings during collectstatic. (#36969, #35371)

Sponsored Link

Reach 4,300+ Engaged Django Developers

Sponsor this newsletter to reach an active community of Python and Django developers.

Articles

In search of a new contribution model

Carlton Gibson on why open source's contribution model is broken--burnout, extractive contributions, harassment, and now AI--and his plans to experiment with something less open-by-default on newer projects.

The University In The AI Era

From Carson Gross, creator of HTMX and full-time college professor, a detailed and practical look at what AI means for universities in general and computer science programs in particular.

How I Work From Anywhere Without Losing My Place

Jeff has been running a new remote dev setup that allows for seamless switching between home office, an iPad, or even a phone when out on the go.

LLM-Inspired Development

How a bad idea from an LLM led to a good idea on a website.

Tech doesn't matter? Why to use Django for agentic coding

Ronny Vedrilla argues that in the age of agentic coding, Django's opinionated structure, secure-by-default posture, and heavy representation in training data make it an ideal "harness" that keeps AI agents on the rails-not a competitive edge, but a hedge against shipping a quiet disaster.

Videos

The Modern Python Web Stack: Django, FastAPI, uv, Pydantic, and AI

A 5-minute conversation from PyCon US with Jeff Triplett on how Python web development is changing fast. (Yes, this video features Jeff and Will, the two authors of this newsletter, but we still think it warrants mention! 🤝)

Podcasts

Teaching Python #158: Will Vincent on Django, AI Coding, and Why Fundamentals Still Matter

A chat on why Django continues to matter, the reality behind vibe coding, local AI models, and more.

Django Forum

Call for mentors - GSoC 2026 with Django!

Google Summer of Code is around the corner and there is still a need for mentors on some projects.

Ticket 34753, Document how to properly escape to in email messages

An active discussion around this particular issue. Checking the forum is a great way to get a pulse on what's happening with core Django development.

Django Fellow Reports

Jacob Walls

In this four-day week (I headed out Friday for a college reunion), everything got a little bit better. First, check out @blighj's estimate showing that collectstatic's import statement detection reliability (needed to rewrite URLs) improves in Django 6.1 from 88% to 99%. Meanwhile @felixxm is stress-testing database defaults and landing fixes needed for using Django 6.1's UUID4()/UUID7() functions. Finally, we made the test client more friendly for third-party permission packages like django-guardian and django-rules. @sage also spotted a breakage in DRF in the upcoming Django 6.1 beta, since Wagtail tests against Django's main branch. I expect the fix to land before the beta is even out. Be like wagtail and test main!

Natalia Bidart

This week had a bit of a reset feel to it 🧹. After the previous stretch of PyCon US, security prep, and the security release itself 🏁, I spent time going through pending and snoozed items ⏰, trying to close loops and get things back to a more manageable state.

We also reviewed and triaged a batch of security reports 🎁 that were shared by a major AI company, following conversations I had at PyCon US 🐍 🏖️ about the growing volume of LLM-generated security submissions and the challenges they create for OSS projects (Django in particular). The reports were generated using an advanced security-focused model 🤖 against the Django codebase. We evaluated each finding, confirming and addressing valid issues where appropriate and mapping others to existing tickets and prior reports. Overall, Django is in good shape 💪, as the results largely overlapped with known reports, validated our current triage approach, and reinforced confidence in our security stance 👏.

Events

Django Girls Krakow on 18th July 2026

This event is taking place during EuroPython at the sprints venue.

Django Day Copenhagen 2026

Djangonauts from in and around Denmark are meeting up for the second edition of Django Day Copenhagen 2026, October 2.

International Travel to DjangoCon US 2026

Are you attending DjangoCon US 2026 in Chicago, Illinois, but you are not from US and need some travel information? Here are some things to consider when planning your trip.

Join DEFNA! There's a seat on the DEFNA board open

Django Events Foundation North America (DEFNA) is looking for another board member. We have eight board members currently and are looking for another person passionate about growing the DjangoCon US community to join.

Django Job Board

Senior Python/Django Developer at Gryps 🆕

Founding ML/Data Scientist (Remote, UK) at MyDataValue

Projects

ranahaani/GNews

A Happy and lightweight Python Package that Provides an API to search for articles on Google News and returns a JSON response.

jazzband/django-newsletter

An email newsletter application for the Django web application framework, including an extended admin interface, web (un)subscription, dynamic e-mail templates, an archive and HTML email support.

19 Jun 2026 3:00pm GMT

The 2026 way of using importmaps in Django

I last wrote about Django, JavaScript modules and importmaps in May 2025, slightly over a year ago.

The main topic of this post is the django-js-asset 4.0 release. The library is used in many places, some of the more well-known packages using it are django-mptt and django-ckeditor. I have since done a lot of work evolving the ways of integrating importmaps but the efforts to standardize upon an approach have stalled a bit. The main reason for this, apart from time and energy, was that I wasn't really all that happy with the global importmap. When I had only a few modules using the importmap facility, I didn't care all that much. Now that the recently released django-content-editor 9.0 also uses importmaps for shipping a refactored, much more modular JavaScript implementation while still keeping all the benefits of cache busting using ManifestStaticFilesStorage¹, having a global importmap got annoying. The content editor JavaScript is only used within the Django administration interface, but when using a single global importmap object, the importmap entries were always there on each page that used an importmap at all.

A better solution was needed. I'm a big fan of using forms.Media for collecting CSS and JavaScript from widgets, forms and utilities. It helps me avoid inline JavaScript since at least 2017. I'm not using it for site-wide CSS and JavaScript, I'm still transpiling, PostCSS-ing and bundling the assets using rspack as for example written about here and here.

Why importmaps?

A quick refresher on why this matters at all. Django's ManifestStaticFilesStorage hashes the contents of each file into its name for cache busting, but out of the box it doesn't rewrite the import statements inside JavaScript modules. Importmaps bridge the gap: your code imports a stable name:

import { initializeEditors } from "django-prose-editor/editor"

and the importmap tells the browser where that name actually lives:

<script type="importmap">
{"imports": {
  "django-prose-editor/editor": "/static/django_prose_editor/editor.6e8dd4c12e2e.js"
}}
</script>

So the import stays clean and constant while the file behind it can get a new hash on every deploy.

django-js-asset 4.0

The updated django-js-asset 4.0 doesn't ship the old, global importmap at all. This means the upgrade might require some work. Instead of one importmap shared across the whole site, you now get a specific importmap assembled for the context at hand - either by Django itself when it collects the media of your forms, widgets and the admin, or explicitly by you in a view or context processor. The building block in both cases is the ImportMap object; when it travels through js_asset.Media (a subclass of django.forms.Media) the maps are automatically merged into a single <script type="importmap">, by customizing and extending what Django does already when merging media instances.

The release notes go into more detail.

In practice

If you're using a package such as django-prose-editor in the Django admin you don't have to do anything, things should just work.

If you're using such a package outside the admin, you have to remove "js_asset.context_processors.importmap" from your list of context processors. On one particular website the prose editor is the only package with importmap entries outside the admin, so I have to add the importmap to the template context myself:

from django_prose_editor.widgets import importmap

def view(request, ...):
    return render(request, "template.html", {
        # ...
        "importmap": importmap,
    })

The template then just renders it in the <head>:

... {{ importmap }}</head>

On a different site, I have a slightly more involved scenario where I previously used importmap.update(...) to add my own entries to the importmap. There, I'm using a custom context processor to always add these entries to the importmap too:

from django_prose_editor.widgets import importmap as dpe_importmap
from js_asset import ImportMap, static_lazy

_site_importmap = ImportMap({
    "imports": {
        "my-module": static_lazy("my-module.js"),
    }
})
_importmap = dpe_importmap | _site_importmap

def importmap(request):
    return {"importmap": _importmap}

This importmap is merged once at server startup and then served repeatedly to the client. Because we use the lazy version of the static function we can do this during startup and not worry about files not yet collected by collectstatic - we'll get the correct paths later.

On the same site as the previous example, I also have an admin inline which requires some JavaScript and also an importmap:

from django.contrib import admin
from django.forms import Script
from js_asset import Media, ImportMap

# Initializing this once. Not necessary but I like it better that way.
_importmap = ImportMap({
    "imports": {
        # ...
    }
})

class ModelInline(admin.StackedInline):
    @property
    def media(self):
        return Media(
            js=[
                _importmap,
                Script("module.js", type="module"),
            ]
        )

As of 4.0, JS and CSS produce Django's own Script and Stylesheet objects, so you can import and use Script directly from django.forms as shown above (on Django 4.2-5.1, import it from js_asset instead, which backports it). The familiar JS("module.js", {"type": "module"}) wrapper still works unchanged if you prefer it - it just takes a positional dict instead of keyword arguments.

Here, it's really important to use the js_asset.Media and not django.forms.Media. js_asset.Media knows how to handle importmaps - all importmaps are collected from all media lists, merged and added to the output before all other CSS and especially JavaScript. The reason for that is that browsers only honour a single importmap per page, and it really has to appear before all JavaScript modules referencing any entries in the importmap.

The nice thing about js_asset.Media is that it doesn't have to appear first in the list of media classes which are merged - it can also appear in the middle or last, and still can do its magic after all Media objects have been merged into a single one.

The rest is handled by Django itself, since it already supports collecting media assets. The missing piece was just the importmap object and the js_asset.Media class which knows how to special case them, and which - through the power of overriding __add__ and __radd__ takes over all the other media instances.

What's next

I haven't yet used CSP nonces using {% csp_nonce_attr media %} in production myself, but it should just work, even with importmaps and everything else. Given that I have a passing test suite I have no reason to believe it doesn't already work, but I'd like to have a confirmation.

I'm hoping to standardize some more. If we could get something like this in Django core that would be really nice. Maybe I'll be able to work on that at Django on the Med 🏖️. Since no browser supports multiple importmaps as of today having multiple implementations of importmaps in the Django ecosystem will lead to trouble down the road. I think there is a clear case to be made for importmap support in Django and I would obviously love it if the approach implemented today in django-js-asset would be the basis for the official solution.

17 Jun 2026 5:00pm GMT

Great programmers cheat. A hard problem gets quietly swapped for an easier one; a transaction-grade database is replaced by a flat file nobody misses; machinery everyone else considers mandatory simply never gets built. They know a lot - and that's exactly why they get away with it.

16 Jun 2026 11:00am GMT