Django-anmeldelse: Er det stadig værd at bruge?

Django udsendte to feature releases og skrev hele sin udgivelseskadence om i de otte måneder mellem december 2025 og august 2026.

Det ramte et framework, hvis omdømme knap har flyttet sig siden 2023: det Python-framework med alt indbygget, som er produktivt, meningsfuldt sat op, kun synkront og taber terræn til FastAPI. Etiketten "kun synkron" er forældet, og historien om populariteten er mere kompliceret, end overskrifternes tal antyder.

Så her er, hvor jeg lander på spørgsmålet om, hvorvidt Django stadig er værd at bruge i 6.1: en dom med karakter, de projekttyper det passer til, og dem hvor FastAPI nu er det bedre valg.

Den korte version

Ja, med forbehold. Django 6.1 er stadig det stærkeste standardvalg, når admin, auth, formularer og ORM udgør det meste af arbejdet, og async-afstanden er blevet så lille, at "kun synkron" ikke længere er en grund til at vælge det fra. Det er forkert til et enkelt API med høj samtidighed og uden adminflade. 4 ud af 5.

• Det er pakken, du køber. ORM, migreringer, session-auth med rettigheder, et formularlag og et genereret admin kommer samlet og allerede integreret, ikke som fem biblioteker plus sømmene imellem dem.
• Baggrundsjob er den svage akse. Tasks-frameworket i Django 6.0 giver dig en dekorator og et enqueue-kald, men ingen worker, så Celery eller noget tilsvarende er stadig en beslutning, du selv tager.
• Async er meget bedre og tydeligvis ufærdigt. Django understøtter async views og asynkrone ORM-kald, men transaktioner virker ikke i async-tilstand. Under WSGI kan async views stadig køre samtidig asynkron I/O inden for én forespørgsel, men du får ikke fordelene ved en fuldt asynkron forespørgselsstak; langvarige forespørgsler og høj forbindelsessamtidighed kræver ASGI.
• Det er blevet lettere at planlægge efter 2027. Fra januar 2028 udsender Django én feature release om året, hver med tre års support, og "LTS"-mærkatet forsvinder, fordi hver eneste udgivelse nu får den forpligtelse.
• Rigtigt til admin- og CRUD-tunge produkter og til små teams. Forkert til et enkelt API med høj gennemstrømning eller streaming uden admin- eller formularflade, hvor FastAPI er det mere naturlige valg.

Sådan har jeg lavet denne anmeldelse: Dette er en vurdering af Django 6.1 bygget på projektets egne release notes og dokumentation, Django Software Foundations governance-udmelding fra august 2026, udviklerundersøgelserne fra JetBrains/PSF i 2024 og Django i 2025 samt navngivne fagfolk, der offentligt skriver om deres egen produktionserfaring. Jeg har ikke kørt en produktionstest over flere uger til dette stykke, og der er ingen benchmarks her: intet er blevet belastningstestet. Django er gratis og BSD-licenseret, og jeg har ingen relation til projektet.

Hvad har egentlig ændret sig i Django siden 2025?

Django 6.0 udkom den 3. december 2025 med et indbygget Tasks-framework og andre tilføjelser i kernen. Den asynkrone ORM-grænseflade er ældre: Django 4.1 indførte asynkrone QuerySet-operationer i 2022. Django 6.1 blev den aktuelle stabile version den 5. august 2026. Derefter annoncerede projektet den 10. august 2026 én feature release om året fra januar 2028, tre års support til hver udgivelse og enden på LTS-mærkatet.

Release notes til 6.1 bekræfter, at 6.1 understøtter Python 3.12, 3.13 og 3.14, hvor mainstream-support slutter i april 2027 og udvidet support i december 2027.

Versionsnumrene ændrer sig med. De bærer årstallet: Django 2028, derefter Django 2029 (i det mindste bliver "hvilken version kører I" lettere at svare på). De tre år deler sig i ét år med almindelige fejlrettelser efterfulgt af to år med sikkerheds- og datatabsrettelser, hvilket er præcis det, LTS plejede at betyde, så mærkatet forsvinder.

Det efterlader et akavet vindue for et projekt, der starter i dag. Django 5.2 er den nuværende LTS og understøttes til april 2028. Django 6.1 er den aktuelle stabile version, men dens udvidede support slutter i december 2027, cirka fire måneder før Django 5.2's supportvindue udløber i april 2028.

Så: vil man have det længste supportvindue, starter man på 5.2. Vil man have Tasks-frameworket og de nyeste 6.x-funktioner, starter man på 6.1 og accepterer en opgradering tidligere. Ingen af delene er forkert, og det akavede valg forsvinder, når Django 6.2 LTS kommer i april 2027.

Jeg læser kadenceændringen som et godt tegn. Projekter i tilbagegang strækker stille og roligt deres supportløfter; de omstrukturerer dem ikke offentligt med en dateret plan. Dette projekt forenklede et løfte, det allerede holdt.

Hvad Django stadig gør bedre end noget andet

Start et Django 6.1-projekt, og du har fungerende session-auth med et rettighedssystem, et formularlag der validerer og renderer, et migreringssystem bundet til dine modeller, ORM'en og et genereret admin, før du har skrevet en eneste feature. Det er hele pointen, og det er den del af Django, der ikke har haft brug for at ændre sig.

Værdien ligger ikke i, at de dele findes. Den ligger i, at de er designet op imod hinanden. De samme modelrettigheder føder admin, og en modelændring genererer migreringen og opdaterer adminformularen i samme åndedrag.

At samle tilsvarende dækning af uafhængige biblioteker fører dig derhen til sidst. Det giver dig også en permanent vedligeholdelsesflade ved hver søm, og det er i sømmene, fejlene bor.

Admin er et værktøj til medarbejdere. Admin-referencen siger, at dens anbefalede brug er begrænset til en organisations interne administrationsværktøj, og at den ikke er tænkt som noget, man bygger hele sin frontend op omkring. Modelrettigheder styrer, hvad medarbejdere må gøre, når de er inde, og for overhovedet at komme ind kræves is_staff. Betragt det som en begrænsning, og det er en god en: du får gratis et kompetent internt backoffice, og du får ikke et kundevendt UI, så ingen fristes til at sende et i luften.

Sikkerhedsstandarderne er den anden halvdel af samme argument. CSRF-beskyttelse, SQL-parameterisering gennem ORM'en, XSS-escaping i skabeloner og clickjacking-beskyttelse er slået til som standard i stedet for at være noget, en erfaren udvikler skal huske at bede om i review. Et lille team arver valg truffet af folk, der har læst et årti af sikkerhedsrapporter.

Så er der alderen. Den læses som en byrde; jeg læser den som økosystemargumentet. Django REST Framework findes og er kedeligt på præcis den måde, man ønsker, at infrastruktur skal være kedelig.

Det samme gælder modne pakker til de problemer, man rammer i måned fire: filtrering, throttling, storage-backends, multi-tenancy-mønstre, audit trails. Og når et problem er usædvanligt nok til, at ingen pakke dækker det, findes der som regel en femten år gammel mailinglistetråd om det. På bredden tror jeg ikke, at noget andet i Python kommer i nærheden, og det er netop den akse, der gør, at nogen overhovedet vælger Django.

Hvor Django kommer til kort

Django mangler stadig gennemgribende indbygget typing på tværs af frameworket, det konservative tempo efterlader huller, som "alt inkluderet" ikke advarer om, og Tasks-frameworket fra 6.0 har ingen worker. Det er de tre mangler ved 6.1. Typing-hullet er det, der irriterer dagligt; Tasks er det, der ændrer dit arkitekturdiagram.

Størstedelen af typing-historien samler du stadig selv fra tredjepartsværktøjer. django-stubs leverer type stubs plus et særligt mypy-plugin til Djangos dynamiske opførsel. Den nuværende dokumentation nævner fuld mypy-understøttelse og grundlæggende understøttelse af pyright, pyrefly og ty. Det er en bedre situation end før, men det er stadig et separat kompatibilitetslag frem for gennemgribende indbygget typing i Django selv.

Kommer man fra et framework bygget op omkring type hints, er det en målbar tilbagegang i den daglige editoroplevelse.

Det konservative tempo er lige så meget en omkostning som en dyd. Django tilføjer ting omhyggeligt og sent, og derfor er det framework, du lærte i 2019, det samme, du kan læse i dag. Det er også derfor, batterierne stopper, hvor de stopper: intet WebSocket-lag i kernen, ingen scheduler, ingen holdning til orkestrering af asynkrone opgaver. Kryds en af de linjer, og du sidder igen og samler tingene selv.

Har Django 6 stadig brug for Celery?

Ikke specifikt Celery. Tasks-frameworket i Django 6.0 standardiserer, hvordan en opgave defineres og lægges i kø, men det kører ikke selv det køede arbejde. I produktion har du stadig brug for en backend eller en workerproces, der udfører opgaverne; Celery er én mulighed, ikke et krav fra frameworket. Release notes til Django 6.0 er kontante omkring grænsen: Django håndterer oprettelse og kølægning af opgaver, men leverer ingen worker-mekanisme, og udførelsen skal styres af ekstern infrastruktur, for eksempel en separat proces eller tjeneste.

Det, du får, er grænsefladen:

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(...) sender opgaven til en konfigureret backend. De to backends, der følger med 6.0, er tænkt til udvikling og test (altså ikke den, du håbede på). Planlægning, gentagelse, retries og holdbarhed ligger alle uden for rammerne.

Kevin Renskers, en praktiserende Django-udvikler, formulerede det skarpest i sin anmeldelse af Tasks:

I stedet fik vi en abstraktion uden en implementering.

Hvad formen angår, har han ret. Hensigten ville jeg dog indramme anderledes. I Steering Councils afstemning om DEP 14, det Django Enhancement Proposal der ligger bag funktionen, argumenterede Simon Charette for, at det "burde være noget, som frameworks som Celery og RQ kobler sig på", og forslagets forfatter beskrev det som en grænseflade til baggrundsworkere frem for en runtime. Den fair kritik er altså ikke, at Tasks er i stykker. Den er, at det er langt snævrere, end "alt inkluderet" fik folk til at forvente, og at det hul, det lukker, er det kedelige: din applikationskode kan lægge arbejde i kø uden at importere et bestemt kø-bibliotek.

Så budgettér med en opgavekø i ethvert Django 6.1-projekt, der har brug for retries, planlagt arbejde eller indblik i fejl. Det er den samme post som før 6.0, og hvis du håbede, at denne udgivelse ville slette den fra dit arkitekturdiagram, gør den det ikke.

Hvis du allerede har besluttet, at Django passer, og helst ikke vil samle serverlaget fra bunden, Cloudzys Django VPS giver dig et selvadministreret udgangspunkt med Django, Gunicorn, Nginx og PostgreSQL, plus root-adgang når du har brug for Redis eller Celery. Serveren er stadig din at drive; du springer opsætningen fra en tom maskine over, ikke driftsansvaret.

LÆS

Sådan installerer du Python på en VPS-server | En trin-for-trin guide

Er Djangos async-understøttelse god nok nu?

God nok til, at "den er kun synkron" ikke længere bør stoppe dig, og ikke god nok til at bygge et fuldt asynkront datalag oven på. Begge halvdele er sande i 6.1. Hvilken der gælder for dig, afhænger af, hvad du bygger, og af om du serverer det under ASGI eller WSGI, for det valg afgør, om du får en fuldt asynkron forespørgselsstak og effektiv håndtering af langlivede forbindelser.

Kapabilitetssiden er der ikke uenighed om. Hver metode i QuerySet der udløser SQL, har en asynkron variant med præfikset a. Løkken async for fungerer på tværs af QuerySets, og de asynkrone database-API'er omfatter modelmetoder som asave() og QuerySet-metoder som acreate(). Du kan skrive en async view, der awaiter forespørgsler og samtidige udgående HTTP-kald uden en threadpool-wrapper. Sammenlignet med det Django, som "kun synkron"-kritikken blev skrevet om, er det et andet framework.

Det, der afgør adfærden, er deployment-protokollen, ikke frameworkets version, og det er netop den del, Djangos eget forum bliver ved med at måtte forklare igen. Emneguiden om async fastslår, at async views under en WSGI-server kører i deres egen engangs-event loop, så du kan bruge async-funktioner, men "du får ikke fordelene ved en async-stak".

At betjene hundredvis af forbindelser uden Python-tråde, langsom streaming, long-polling: det kræver ASGI. Samme kode, anden samtidighedsadfærd, og intet i frameworket fortæller dig, hvilken du får.

Den forvirring har et langt liv. En bruger under navnet tomcypress åbnede en tråd på Djangos forum hvor han spurgte, hvorfor på hinanden følgende forespørgsler til en async view ikke alle udførte deres baggrundsarbejde, og forumveteranen KenWhitesell henviste ham til WSGI-event loopet. Den udveksling er fra 2021, og intet ved den har ændret sig i 6.1.

Den bliver desuden forstærket udefra. TechVidvans side om fordele og ulemper ved Django fortæller læserne, at Django "ikke er i stand til at håndtere flere forespørgsler samtidig", hvilket er forkert om Django 6.1 og er præcis den slags påstand, der afslutter en evaluering, før den begynder. Samtidighed er ikke noget, frameworket mangler; det er noget, deploymentet afgør.

Det hårde stop er transaktioner, og Djangos egen async-dokumentation siger det lige ud:

Transaktioner virker endnu ikke i async-tilstand. Har du et stykke kode, der har brug for transaktionsadfærd, anbefaler vi, at du skriver det stykke som én synkron funktion og kalder den med sync_to_async().

Samme side klassificerer visse centrale dele af frameworket som "async-usikre" og blokerer dem fra at køre i en async-kontekst, hvorved den rejser SynchronousOnlyOperation , hvis du forsøger. Formen på en asynkron Django 6.1-applikation er altså: async views og asynkrone læsninger med synkrone øer alle de steder, hvor skrivninger kræver atomicitet. Det kan lade sig gøre, og det er ikke det samme som et async-native framework. Min vurdering på denne akse: mærkbart bedre, ikke færdigt, og en klar bestået for alt, der ikke sætter samtidighed først.

Har FastAPI gjort Django til det forkerte standardvalg?

For en bestemt og voksende kategori af projekter: ja. Python Developers Survey 2024 fra JetBrains og Python Software Foundation, indsamlet hen over oktober og november 2024 med mere end 30.000 deltagere, placerede FastAPI på 38 %, Django på 35 % og Flask på 34 % blandt alle respondenter. Blandt respondenter, der valgte webudvikling som det, de mest bruger Python til, lå Django på 61 %, FastAPI på 56 % og Flask på 39 %.

Se godt på det spørgsmål, før du tager det med til et planlægningsmøde, for det er multiple choice. Respondenterne blev spurgt, hvilke frameworks de bruger, ikke hvilket de valgte, og en udvikler, der vedligeholder en Django-monolit og samtidig skriver FastAPI-tjenester, tæller i begge. Det er ikke gensidigt udelukkende markedsandele, og ingen har 38 % af et marked her. Det, de viser, er et delt signal: FastAPI førte over Django blandt alle respondenter, mens Django stadig førte over FastAPI blandt respondenter, der primært bruger Python til webudvikling.

Den Django-specifikke undersøgelse tilføjer endnu et signal, fra folk der allerede bruger frameworket. Django Developer Survey 2025, gennemført af Django Software Foundation sammen med JetBrains på 4.655 filtrerede svar indsamlet mellem november 2024 og januar 2025, fandt 82 %, der skriver Django professionelt, 77 %, der kalder det deres mest brugte framework, og 48 %, der opgraderer ved hver stabil udgivelse, op fra 40 % året før. Respondenterne har selv meldt sig, så det beskriver den nuværende brugerbase snarere end markedet. Bredden i brugen og dybden i engagementet er forskellige signaler, og Djangos andet tal er sundere end det første.

De steder, hvor FastAPI vinder, er smallere og skarpere, end spredningen i undersøgelsen antyder. En typedrevet API-flade, hvor dine Pydantic-modeller er valideringslaget og det genererede OpenAPI-skema er kontrakten, slår Django plus et serializer-lag. FastAPI er async-native på request-laget, men dets egen dokumentation er eksplicit : path operations kan skrives på begge måder, og en handler eller dependency erklæret med et almindeligt def kører i en ekstern threadpool.

Og en tjeneste uden admin, uden formularer og uden skabeloner slæber rundt på Djangos batterier som dødvægt: du betaler for frameworkets holdninger og bruger en fjerdedel af dem. Er det dét, du bygger, er momentum ikke hype, og du bør følge det.

Hvem bør vælge Django?

Grib til Django i 6.1, når admin, auth, formularer og ORM udgør det meste af det arbejde, du står over for: interne værktøjer, markedspladser, back office-SaaS. Det er også rigtigt for et lille team, der har brug for, at de ting virker fra dag ét, og for et team, der allerede nu skal vide, hvordan dets supportvindue ser ud i 2029.

Produkter, hvor frameworkets holdninger dækker det meste af det egentlige arbejde. Alt med en rettighedsmatrix og masser af CRUD bag et login. Her er det pointen og ikke en omkostning, at frameworket træffer de strukturelle valg, for netop de valg er det meste af det, du alligevel ville bygge.

Små teams, der skal være produktive fra dag ét. Med tre udviklere og ingen platform engineer begynder det ene team at skrive features, mens det andet begynder at evaluere auth-biblioteker. Derfra vokser forskellen med renters rente.

Teams, der allerede kører Django og planlægger de næste tre år. Django 5.2 giver dig et understøttet gulv frem til april 2028, og den årlige kadence giver dig et forudsigeligt gulv derefter. En læselig supporthorisont er penge værd på planlægningstidspunktet, og det er usædvanligt at få den rakt så tydeligt.

Hvem bør ikke vælge Django?

Vælg ikke Django til et API med høj gennemstrømning eller streaming uden admin bagved: FastAPI er det renere standardvalg til den slags projekt. Vælg det ikke, hvis du i år har brug for asynkron dataadgang inklusive transaktioner, for det har 6.1 ikke. Og vælg det ikke i forventning om, at batterierne kører dine baggrundsjob.

Et enkelt API med høj gennemstrømning eller streaming, uden admin- og uden formularflade. Næsten intet af det, Django er god til, er bærende for denne projektform, så du ville vedligeholde et helt frameworks struktur for en tjeneste, der havde brug for en router og en validator.

Teams, der i dag har brug for fuldt asynkron dataadgang, transaktioner inklusive. Django 6.1 understøtter ikke transaktioner i async-tilstand. At pakke dine skrivninger ind i sync_to_async() er et legitimt mønster, ikke en nødløsning du vokser fra i år, og hvor det er uacceptabelt, er det en showstopper og ikke en skramme.

Teams, der læser "alt inkluderet" som om det dækker afvikling af baggrundsjob. Tasks leveres ikke med en worker. Hvis din plan antog, at 6.0 fjernede køen fra din stak, skal der en kø tilbage i planen, før du binder dig til frameworket.

Hvilket webframework man skal lære først, er et andet spørgsmål med et andet svar; FAQ'en nedenfor har den korte version.

At vide, hvor Django holder op, er netop det, der gør det sikkert at starte: udgangene ovenfor er synlige, før du binder dig, i stedet for at blive opdaget bagefter.

Ofte stillede spørgsmål

Er Django dødt?

Nej. Django udsendte to feature releases mellem december 2025 og august 2026 og offentliggjorde en omstruktureret udgivelsesplan, der løber ind i 2030'erne. FastAPI er vokset hurtigt og førte over Django med 38 % mod 35 % blandt alle respondenter i Python Developers Survey 2024, mens Django førte 61 % mod 56 % blandt respondenter, der primært bruger Python til webudvikling. Hurtig vækst hos et nyere framework og et ældre frameworks død er forskellige påstande.

Er Django godt for begyndere?

Ja, med det forbehold at det er mest at lære på én gang. Djangos bredde er det, der gør det produktivt, og det betyder, at en begynder løber ind i ORM'en, migreringer, skabelonlaget og admin, før han har sendt noget som helst i luften. Modargumentet er værd at læse: et indlæg fra Bite Code! argumenterer for, at begyndere netop bør starte med Django, fordi dets standardindstillinger forhindrer arkitekturfejl, som et minimalt framework lader dig begå på egen hånd.

Er Django hurtigere end Flask?

Der findes ikke noget universelt svar. Der blev ikke kørt nogen benchmark til denne anmeldelse, og jeg ville ikke stole på en uden at kende dens arbejdsbelastning og deployment. I mange applikationer betyder databaseforespørgsler, N+1-problemer og eksterne API-kald mere end frameworkets overhead. Hvis rå request-gennemstrømning vejer tungt i beslutningen, så mål den applikation og serverkonfiguration, du faktisk har tænkt dig at køre.

Hvilken Django-version bør man starte et nyt projekt på?

Start på 5.2, hvis det længste supportvindue betyder mest: det er den nuværende LTS, understøttet til april 2028. Start på 6.1, hvis du vil have Tasks-frameworket og de nyeste 6.x-funktioner, og accepter mainstream-support til cirka april 2027 og udvidet support til december 2027, og planlæg så en opgradering til Django 6.2 LTS, når den kommer i april 2027. Django 6.2 er planlagt med udvidet support frem til april 2030. Fra januar 2028 og frem bærer hver årlig feature release tre års support.

Skal man lære Django eller FastAPI først?

Lær den, der passer til det arbejde, du gerne vil lave. Django lærer dig, hvordan en komplet webapplikation hænger sammen: datamodellering, migreringer, auth, formularer, skabeloner og admin, med strukturen besluttet på forhånd for dig. FastAPI lærer dig typet API-design og asynkron Python, hvor næsten intet er besluttet for dig. Ingen af dem er i abstrakt forstand det begyndervenlige valg, og at vælge den, der ligger tættest på det job, du sigter efter, slår at vælge den nemmeste.