I’ve opened a new feature proposal on django/new-features:
The idea is to make Django’s JSON serialization/deserialization pluggable via an opt-in backend, the same way PASSWORD_HASHERS + django[argon2] already works for password hashing and STORAGES works for storage backends. The standard library json module stays the default; switching to a faster library like orjson would be opt-in via a JSON_BACKENDS setting and a django[orjson] packaging extra.
The proposal is a progressive sequence: step 1 is a pure refactor (route the ~40 hardcoded json.dumps/json.loads call sites through django.utils.json, no new setting, no behavior change), step 2 introduces a BaseJsonBackend abstraction (still stdlib-only), and step 3 adds the opt-in setting + extra (DEP-gated).
The genuine gap the proposal addresses is the internal hardcoded call sites in contrib/admin, contrib/messages, contrib/staticfiles, views/i18n.py, forms/utils.py, etc. — those cannot be swapped from a third-party package without monkey-patching. The user-facing surfaces (JsonResponse, JSONField, serializers) are already pluggable per-call, and django-orjson already covers them opt-in, but the internal surfaces are unreachable from third-party code.
It follows the template established by #105 / PR #20498 (pluggable multipart parser, recently merged) and the PASSWORD_HASHERS precedent. @nanorepublica has already offered to help with the contrib/messages part, which overlaps with his #155 refactor proposal.
If you’d use this or have thoughts, please react on the issue with the emoji buttons (the django/new-features process uses emoji reactions to gauge community support). Comments with specific knowledge or concerns are also welcome on the issue directly.