Django review: is het nog steeds de moeite waard?

Django bracht in de acht maanden tussen december 2025 en augustus 2026 twee feature releases uit en schreef zijn hele releaseritme opnieuw.

Dat alles overkwam een framework waarvan de reputatie sinds 2023 nauwelijks is veranderd: het Python-framework met alles erop en eraan, productief, eigenwijs, alleen synchroon, en terrein verliezend aan FastAPI. Het etiket "alleen synchroon" is verouderd, en het verhaal over de populariteit is ingewikkelder dan de cijfers in de koppen doen vermoeden.

Dit is dus mijn conclusie over de vraag of Django in 6.1 nog de moeite waard is: een oordeel met een cijfer, de projectvormen waar het bij past, en die waarvoor FastAPI inmiddels de betere keuze is.

De korte versie

Ja, met voorwaarden. Django 6.1 blijft de sterkste standaardkeuze wanneer de admin, auth, formulieren en de ORM het meeste werk zijn, en het async-gat is zo ver gedicht dat "alleen synchroon" geen reden meer is om het af te wijzen. Het is verkeerd voor één API met hoge gelijktijdigheid zonder adminlaag. 4 van de 5.

• Het pakket is wat je koopt. De ORM, migraties, sessie-authenticatie met permissies, een formulierlaag en een gegenereerde admin komen samen en al geïntegreerd, niet als vijf bibliotheken plus de naden ertussen.
• Achtergrondtaken zijn de zwakke as. Het Tasks-framework van Django 6.0 geeft je een decorator en een enqueue-aanroep, maar geen worker, dus Celery of iets vergelijkbaars blijft een keuze die je zelf maakt.
• Async is veel beter en duidelijk onaf. Django ondersteunt async views en asynchrone ORM-aanroepen, maar transacties werken niet in async-modus. Onder WSGI kunnen async views nog steeds gelijktijdige asynchrone I/O binnen één request uitvoeren, maar je krijgt niet de voordelen van een volledig asynchrone requeststack: langlopende requests en hoge verbindingsgelijktijdigheid vereisen ASGI.
• Plannen voorbij 2027 is makkelijker geworden. Vanaf januari 2028 brengt Django één feature release per jaar uit, elk met drie jaar ondersteuning, en verdwijnt het label "LTS" omdat elke release die toezegging nu krijgt.
• Geschikt voor admin- en CRUD-zware producten en voor kleine teams. Verkeerd voor één API met hoge doorvoer of streaming, zonder admin- of formulierlaag, waar FastAPI de natuurlijkere keuze is.

Hoe ik deze review heb opgebouwd: Dit is een evaluatie van Django 6.1, opgebouwd uit de release notes en documentatie van het project zelf, de bestuursaankondiging van de Django Software Foundation van augustus 2026, de ontwikkelaarsenquêtes van JetBrains/PSF uit 2024 en van Django uit 2025, en met naam genoemde vakmensen die publiek over hun eigen productie-ervaring schrijven. Ik heb voor dit stuk geen productietest van meerdere weken gedraaid, en er staan hier geen benchmarks: er is niets onder belasting getest. Django is gratis en BSD-gelicentieerd, en ik heb geen band met het project.

Wat is er sinds 2025 echt veranderd in Django?

Django 6.0 verscheen op 3 december 2025 met een eigen Tasks-framework en andere toevoegingen in de kern. De asynchrone ORM-interface is ouder: Django 4.1 introduceerde in 2022 asynchrone QuerySet-operaties. Django 6.1 werd op 5 augustus 2026 de huidige stabiele versie. Vervolgens kondigde het project op 10 augustus 2026 één feature release per jaar aan, vanaf januari 2028, met drie jaar ondersteuning per release en het einde van het LTS-label.

De release notes van 6.1 bevestigen dat 6.1 Python 3.12, 3.13 en 3.14 ondersteunt, waarbij de mainstream ondersteuning in april 2027 en de verlengde ondersteuning in december 2027 eindigt.

De versienummers veranderen mee. Ze dragen het jaartal: Django 2028, dan Django 2029 (in elk geval wordt "op welke versie zit je" makkelijker te beantwoorden). De drie jaar vallen uiteen in één jaar gewone bugfixes gevolgd door twee jaar beveiligings- en dataverliesfixes, precies wat LTS vroeger betekende, dus het label verdwijnt.

Dat laat een ongemakkelijk venster over voor een project dat vandaag begint. Django 5.2 is de huidige LTS, ondersteund tot april 2028. Django 6.1 is de huidige stabiele versie, maar de verlengde ondersteuning ervan eindigt in december 2027, ongeveer vier maanden voordat het ondersteuningsvenster van Django 5.2 in april 2028 afloopt.

Dus: het langste ondersteuningsvenster najagen betekent beginnen op 5.2. Het Tasks-framework en de nieuwste 6.x-functies willen betekent beginnen op 6.1 en een vroegere upgrade accepteren. Geen van beide is fout, en de ongemakkelijke keuze verdwijnt zodra Django 6.2 LTS in april 2027 verschijnt.

Ik lees de ritmewijziging als een goed teken. Projecten in verval rekken hun ondersteuningsbeloftes stilletjes op; ze herstructureren ze niet in het openbaar met een gedateerd plan. Dit project vereenvoudigde een toezegging die het al nakwam.

Wat Django nog steeds beter doet dan wat dan ook

Start een Django 6.1-project en je hebt werkende sessie-authenticatie met een rechtensysteem, een formulierlaag die valideert en rendert, een migratiesysteem gekoppeld aan je modellen, de ORM en een gegenereerde admin, voordat je één feature hebt geschreven. Dat is het hele verhaal, en het is het deel van Django dat niet hoefde te veranderen.

De waarde zit niet in het bestaan van die onderdelen. Ze zit erin dat ze op elkaar zijn ontworpen. Dezelfde modelrechten voeden de admin, en een modelwijziging genereert de migratie en werkt het adminformulier in één beweging bij.

Een gelijkwaardige dekking samenstellen uit losse bibliotheken brengt je er uiteindelijk wel. Het levert je ook een permanent onderhoudsoppervlak bij elke naad op, en in de naden zitten de bugs.

De admin is een tool voor medewerkers. De adminreferentie zegt dat het aanbevolen gebruik beperkt blijft tot een intern beheertool van een organisatie en dat het niet bedoeld is om je hele front-end omheen te bouwen. Modelrechten bepalen wat medewerkers binnen mogen doen, en om überhaupt binnen te komen is vereist: is_staff. Zie dat als een beperking, en het is een goede: je krijgt gratis een degelijke interne backoffice, en je krijgt geen klantgerichte UI, dus niemand komt in de verleiding er een uit te brengen.

De veiligheidsinstellingen zijn de andere helft van hetzelfde argument. CSRF-bescherming, SQL-parameterisering via de ORM, XSS-escaping in templates en clickjacking-bescherming staan standaard aan, in plaats van dingen te zijn waar een ervaren ontwikkelaar in review om moet denken te vragen. Een klein team erft keuzes van mensen die tien jaar aan beveiligingsrapporten hebben gelezen.

Dan is er nog de leeftijd. Die wordt gelezen als een last; ik lees hem als het ecosysteemargument. Django REST Framework bestaat en is saai op precies de manier waarop je wilt dat infrastructuur saai is.

Hetzelfde geldt voor volwassen pakketten voor de problemen die je in maand vier tegenkomt: filteren, throttling, opslagbackends, multi-tenancy-patronen, audit trails. En als een probleem zo ongebruikelijk is dat geen enkel pakket het dekt, is er meestal een vijftien jaar oude mailinglijstdraad over. Qua breedte denk ik niet dat iets anders in Python in de buurt komt, en juist die as is waarom iemand überhaupt voor Django kiest.

Waar Django tekortschiet

Django mist nog steeds volledige eigen typing over het hele framework, het behoudende tempo laat gaten waar "alles inbegrepen" je niet voor waarschuwt, en het Tasks-framework uit 6.0 heeft geen worker. Dat zijn de drie tekortkomingen bij 6.1. Het typinggat is degene die je dagelijks irriteert; Tasks is degene die je architectuurdiagram verandert.

Het grootste deel van het typingverhaal stel je nog steeds samen uit tooling van derden. django-stubs levert type stubs plus een eigen mypy-plug-in voor het dynamische gedrag van Django. De huidige documentatie noemt volledige mypy-ondersteuning en basisondersteuning voor pyright, pyrefly en ty. Dat is beter dan het was, maar het blijft een aparte compatibiliteitslaag in plaats van volwaardige eigen typing in Django zelf.

Kom je van een framework dat rond type hints is gebouwd, dan is dat een meetbare achteruitgang in de dagelijkse editorervaring.

Het behoudende tempo is net zozeer een kostenpost als een deugd. Django voegt dingen zorgvuldig en laat toe, en daarom is het framework dat je in 2019 leerde hetzelfde dat je vandaag kunt lezen. Daarom houden de batterijen ook op waar ze ophouden: geen WebSocket-laag in de kern, geen scheduler, geen mening over het orkestreren van async taken. Overschrijd een van die grenzen en je zet het weer zelf in elkaar.

Heeft Django 6 nog steeds Celery nodig?

Niet per se Celery. Het Tasks-framework van Django 6.0 standaardiseert hoe een taak wordt gedefinieerd en in de wachtrij gezet, maar het voert het gewachtrijde werk niet zelf uit. In productie heb je nog steeds een backend of workerproces nodig dat taken uitvoert; Celery is één optie, geen eis van het framework. De release notes van Django 6.0 zijn onomwonden over de grens: Django regelt het aanmaken en in de wachtrij zetten van taken, maar levert geen workermechanisme, en de uitvoering moet worden beheerd door externe infrastructuur, zoals een apart proces of een aparte service.

Wat je krijgt is de interface:

from django.core.mail import send_mail
from django.tasks import task

@task
def email_users(emails, subject, message):
    return send_mail(subject, message, None, emails)

email_users.enqueue(...) stuurt de taak naar een geconfigureerde backend. De twee backends die met 6.0 meekomen zijn bedoeld voor ontwikkeling en testen (dus niet degene waarop je hoopte). Planning, herhaling, retries en duurzaamheid vallen allemaal buiten het bestek.

Kevin Renskers, een praktiserend Django-ontwikkelaar, verwoordde het het scherpst in zijn review van Tasks:

In plaats daarvan kregen we een abstractie zonder implementatie.

Wat de vorm betreft heeft hij gelijk. De bedoeling zou ik anders formuleren. In de stemming van de Steering Council over DEP 14, het Django Enhancement Proposal achter de functie, betoogde Simon Charette dat het "iets zou moeten zijn waar frameworks als Celery en RQ op aansluiten", en de auteur van het voorstel omschreef het als een interface voor achtergrondworkers in plaats van een runtime. De eerlijke kritiek is dus niet dat Tasks stuk is. Ze is dat het veel smaller is dan "alles inbegrepen" deed verwachten, en dat het gat dat het dicht het saaie gat is: je applicatiecode kan werk in de wachtrij zetten zonder een specifieke queuebibliotheek te importeren.

Begroot dus een taakwachtrij voor elk Django 6.1-project dat retries, geplande taken of zicht op fouten nodig heeft. Het is dezelfde post als vóór 6.0, en als je hoopte dat deze release hem uit je architectuurdiagram zou schrappen: dat doet hij niet.

Als je al hebt besloten dat Django past en je de serverlaag liever niet vanaf nul opbouwt: de Django VPS van Cloudzy geeft je een zelfbeheerd startpunt met Django, Gunicorn, Nginx en PostgreSQL, plus roottoegang wanneer je Redis of Celery nodig hebt. De server blijft van jou om te beheren: je slaat de installatie vanaf een lege machine over, niet de operationele verantwoordelijkheid.

LEES

Python installeren op een VPS-server? | Een stapsgewijze gids

Is de async-ondersteuning van Django nu goed genoeg?

Goed genoeg dat "het is alleen synchroon" je niet langer zou moeten tegenhouden, en niet goed genoeg om er een volledig asynchrone datalaag op te bouwen. Beide helften kloppen bij 6.1. Welke op jou van toepassing is, hangt af van wat je bouwt en of je het onder ASGI of WSGI serveert, want die keuze bepaalt of je een volledig asynchrone requeststack en efficiënte afhandeling van langlevende verbindingen krijgt.

De kant van de mogelijkheden staat niet ter discussie. Elke methode van QuerySet die SQL activeert, heeft een asynchrone variant met het voorvoegsel a. De lus async for werkt over QuerySets heen, en de asynchrone database-API's bevatten modelmethoden zoals asave() en QuerySet-methoden zoals acreate(). Je kunt een async view schrijven die queries en gelijktijdige uitgaande HTTP-aanroepen awaitet zonder threadpool-wrapper. Vergeleken met de Django waarover de "alleen synchroon"-kritiek werd geschreven, is dit een ander framework.

Wat het gedrag bepaalt is het deploymentprotocol, niet de frameworkversie, en het is precies het punt dat Django's eigen forum steeds opnieuw moet uitleggen. De onderwerphandleiding over async stelt dat async views onder een WSGI-server in hun eigen eenmalige event loop draaien, dus je kunt asyncfuncties gebruiken maar "je krijgt niet de voordelen van een async stack".

Honderden verbindingen bedienen zonder Python-threads, traag streamen, long-polling: dat vereist ASGI. Dezelfde code, ander gelijktijdigheidsgedrag, en niets in het framework vertelt je welke je krijgt.

Die verwarring is taai. Een gebruiker onder de naam tomcypress opende een draadje op het forum van Django met de vraag waarom opeenvolgende requests naar een async view niet allemaal hun achtergrondwerk uitvoerden, en forumveteraan KenWhitesell wees hem op de WSGI-event loop. Die uitwisseling is van 2021 en daaraan is bij 6.1 niets veranderd.

Bovendien wordt ze van buitenaf versterkt. De voors-en-tegenspagina over Django bij TechVidvan vertelt lezers dat Django "niet in staat is meerdere requests tegelijk af te handelen", wat onjuist is voor Django 6.1 en precies het soort bewering is dat een evaluatie beëindigt voordat ze begint. Gelijktijdigheid ontbreekt niet aan het framework; ze wordt bepaald door de deployment.

De harde grens zijn transacties, en Django's eigen async-documentatie zegt het onomwonden:

Transacties werken nog niet in async-modus. Heb je een stuk code dat transactiegedrag nodig heeft, dan raden we aan dat stuk als één synchrone functie te schrijven en aan te roepen met sync_to_async().

Dezelfde pagina bestempelt bepaalde kernonderdelen van het framework als "async-onveilig" en verhindert dat ze in een asynchrone context draaien, met als gevolg SynchronousOnlyOperation als je het probeert. De vorm van een asynchrone Django 6.1-applicatie is dus: async views en asynchrone leesacties, met synchrone eilandjes overal waar schrijfacties atomiciteit nodig hebben. Werkbaar, en niet hetzelfde als een async-native framework. Mijn oordeel op deze as: merkbaar beter, niet af, en een duidelijke voldoende voor alles wat niet gelijktijdigheid vooropstelt.

Heeft FastAPI van Django de verkeerde standaardkeuze gemaakt?

Voor een specifieke en groeiende categorie projecten: ja. De Python Developers Survey 2024 van JetBrains en de Python Software Foundation, verzameld in oktober en november 2024 onder ruim 30.000 deelnemers, zette FastAPI op 38%, Django op 35% en Flask op 34% over alle respondenten. Onder respondenten die webontwikkeling aanvinkten als waar ze Python het meest voor gebruiken, stond Django op 61%, FastAPI op 56% en Flask op 39%.

Kijk goed naar die vraag voordat je hem meeneemt naar een planningsoverleg, want het is een meerkeuzevraag. Respondenten werd gevraagd welke frameworks ze gebruiken, niet welke ze hebben gekozen, en een ontwikkelaar die een Django-monoliet onderhoudt terwijl hij FastAPI-services schrijft telt in beide mee. Dit zijn geen exclusieve marktaandelen, en niemand heeft hier 38% van een markt. Wat ze laten zien is een gesplitst signaal: FastAPI stond over alle respondenten voor op Django, terwijl Django nog steeds voorstond op FastAPI onder respondenten die Python vooral voor webontwikkeling gebruiken.

De Django-specifieke enquête voegt nog een signaal toe, van mensen die het framework al gebruiken. De Django Developer Survey 2025, uitgevoerd door de Django Software Foundation met JetBrains op 4.655 gefilterde antwoorden verzameld tussen november 2024 en januari 2025, vond 82% die Django beroepsmatig schrijft, 77% die het hun meestgebruikte framework noemt, en 48% die met elke stabiele release upgradet, tegen 40% een jaar eerder. Zelfgeselecteerde respondenten, dus het beschrijft de huidige gebruikersbasis en niet de markt. Breedte van gebruik en diepte van betrokkenheid zijn verschillende signalen, en Django's tweede getal is gezonder dan het eerste.

De plekken waar FastAPI wint zijn smaller en scherper dan het verschil in de enquête suggereert. Een typegedreven API-oppervlak, waarin je Pydantic-modellen de validatielaag zijn en het gegenereerde OpenAPI-schema het contract, verslaat Django plus een serializerlaag. FastAPI is async-native op de requestlaag, maar de eigen documentatie is expliciet : path operations kunnen op beide manieren worden geschreven, en een handler of dependency die met een gewone def worden gedeclareerd, draaien in een externe threadpool.

En een dienst zonder admin, zonder formulieren en zonder templates draagt Django's batterijen als dood gewicht mee: je betaalt voor de opvattingen van het framework en gebruikt er een kwart van. Als dat is wat je bouwt, is het momentum geen hype en zou je het moeten volgen.

Wie zou voor Django moeten kiezen?

Grijp bij 6.1 naar Django wanneer de admin, auth, formulieren en de ORM het grootste deel van je aanstaande werk zijn: interne tools, marktplaatsen, back-office-SaaS. Het klopt ook voor een klein team dat die dingen vanaf dag één werkend nodig heeft, en voor een team dat nu al moet weten hoe zijn ondersteuningsvenster er in 2029 uitziet.

Producten waarbij de opvattingen van het framework het grootste deel van het echte werk dekken. Alles met een rechtenmatrix en veel CRUD achter een login. Hier is het juist de bedoeling en geen kostenpost dat het framework de structurele keuzes maakt, want die keuzes zijn het grootste deel van wat je toch al zou bouwen.

Kleine teams die vanaf dag één productief moeten zijn. Met drie ontwikkelaars en geen platform engineer begint het ene team features te schrijven terwijl het andere authenticatiebibliotheken gaat evalueren. Vanaf dat punt loopt dat verschil steeds verder op.

Teams die al op Django zitten en de komende drie jaar plannen. Django 5.2 geeft je een ondersteunde ondergrens tot april 2028, en de jaarlijkse cadans geeft je daarna een voorspelbare. Een leesbare supporthorizon is bij het plannen geld waard, en het is ongewoon om er een zo duidelijk aangereikt te krijgen.

Wie zou niet voor Django moeten kiezen?

Kies Django niet voor een API met hoge doorvoer of streaming zonder admin erachter: FastAPI is voor die projectvorm de schonere standaardkeuze. Kies het niet als je dit jaar asynchrone datatoegang inclusief transacties nodig hebt, want 6.1 heeft dat niet. En kies het niet in de verwachting dat de batterijen je achtergrondtaken uitvoeren.

Eén API met hoge doorvoer of streaming, zonder admin- en zonder formulierlaag. Vrijwel niets waar Django goed in is draagt bij deze projectvorm iets, dus je zou de structuur van een heel framework onderhouden voor een dienst die een router en een validator nodig had.

Teams die vandaag volledig asynchrone datatoegang nodig hebben, inclusief transacties. Django 6.1 ondersteunt geen transacties in async-modus. Je schrijfacties verpakken in sync_to_async() is een legitiem patroon, geen tijdelijke oplossing waar je dit jaar overheen groeit, en waar dat onacceptabel is, is het een blocker en geen schrammetje.

Teams die "alles inbegrepen" lezen alsof het de uitvoering van achtergrondtaken dekt. Tasks levert geen worker mee. Als je plan ervan uitging dat 6.0 de wachtrij uit je stack haalde, moet er weer een wachtrij in het plan voordat je je aan het framework verbindt.

Welk webframework je als eerste leert, is een andere vraag met een ander antwoord; de FAQ hieronder heeft de korte versie.

Weten waar Django ophoudt is wat het veilig maakt om ermee te beginnen: de bovenstaande uitgangen zijn zichtbaar vóór je je vastlegt, in plaats van dat je ze achteraf ontdekt.

Veelgestelde vragen

Is Django dood?

Nee. Django bracht tussen december 2025 en augustus 2026 twee feature releases uit en publiceerde een geherstructureerd releaseplan dat tot in de jaren dertig loopt. FastAPI is snel gegroeid en stond in de Python Developers Survey 2024 over alle respondenten met 38% tegen 35% voor op Django, terwijl Django met 61% tegen 56% voorstond onder respondenten die Python vooral voor webontwikkeling gebruiken. Snelle groei van een nieuwer framework en de dood van een ouder framework zijn verschillende beweringen.

Is Django geschikt voor beginners?

Ja, met de kanttekening dat het het meeste is om in één keer te leren. Djangos breedte is wat het productief maakt, en het betekent dat een beginner de ORM, migraties, de templatelaag en de admin tegenkomt voordat hij iets heeft opgeleverd. Het tegendraadse betoog is de moeite van het lezen waard: een post van Bite Code! betoogt dat beginners juist met Django zouden moeten beginnen omdat de standaardinstellingen architectuurfouten voorkomen die een minimaal framework je alleen laat maken.

Is Django sneller dan Flask?

Er is geen universeel antwoord. Voor deze review is geen benchmark gedraaid, en ik zou er geen vertrouwen aan geven zonder de workload en deployment te kennen. In veel applicaties tellen databasequery's, N+1-problemen en externe API-aanroepen zwaarder dan de overhead van het framework. Als ruwe requestdoorvoer meeweegt in de beslissing, meet dan de applicatie en serverconfiguratie die je daadwerkelijk van plan bent te draaien.

Met welke Django-versie zou je een nieuw project moeten starten?

Begin op 5.2 als het langste ondersteuningsvenster het zwaarst weegt: het is de huidige LTS, ondersteund tot april 2028. Begin op 6.1 als je het Tasks-framework en de nieuwste 6.x-functies wilt, waarbij je mainstream ondersteuning tot ongeveer april 2027 en verlengde ondersteuning tot december 2027 accepteert, en daarna een upgrade naar Django 6.2 LTS plant zodra die in april 2027 verschijnt. Voor Django 6.2 staat verlengde ondersteuning tot april 2030 gepland. Vanaf januari 2028 draagt elke jaarlijkse feature release drie jaar ondersteuning.

Moet je eerst Django of FastAPI leren?

Leer degene die past bij het werk dat je wilt doen. Django leert je hoe een volledige webapplicatie in elkaar zit: datamodellering, migraties, authenticatie, formulieren, templates en de admin, met de structuur al voor je bepaald. FastAPI leert je getypeerd API-ontwerp en asynchroon Python, waarbij vrijwel niets voor je bepaald is. Geen van beide is in het abstracte de beginnersvriendelijke optie, en degene kiezen die dichter bij je beoogde baan ligt is beter dan de makkelijkste kiezen.