Recenzja Django: czy nadal warto?

W ciągu ośmiu miesięcy, od grudnia 2025 do sierpnia 2026, Django wydało dwie wersje funkcjonalne i napisało od nowa cały swój harmonogram wydań.

Spotkało to framework, którego reputacja od 2023 roku prawie się nie zmieniła: pythonowy framework z całym wyposażeniem, produktywny, z własnym zdaniem, wyłącznie synchroniczny i tracący grunt na rzecz FastAPI. Etykieta „tylko synchroniczny” jest nieaktualna, a historia popularności jest bardziej skomplikowana, niż sugerują nagłówkowe liczby.

Oto więc moja odpowiedź na pytanie, czy Django w wersji 6.1 nadal warto: werdykt z oceną, typy projektów, do których pasuje, i te, dla których lepszym wyborem jest dziś FastAPI.

Krótka wersja

Tak, pod warunkami. Django 6.1 pozostaje najmocniejszym domyślnym wyborem, gdy panel administracyjny, uwierzytelnianie, formularze i ORM stanowią większość pracy, a dystans w asynchroniczności zmniejszył się na tyle, że „tylko synchroniczny” nie jest już powodem do odrzucenia. Nie nadaje się do pojedynczego API o wysokiej współbieżności bez warstwy administracyjnej. 4 na 5.

• Kupujesz właśnie ten komplet. ORM, migracje, uwierzytelnianie sesyjne z uprawnieniami, warstwa formularzy i wygenerowany panel administracyjny przychodzą razem i już zintegrowane, a nie jako pięć bibliotek plus szwy między nimi.
• Zadania w tle to słaba oś. Framework Tasks w Django 6.0 daje dekorator i wywołanie kolejkujące, ale nie daje workera, więc Celery lub jego odpowiednik pozostaje decyzją, którą podejmujesz sam.
• Asynchroniczność jest znacznie lepsza i wyraźnie niedokończona. Django obsługuje asynchroniczne widoki i asynchroniczne wywołania ORM, ale transakcje nie działają w trybie asynchronicznym. Pod WSGI asynchroniczne widoki wciąż mogą wykonywać równoległe asynchroniczne operacje we/wy w obrębie żądania, lecz nie otrzymujesz korzyści w pełni asynchronicznego stosu żądań; długo trwające żądania i wysoka współbieżność połączeń wymagają ASGI.
• Planowanie po 2027 roku stało się łatwiejsze. Od stycznia 2028 Django wydaje jedną wersję funkcjonalną rocznie, każdą z trzyletnim wsparciem, a etykieta „LTS” znika, bo takie zobowiązanie obejmuje teraz każde wydanie.
• Odpowiedni dla produktów mocno opartych na panelu administracyjnym i CRUD oraz dla małych zespołów. Zły wybór dla pojedynczego API o wysokiej przepustowości lub strumieniowego, bez panelu administracyjnego i formularzy, gdzie naturalniejszym wyborem jest FastAPI.

Jak powstała ta recenzja: To ocena Django 6.1 zbudowana na podstawie notatek wydania i dokumentacji samego projektu, ogłoszenia Django Software Foundation w sprawie zarządzania projektem z sierpnia 2026, ankiet deweloperskich JetBrains/PSF z 2024 i Django z 2025 oraz wymienionych z nazwiska praktyków, którzy publicznie piszą o własnym doświadczeniu produkcyjnym. Na potrzeby tego tekstu nie prowadziłem kilkutygodniowego wdrożenia produkcyjnego i nie ma tu żadnych benchmarków: nic nie było testowane pod obciążeniem. Django jest darmowe i na licencji BSD, a mnie nic z projektem nie łączy.

Co naprawdę zmieniło się w Django od 2025 roku?

Django 6.0 ukazało się 3 grudnia 2025 z własnym frameworkiem Tasks i innymi dodatkami w rdzeniu. Asynchroniczny interfejs ORM jest starszy: Django 4.1 wprowadziło asynchroniczne operacje QuerySet już w 2022 roku. Django 6.1 stało się bieżącą wersją stabilną 5 sierpnia 2026. Następnie 10 sierpnia 2026 projekt ogłosił jedno wydanie funkcjonalne rocznie od stycznia 2028, trzy lata wsparcia dla każdego wydania i koniec etykiety LTS.

Notatki wydania 6.1 potwierdzają, że 6.1 obsługuje Pythona 3.12, 3.13 i 3.14, przy czym wsparcie główne kończy się w kwietniu 2027, a rozszerzone w grudniu 2027.

Wraz z tym zmieniają się numery wersji. Noszą rok: Django 2028, potem Django 2029 (przynajmniej na pytanie „na jakiej jesteś wersji” łatwiej odpowiedzieć). Trzy lata dzielą się na rok zwykłych poprawek błędów, a potem dwa lata poprawek bezpieczeństwa i utraty danych, czyli dokładnie to, co kiedyś oznaczało LTS, więc etykieta znika.

To zostawia niewygodne okno dla projektu, który zaczyna się dziś. Django 5.2 jest obecnym LTS i jest wspierane do kwietnia 2028. Django 6.1 to bieżąca wersja stabilna, ale jej rozszerzone wsparcie kończy się w grudniu 2027, jakieś cztery miesiące przed końcem okna wsparcia Django 5.2 w kwietniu 2028.

Zatem: pogoń za najdłuższym oknem wsparcia oznacza start na 5.2. Chęć posiadania frameworka Tasks i najnowszych funkcji gałęzi 6.x oznacza start na 6.1 i zgodę na wcześniejszą aktualizację. Żadne z tych podejść nie jest złe, a niewygodny wybór zniknie, gdy w kwietniu 2027 pojawi się Django 6.2 LTS.

Zmianę rytmu odczytuję jako dobry znak. Projekty w zaniku po cichu rozciągają swoje obietnice wsparcia; nie przebudowują ich publicznie, z planem opatrzonym datami. Ten uprościł zobowiązanie, które i tak już wypełniał.

Co Django wciąż robi lepiej niż cokolwiek innego

Załóż projekt w Django 6.1, a masz działające uwierzytelnianie sesyjne z systemem uprawnień, warstwę formularzy, która waliduje i renderuje, system migracji powiązany z twoimi modelami, ORM oraz wygenerowany panel administracyjny, zanim napiszesz choć jedną funkcję. To cała propozycja i jest to ta część Django, która nie musiała się zmieniać.

Wartość nie polega na tym, że te elementy istnieją. Polega na tym, że zaprojektowano je względem siebie. Te same uprawnienia modeli zasilają panel administracyjny, a zmiana modelu jednym ruchem generuje migrację i aktualizuje formularz w panelu.

Złożenie równoważnego pokrycia z niezależnych bibliotek w końcu się udaje. Daje też stałą powierzchnię utrzymaniową na każdym szwie, a to właśnie w szwach mieszkają błędy.

Panel administracyjny to narzędzie dla pracowników. Dokumentacja referencyjna panelu administracyjnego mówi, że zalecane zastosowanie ogranicza się do wewnętrznego narzędzia zarządzania w organizacji i że nie jest on przeznaczony do budowania wokół niego całego front-endu. Uprawnienia modeli decydują, co pracownicy mogą robić w środku, a żeby w ogóle wejść, wymagane jest is_staff. Potraktuj to jako ograniczenie, i to dobre: dostajesz za darmo sprawne wewnętrzne zaplecze, a nie dostajesz interfejsu dla klientów, więc nikt nie ma pokusy go wypuścić.

Domyślne ustawienia bezpieczeństwa to druga połowa tego samego argumentu. Ochrona CSRF, parametryzacja SQL przez ORM, escapowanie XSS w szablonach i ochrona przed clickjackingiem są włączone domyślnie, zamiast być rzeczami, o które doświadczony programista musi pamiętać poprosić przy przeglądzie kodu. Mały zespół dziedziczy decyzje ludzi, którzy przeczytali dekadę raportów bezpieczeństwa.

No i jest wiek. Odczytuje się go jako obciążenie; ja odczytuję go jako argument ekosystemowy. Django REST Framework istnieje i jest nudny dokładnie w tym sensie, w jakim chcesz, żeby infrastruktura była nudna.

Tak samo jest z dojrzałymi pakietami do problemów, na które trafiasz w czwartym miesiącu: filtrowanie, throttling, backendy magazynowe, wzorce wielodostępności, ślady audytowe. A gdy problem jest na tyle nietypowy, że żaden pakiet go nie pokrywa, zwykle istnieje o nim piętnastoletni wątek na liście mailingowej. Pod względem zasięgu nie sądzę, by cokolwiek innego w Pythonie się do tego zbliżało, i to właśnie ta oś sprawia, że ktokolwiek w ogóle wybiera Django.

Gdzie Django zawodzi

Django wciąż brakuje kompletnego, własnego typowania w całym frameworku, ostrożne tempo zostawia luki, przed którymi „wszystko w komplecie” nie ostrzega, a framework Tasks z 6.0 nie ma workera. To trzy niedostatki wersji 6.1. Luka w typowaniu to ta, która denerwuje codziennie; Tasks to ta, która zmienia twój diagram architektury.

Większość historii z typowaniem wciąż składasz z narzędzi zewnętrznych. django-stubs dostarcza stuby typów oraz własną wtyczkę do mypy, radzącą sobie z dynamicznym zachowaniem Django. Jego bieżąca dokumentacja wymienia pełne wsparcie mypy oraz podstawowe wsparcie dla pyright, pyrefly i ty. To lepsza sytuacja niż kiedyś, ale nadal jest to osobna warstwa zgodności, a nie kompletne własne typowanie w samym Django.

Jeśli przychodzisz z frameworka zbudowanego wokół adnotacji typów, to wymierny regres w codziennej pracy w edytorze.

Ostrożne tempo jest kosztem tak samo jak zaletą. Django dodaje rzeczy uważnie i późno, dlatego framework, którego uczyłeś się w 2019, jest tym, który umiesz czytać dziś. Dlatego też baterie kończą się tam, gdzie się kończą: brak warstwy WebSocket w rdzeniu, brak harmonogramu, brak zdania na temat orkiestracji zadań asynchronicznych. Przekrocz jedną z tych granic, a znów składasz wszystko sam.

Czy Django 6 nadal potrzebuje Celery?

Niekoniecznie Celery. Framework Tasks w Django 6.0 standaryzuje, jak zadanie się definiuje i kolejkuje, ale sam nie wykonuje zakolejkowanej pracy. Na produkcji nadal potrzebujesz backendu albo procesu workera, który wykonuje zadania; Celery to jedna z opcji, a nie wymóg frameworka. Notatki wydania Django 6.0 są bezceremonialne co do tej granicy: Django zajmuje się tworzeniem zadań i ich kolejkowaniem, ale nie dostarcza mechanizmu workera, a wykonaniem musi zarządzać zewnętrzna infrastruktura, na przykład osobny proces lub usługa.

To, co dostajesz, to interfejs:

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(...) wysyła zadanie do skonfigurowanego backendu. Dwa backendy dostarczane z 6.0 są przeznaczone do developmentu i testów (a więc nie ten, na który liczyłeś). Harmonogramowanie, cykliczność, ponawianie i trwałość są poza zakresem.

Kevin Renskers, praktykujący programista Django, ujął to najostrzej w swojej recenzji Tasks:

Zamiast tego dostaliśmy abstrakcję bez implementacji.

Co do kształtu ma rację. Intencję ująłbym jednak inaczej. W głosowaniu Steering Council nad DEP 14, propozycji ulepszenia Django stojącej za tą funkcją, Simon Charette argumentował, że „powinno to być coś, do czego podpinają się frameworki takie jak Celery i RQ”, a autor propozycji opisał to jako interfejs dla workerów działających w tle, a nie środowisko uruchomieniowe. Uczciwa krytyka nie brzmi więc, że Tasks jest zepsute. Brzmi ona, że jest znacznie węższe, niż kazało się spodziewać „wszystko w komplecie”, a luka, którą zamyka, jest tą nudną: kod twojej aplikacji może kolejkować pracę bez importowania konkretnej biblioteki kolejek.

Zaplanuj więc kolejkę zadań w każdym projekcie na Django 6.1, który potrzebuje ponawiania, pracy według harmonogramu albo wglądu w awarie. To ta sama pozycja co przed 6.0, a jeśli liczyłeś, że to wydanie usunie ją z twojego diagramu architektury, to nie usuwa.

Jeśli już zdecydowałeś, że Django pasuje, i wolisz nie składać warstwy serwerowej od zera, Django VPS od Cloudzy daje ci samodzielnie zarządzany punkt startowy z Django, Gunicornem, Nginxem i PostgreSQL-em oraz dostęp roota, gdy potrzebujesz Redisa albo Celery. Serwer nadal jest twój do prowadzenia: pomijasz konfigurację od pustej maszyny, a nie odpowiedzialność operacyjną.

CZYTAJ

Jak zainstalować Pythona na serwerze VPS? | przewodnik krok po kroku

Czy wsparcie asynchroniczne w Django jest już wystarczające?

Wystarczająco dobre, by „to tylko synchroniczne” przestało cię powstrzymywać, i niewystarczająco dobre, by zbudować na tym w pełni asynchroniczną warstwę danych. W wersji 6.1 obie połowy są prawdziwe. To, która dotyczy ciebie, zależy od tego, co budujesz, i od tego, czy serwujesz to pod ASGI czy WSGI, bo właśnie ten wybór decyduje, czy dostaniesz w pełni asynchroniczny stos żądań i wydajną obsługę długo żyjących połączeń.

Strona możliwości nie jest sporna. Każda metoda QuerySet wyzwalająca SQL ma asynchroniczny odpowiednik z przedrostkiem a. Konstrukcja async for działa na QuerySetach, a asynchroniczne API bazy danych obejmują metody modelu takie jak asave() oraz metody QuerySet takie jak acreate(). Możesz napisać asynchroniczny widok, który awaituje zapytania i równoległe wychodzące wywołania HTTP bez opakowania na pulę wątków. W porównaniu z tym Django, o którym pisano krytykę „tylko synchroniczny”, to inny framework.

O zachowaniu decyduje protokół wdrożenia, a nie wersja frameworka, i to właśnie ten fragment forum Django musi tłumaczyć raz za razem. Przewodnik tematyczny o asynchroniczności stwierdza, że pod serwerem WSGI asynchroniczne widoki działają we własnej, jednorazowej pętli zdarzeń, więc funkcji asynchronicznych możesz używać, ale „nie otrzymasz korzyści asynchronicznego stosu”.

Obsługa setek połączeń bez wątków Pythona, powolny streaming, long-polling: to wszystko wymaga ASGI. Ten sam kod, inne zachowanie współbieżności, a nic we frameworku nie mówi ci, które z nich właśnie dostajesz.

Ta dezorientacja ma długie życie. Użytkownik podpisujący się tomcypress założył wątek na forum Django z pytaniem, dlaczego kolejne żądania do asynchronicznego widoku nie wykonują wszystkie swojej pracy w tle, a bywalec forum KenWhitesell wskazał mu pętlę zdarzeń WSGI. Ta wymiana pochodzi z 2021 roku i nic się w niej nie zmieniło w wersji 6.1.

Co więcej, jest wzmacniana z zewnątrz. Strona o zaletach i wadach Django w TechVidvan mówi czytelnikom, że Django „nie potrafi obsługiwać wielu żądań jednocześnie”, co jest nieprawdą w odniesieniu do Django 6.1 i jest typem twierdzenia, które kończy ocenę, zanim się zacznie. Współbieżność nie jest czymś, czego frameworkowi brakuje; jest czymś, o czym decyduje wdrożenie.

Twardą barierą są transakcje, a własna dokumentacja asynchroniczna Django mówi to wprost:

Transakcje jeszcze nie działają w trybie asynchronicznym. Jeśli masz fragment kodu, który wymaga zachowania transakcyjnego, zalecamy napisanie go jako pojedynczej funkcji synchronicznej i wywoływanie jej przy użyciu sync_to_async().

Ta sama strona klasyfikuje pewne kluczowe części frameworka jako „niebezpieczne dla async” i blokuje ich uruchamianie w kontekście asynchronicznym, zgłaszając SynchronousOnlyOperation , jeśli spróbujesz. Kształt asynchronicznej aplikacji w Django 6.1 wygląda więc tak: asynchroniczne widoki i asynchroniczne odczyty z synchronicznymi wysepkami wszędzie tam, gdzie zapisy potrzebują atomowości. Da się z tym pracować, ale to nie to samo co framework asynchroniczny z natury. Moja ocena na tej osi: wyraźnie lepiej, niedokończone i wyraźne zaliczenie dla wszystkiego, co nie stawia współbieżności na pierwszym miejscu.

Czy FastAPI sprawiło, że Django jest złym domyślnym wyborem?

Dla konkretnej i rosnącej klasy projektów tak. Ankieta deweloperów Pythona 2024 od JetBrains i Python Software Foundation, zebrana w październiku i listopadzie 2024 wśród ponad 30 000 uczestników, dała FastAPI 38%, Django 35% i Flaskowi 34% wśród wszystkich respondentów. Wśród respondentów, którzy jako główne zastosowanie Pythona wskazali web development, Django miało 61%, FastAPI 56%, a Flask 39%.

Przyjrzyj się temu pytaniu uważnie, zanim zaniesiesz je na spotkanie planistyczne, bo jest wielokrotnego wyboru. Respondentów pytano, których frameworków używają, a nie który wybrali, i programista utrzymujący monolit w Django, a jednocześnie piszący usługi we FastAPI, liczy się w obu. To nie są rozłączne udziały w rynku i nikt nie ma tu 38% rynku. Pokazują one rozdwojony sygnał: wśród wszystkich respondentów FastAPI prowadziło nad Django, natomiast wśród respondentów używających Pythona głównie do web developmentu Django wciąż prowadziło nad FastAPI.

Ankieta poświęcona samemu Django dokłada kolejny sygnał, od ludzi, którzy już z tego frameworka korzystają. Ankieta deweloperów Django 2025, przeprowadzona przez Django Software Foundation wspólnie z JetBrains na 4655 przefiltrowanych odpowiedziach zebranych między listopadem 2024 a styczniem 2025, wykazała 82% piszących w Django zawodowo, 77% wskazujących je jako najczęściej używany framework i 48% aktualizujących przy każdym stabilnym wydaniu, wobec 40% rok wcześniej. Respondenci zgłaszali się sami, więc opisuje to bieżącą bazę użytkowników, a nie rynek. Szerokość użycia i głębokość zaangażowania to różne sygnały, a druga liczba Django jest zdrowsza niż pierwsza.

Miejsca, w których FastAPI wygrywa, są węższe i ostrzejsze, niż sugeruje rozrzut w ankiecie. Powierzchnia API sterowana typami, gdzie twoje modele Pydantic są warstwą walidacji, a wygenerowany schemat OpenAPI kontraktem, bije Django plus warstwę serializerów. FastAPI jest asynchroniczne z natury na warstwie żądania, ale jego własna dokumentacja mówi wprost : operacje ścieżek można pisać na oba sposoby, a handler lub zależność zadeklarowane zwykłym def działają w zewnętrznej puli wątków.

A usługa bez panelu administracyjnego, bez formularzy i bez szablonów wlecze baterie Django jako martwy balast: płacisz za opinie frameworka i używasz jednej czwartej z nich. Jeśli budujesz właśnie to, ten rozpęd nie jest szumem i warto za nim pójść.

Kto powinien wybrać Django?

Sięgnij po Django w wersji 6.1, gdy panel administracyjny, uwierzytelnianie, formularze i ORM stanowią większość pracy, którą masz przed sobą: narzędzia wewnętrzne, marketplace'y, back-office'owe SaaS-y. Jest też właściwy dla małego zespołu, który potrzebuje tego wszystkiego działającego od pierwszego dnia, i dla zespołu, który musi już teraz wiedzieć, jak jego okno wsparcia będzie wyglądać w 2029 roku.

Produkty, w których opinie frameworka pokrywają większość rzeczywistej pracy. Wszystko, co ma macierz uprawnień i dużo CRUD-a za logowaniem. Tutaj to, że framework podejmuje decyzje strukturalne, jest zaletą, a nie kosztem, bo te decyzje to większość tego, co i tak byś budował.

Małe zespoły, które muszą być produktywne od pierwszego dnia. Przy trzech programistach i bez inżyniera platformy jeden zespół zaczyna pisać funkcje, a drugi zaczyna oceniać biblioteki uwierzytelniania. Od tego momentu ta różnica narasta.

Zespoły już pracujące na Django, które planują kolejne trzy lata. Django 5.2 daje ci wspieraną podłogę do kwietnia 2028, a roczna kadencja daje przewidywalną po niej. Czytelny horyzont wsparcia jest wart pieniędzy na etapie planowania, a rzadko podaje się go tak wyraźnie.

Kto nie powinien wybierać Django?

Nie wybieraj Django do API o wysokiej przepustowości albo strumieniowego, za którym nie stoi żaden panel administracyjny: dla takiego kształtu projektu czystszym domyślnym wyborem jest FastAPI. Nie wybieraj go, jeśli w tym roku potrzebujesz asynchronicznego dostępu do danych wraz z transakcjami, bo 6.1 tego nie ma. I nie wybieraj go w nadziei, że baterie uruchomią twoje zadania w tle.

Pojedyncze API o wysokiej przepustowości lub strumieniowe, bez panelu administracyjnego i bez formularzy. Prawie nic z tego, w czym Django jest dobre, nie jest nośne w tym kształcie projektu, więc utrzymywałbyś strukturę całego frameworka dla usługi, której potrzebny był router i walidator.

Zespoły, które już dziś potrzebują w pełni asynchronicznego dostępu do danych, wraz z transakcjami. Django 6.1 nie obsługuje transakcji w trybie asynchronicznym. Opakowywanie zapisów w sync_to_async() to prawomocny wzorzec, a nie obejście, z którego wyrośniesz w tym roku, a tam, gdzie jest to nie do przyjęcia, jest to blokada, a nie zadrapanie.

Zespoły, które czytają „wszystko w komplecie” jako obejmujące wykonywanie zadań w tle. Tasks nie dostarcza workera. Jeśli twój plan zakładał, że 6.0 usunęła kolejkę ze stosu, plan musi z powrotem zawierać kolejkę, zanim zwiążesz się z tym frameworkiem.

To, którego frameworka webowego uczyć się najpierw, jest osobnym pytaniem z osobną odpowiedzią; krótką wersję znajdziesz w FAQ poniżej.

To właśnie wiedza o tym, gdzie Django się kończy, sprawia, że można bezpiecznie zacząć: wyjścia opisane wyżej widać, zanim się zwiążesz, a nie odkrywa się je potem.

Często zadawane pytania

Czy Django jest martwe?

Nie. Django wydało dwie wersje funkcjonalne między grudniem 2025 a sierpniem 2026 i opublikowało przebudowany plan wydań sięgający lat trzydziestych. FastAPI rosło szybko i prowadziło nad Django 38% do 35% wśród wszystkich respondentów Ankiety deweloperów Pythona 2024, podczas gdy Django prowadziło 61% do 56% wśród respondentów używających Pythona głównie do web developmentu. Szybki wzrost nowszego frameworka i śmierć starszego to różne twierdzenia.

Czy Django jest dobre dla początkujących?

Tak, z zastrzeżeniem, że jest to najwięcej materiału do przyswojenia naraz. Produktywność Django bierze się z jego rozpiętości, a to znaczy, że początkujący natyka się na ORM, migracje, warstwę szablonów i panel administracyjny, zanim cokolwiek wypuści. Warto przeczytać argument z drugiej strony: wpis na Bite Code! przekonuje, że początkujący powinni zaczynać właśnie od Django, bo jego ustawienia domyślne zapobiegają błędom architektonicznym, które minimalny framework zostawia tobie samemu do popełnienia.

Czy Django jest szybsze niż Flask?

Nie ma uniwersalnej odpowiedzi. Na potrzeby tej recenzji nie uruchamiano żadnego benchmarku i nie ufałbym żadnemu bez znajomości jego obciążenia i wdrożenia. W wielu aplikacjach zapytania do bazy, problemy N+1 i wywołania zewnętrznych API ważą więcej niż narzut frameworka. Jeśli surowa przepustowość żądań ma znaczenie dla decyzji, zmierz tę aplikację i tę konfigurację serwera, którą naprawdę zamierzasz uruchomić.

Od której wersji Django zacząć nowy projekt?

Zacznij od 5.2, jeśli najbardziej liczy się najdłuższe okno wsparcia: to obecne LTS, wspierane do kwietnia 2028. Zacznij od 6.1, jeśli chcesz framework Tasks i najnowsze funkcje gałęzi 6.x, godząc się na wsparcie główne mniej więcej do kwietnia 2027 i rozszerzone do grudnia 2027, a potem zaplanuj aktualizację do Django 6.2 LTS, gdy pojawi się w kwietniu 2027. Dla Django 6.2 zaplanowano wsparcie rozszerzone do kwietnia 2030. Od stycznia 2028 każde roczne wydanie funkcjonalne niesie trzy lata wsparcia.

Czego uczyć się najpierw: Django czy FastAPI?

Ucz się tego, który pasuje do pracy, jaką chcesz wykonywać. Django uczy cię, jak składa się cała aplikacja webowa: modelowanie danych, migracje, uwierzytelnianie, formularze, szablony i panel administracyjny, przy czym struktura jest już za ciebie ustalona. FastAPI uczy cię projektowania typowanych API i asynchronicznego Pythona, przy czym za ciebie nie ustalono prawie niczego. W oderwaniu od kontekstu żaden z nich nie jest opcją przyjazną początkującym, a wybranie tego bliższego pracy, o którą ci chodzi, bije wybieranie łatwiejszego.