Recenze Djanga: stojí ještě za to?

Django během osmi měsíců mezi prosincem 2025 a srpnem 2026 vydalo dvě funkční verze a celý svůj režim vydávání přepsalo.

To vše potkalo framework, jehož pověst se od roku 2023 skoro nezměnila: pythonovský framework se vším všudy, produktivní, názorový, jen synchronní a ztrácející půdu ve prospěch FastAPI. Nálepka „jen synchronní“ je zastaralá a příběh popularity je složitější, než napovídají čísla z titulků.

Tady je tedy můj závěr k otázce, jestli Django ve verzi 6.1 ještě stojí za to: verdikt s hodnocením, typy projektů, kterým sedí, a ty, pro které je dnes lepší volbou FastAPI.

Zkrácená verze

Ano, s podmínkami. Django 6.1 zůstává nejsilnější výchozí volbou, když admin, autentizace, formuláře a ORM tvoří většinu práce, a odstup v asynchronním provozu se zmenšil natolik, že „jen synchronní“ už není důvod ho vyřadit. Pro jediné API s vysokou souběžností a bez administrace je špatnou volbou. 4 z 5.

• Kupujete si ten balík jako celek. ORM, migrace, session autentizace s oprávněními, formulářová vrstva a vygenerovaná administrace přicházejí pohromadě a už provázané, ne jako pět knihoven plus spoje mezi nimi.
• Slabinou jsou úlohy na pozadí. Framework Tasks v Djangu 6.0 vám dá dekorátor a volání pro zařazení do fronty, ale žádného workera, takže Celery nebo něco rovnocenného zůstává rozhodnutím na vás.
• Asynchronní podpora je mnohem lepší a zjevně nedodělaná. Django podporuje asynchronní pohledy i asynchronní volání ORM, ale transakce v asynchronním režimu nefungují. Pod WSGI mohou asynchronní pohledy stále provádět souběžné asynchronní I/O v rámci jednoho požadavku, ale výhody plně asynchronního zásobníku požadavků nezískáte; dlouhoběžící požadavky a vysoká souběžnost spojení vyžadují ASGI.
• Plánovat za rok 2027 je snazší. Od ledna 2028 vydává Django jednu funkční verzi ročně, každou s tříletou podporou, a nálepka „LTS“ mizí, protože tento závazek teď dostává každé vydání.
• Vhodné pro produkty s velkou administrací a spoustou CRUD a pro malé týmy. Špatné pro jediné API s vysokou propustností nebo streamováním, bez administrace či formulářů, kde je přirozenější volbou FastAPI.

Jak jsem tuhle recenzi sestavil: Toto je hodnocení Djanga 6.1 postavené na poznámkách k vydání a dokumentaci samotného projektu, na oznámení Django Software Foundation o správě projektu ze srpna 2026, na vývojářských průzkumech JetBrains/PSF 2024 a Django 2025 a na jmenovitě uvedených praktikcích, kteří veřejně píší o vlastní zkušenosti z produkce. Několikatýdenní nasazení v produkci jsem pro tento text nedělal a nejsou tu žádné benchmarky: nic se netestovalo pod zátěží. Django je zdarma a pod licencí BSD a s projektem mě nic nespojuje.

Co se v Djangu od roku 2025 skutečně změnilo?

Django 6.0 vyšlo 3. prosince 2025 s vlastním frameworkem Tasks a dalšími přírůstky v jádře. Asynchronní rozhraní ORM je starší: Django 4.1 přineslo asynchronní operace QuerySet už v roce 2022. Django 6.1 se stalo aktuální stabilní verzí 5. srpna 2026. Poté, 10. srpna 2026, projekt oznámil jedno funkční vydání ročně od ledna 2028, tři roky podpory pro každé vydání a konec nálepky LTS.

Poznámky k vydání 6.1 potvrzují, že 6.1 podporuje Python 3.12, 3.13 a 3.14, přičemž hlavní podpora končí v dubnu 2027 a rozšířená v prosinci 2027.

Spolu s tím se mění i čísla verzí. Nesou rok: Django 2028, pak Django 2029 (aspoň otázka „na jaké jste verzi“ se bude odpovídat snáz). Tři roky se dělí na rok běžných oprav chyb a pak dva roky oprav bezpečnosti a ztráty dat, což je přesně to, co dřív znamenalo LTS, a proto nálepka mizí.

Pro projekt, který začíná dnes, tím vzniká nepohodlné okno. Django 5.2 je současné LTS a je podporované do dubna 2028. Django 6.1 je aktuální stabilní verze, ale jeho rozšířená podpora končí v prosinci 2027, zhruba čtyři měsíce před tím, než v dubnu 2028 skončí okno podpory Djanga 5.2.

Takže: hnát se za nejdelším oknem podpory znamená začít na 5.2. Chtít framework Tasks a nejnovější funkce řady 6.x znamená začít na 6.1 a smířit se s dřívějším upgradem. Ani jedno není špatně a ta nepříjemná volba zmizí, až v dubnu 2027 přijde Django 6.2 LTS.

Změnu kadence čtu jako dobré znamení. Upadající projekty své sliby o podpoře potichu natahují; nepředělávají je veřejně s datovaným plánem. Tenhle zjednodušil závazek, který už tak dodržoval.

Co Django pořád zvládá lépe než cokoli jiného

Založte projekt v Djangu 6.1 a máte funkční session autentizaci se systémem oprávnění, formulářovou vrstvu, která validuje i vykresluje, migrační systém svázaný s vašimi modely, ORM a vygenerovanou administraci, ještě než napíšete jedinou funkci. To je celá nabídka a je to ta část Djanga, která se měnit nepotřebovala.

Hodnota není v tom, že ty díly existují. Je v tom, že byly navrženy vůči sobě navzájem. Táž oprávnění na modelech živí administraci a změna modelu jedním pohybem vygeneruje migraci i aktualizuje formulář v administraci.

Poskládat rovnocenné pokrytí z nezávislých knihoven se nakonec podaří. Zároveň si tím pořídíte trvalou údržbovou plochu na každém spoji, a chyby bydlí právě ve spojích.

Administrace je nástroj pro zaměstnance. Referenční dokumentace administrace říká, že doporučené použití je omezené na interní nástroj správy dané organizace a že není určena k tomu, aby se kolem ní stavěl celý váš frontend. Oprávnění na modelech řídí, co smějí zaměstnanci uvnitř dělat, a k tomu, aby se dovnitř vůbec dostali, je potřeba is_staff. Berte to jako omezení, a je to omezení dobré: zdarma dostanete schopný interní back office a nedostanete rozhraní pro zákazníky, takže nikoho neláká ho nasadit.

Výchozí bezpečnostní nastavení jsou druhá polovina téhož argumentu. Ochrana proti CSRF, parametrizace SQL přes ORM, escapování XSS v šablonách a ochrana proti clickjackingu jsou zapnuté ve výchozím stavu, místo aby šlo o věci, na které si zkušený vývojář musí vzpomenout při code review. Malý tým dědí rozhodnutí lidí, kteří přečetli deset let bezpečnostních hlášení.

Pak je tu věk. Čte se jako zátěž; já ho čtu jako argument ekosystému. Django REST Framework existuje a je nudný přesně tak, jak si přejete, aby infrastruktura byla nudná.

Totéž platí pro vyzrálé balíčky na problémy, na které narazíte ve čtvrtém měsíci: filtrování, throttling, úložná backendová řešení, vzory multi-tenancy, auditní stopy. A když je problém dost neobvyklý na to, aby ho žádný balíček nepokrýval, obvykle o něm existuje patnáct let staré vlákno v mailing listu. Co do šířky si nemyslím, že by se v Pythonu něco jiného blížilo, a právě tahle osa je důvod, proč si Django vůbec někdo vybere.

Kde Django zaostává

Djangu pořád chybí komplexní vlastní typování napříč frameworkem, opatrné tempo nechává mezery, na které vás „vše v ceně“ neupozorní, a frameworku Tasks z 6.0 chybí worker. To jsou tři nedostatky verze 6.1. Mezera v typování je ta, která vás štve denně; Tasks je ta, která vám mění schéma architektury.

Většinu typování si tak pořád skládáte z nástrojů třetích stran. django-stubs poskytuje typové stuby a vlastní plugin pro mypy, který si poradí s dynamickým chováním Djanga. Jeho současná dokumentace uvádí plnou podporu mypy a základní podporu pro pyright, pyrefly a ty. Je to lepší stav než dřív, ale pořád jde o oddělenou kompatibilní vrstvu, ne o komplexní vlastní typování přímo v Djangu.

Když přicházíte z frameworku postaveného kolem typových anotací, je to měřitelný krok zpět v každodenní práci v editoru.

Opatrné tempo je stejně tak náklad jako přednost. Django přidává věci pečlivě a pozdě, a právě proto je framework, který jste se učili v roce 2019, ten, který dnes umíte číst. Proto také baterie končí tam, kde končí: v jádře žádná vrstva WebSocketů, žádný plánovač, žádný názor na orchestraci asynchronních úloh. Překročte jednu z těch čar a zase si vše skládáte sami.

Potřebuje Django 6 ještě Celery?

Ne přímo Celery. Framework Tasks v Djangu 6.0 sjednocuje, jak se úloha definuje a zařazuje do fronty, ale zařazenou práci sám nespouští. V produkci pořád potřebujete backend nebo worker proces, který úlohy vykonává; Celery je jedna z možností, ne požadavek frameworku. Poznámky k vydání Djanga 6.0 jsou k té hranici otevřené: Django zajišťuje vytvoření úlohy a její zařazení do fronty, ale neposkytuje mechanismus workera, a vykonávání musí řídit externí infrastruktura, například samostatný proces nebo služba.

Co dostanete, je rozhraní:

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(...) pošle úlohu do nakonfigurovaného backendu. Dva backendy, které přicházejí s 6.0, jsou určené pro vývoj a testování (tedy ne ten, v který jste doufali). Plánování, opakování, retry a trvanlivost jsou všechny mimo rozsah.

Kevin Renskers, praktikující vývojář v Djangu, to vyjádřil nejostřeji ve své recenzi Tasks:

Místo toho jsme dostali abstrakci bez implementace.

Co do tvaru má pravdu. Záměr bych ale rámoval jinak. Ve hlasování Steering Council o DEP 14 návrhu na vylepšení Djanga, který za touto funkcí stojí, Simon Charette argumentoval, že „by to mělo být něco, do čeho se zapojí frameworky jako Celery a RQ“, a autor návrhu jej popsal jako rozhraní pro workery na pozadí, ne jako běhové prostředí. Spravedlivá kritika tedy nezní, že je Tasks rozbité. Zní, že je mnohem užší, než co lidé podle „vše v ceně“ čekali, a že mezera, kterou zavírá, je ta nudná: kód vaší aplikace může zařadit práci do fronty, aniž by importoval konkrétní frontovou knihovnu.

Počítejte tedy s frontou úloh v každém projektu na Djangu 6.1, který potřebuje opakování, plánovanou práci nebo přehled o selháních. Je to tatáž položka jako před 6.0, a pokud jste doufali, že ji tohle vydání z vašeho schématu architektury vymaže, nevymaže.

Pokud jste už rozhodli, že Django sedí, a nechcete skládat serverovou vrstvu od nuly, Django VPS od Cloudzy vám dá samosprávný výchozí bod s Djangem, Gunicornem, Nginxem a PostgreSQL, plus root přístup, když potřebujete Redis nebo Celery. Server je pořád váš k provozování: přeskakujete rozjezd z prázdné mašiny, ne provozní odpovědnost.

ČTĚTE

Jak nainstalovat Python na VPS server? | Návod krok za krokem

Je už asynchronní podpora v Djangu dost dobrá?

Dost dobrá na to, aby vás „je jen synchronní“ už nezastavilo, a nedost dobrá na to, abyste na ní postavili plně asynchronní datovou vrstvu. Ve verzi 6.1 platí obě poloviny. Která se týká vás, závisí na tom, co stavíte, a na tom, jestli to servírujete pod ASGI, nebo WSGI, protože právě tahle volba rozhoduje, jestli dostanete plně asynchronní zásobník požadavků a efektivní obsluhu dlouhoživých spojení.

Stránka schopností není sporná. Každá metoda QuerySet která spouští SQL, má asynchronní variantu s předponou a. Konstrukce async for funguje napříč QuerySety a asynchronní databázová API zahrnují metody modelů jako asave() a metody QuerySetu jako acreate(). Můžete napsat asynchronní pohled, který awaituje dotazy i souběžná odchozí HTTP volání bez obalu nad threadpoolem. Ve srovnání s Djangem, o kterém byla kritika „jen synchronní“ napsána, je to jiný framework.

O chování rozhoduje protokol nasazení, ne verze frameworku, a je to přesně ta část, kterou musí vlastní fórum Djanga vysvětlovat pořád dokola. Tematický průvodce asynchronním provozem uvádí, že pod WSGI serverem běží asynchronní pohledy ve vlastní jednorázové smyčce událostí, takže asynchronní funkce použít můžete, ale „výhody asynchronního zásobníku nezískáte“.

Obsloužit stovky spojení bez pythonovských vláken, pomalý streaming, long-polling: to všechno vyžaduje ASGI. Stejný kód, jiné chování v souběžnosti, a nic ve frameworku vám neřekne, které z nich právě dostáváte.

Ten zmatek má dlouhý život. Uživatel vystupující jako tomcypress založil vlákno na fóru Djanga s dotazem, proč po sobě jdoucí požadavky na asynchronní pohled nespouštějí všechny svou práci na pozadí, a stálice fóra KenWhitesell ho odkázal na smyčku událostí WSGI. Ta výměna je z roku 2021 a ve verzi 6.1 se na ní nic nezměnilo.

A navíc ho posilují zvenčí. Stránka o výhodách a nevýhodách Djanga na TechVidvanu čtenářům tvrdí, že Django „není schopné obsloužit více požadavků najednou“, což o Djangu 6.1 neplatí a je to přesně ten typ tvrzení, který ukončí hodnocení dřív, než začne. Souběžnost není něco, co frameworku chybí; je to něco, o čem rozhoduje nasazení.

Tvrdou zarážkou jsou transakce a vlastní asynchronní dokumentace Djanga to říká na rovinu:

Transakce v asynchronním režimu zatím nefungují. Pokud máte kus kódu, který potřebuje transakční chování, doporučujeme napsat ho jako jedinou synchronní funkci a volat ji pomocí sync_to_async().

Táž stránka označuje některé klíčové části frameworku za „nebezpečné pro async“ a brání jim běžet v asynchronním kontextu; vyhodí přitom SynchronousOnlyOperation , když to zkusíte. Tvar asynchronní aplikace v Djangu 6.1 je tedy: asynchronní pohledy a asynchronní čtení se synchronními ostrůvky všude tam, kde zápisy potřebují atomicitu. Použitelné, a přitom to není totéž co framework asynchronní od základu. Můj závěr na této ose: znatelně lepší, nedokončené, a jasné projití pro cokoli, co nestaví souběžnost na první místo.

Udělal FastAPI z Djanga špatnou výchozí volbu?

Pro určitou a rostoucí třídu projektů ano. Průzkum vývojářů v Pythonu 2024 od JetBrains a Python Software Foundation, sbíraný v říjnu a listopadu 2024 s více než 30 000 účastníky, dal FastAPI 38 %, Djangu 35 % a Flasku 34 % napříč všemi respondenty. Mezi respondenty, kteří jako hlavní využití Pythonu zvolili webový vývoj, mělo Django 61 %, FastAPI 56 % a Flask 39 %.

Podívejte se na tu otázku pořádně, než ji ponesete na plánovací schůzku, protože jde o vícenásobný výběr. Respondentů se ptali, které frameworky používají, ne který si vybrali, a vývojář, který udržuje monolit v Djangu a přitom píše služby ve FastAPI, se počítá do obou. Nejsou to výhradní tržní podíly a nikdo tu nemá 38 % trhu. Ukazují rozdvojený signál: napříč všemi respondenty vedl FastAPI před Djangem, zatímco mezi respondenty, kteří Python používají hlavně na webový vývoj, vedlo Django před FastAPI.

Průzkum zaměřený přímo na Django přidává další signál, a to od lidí, kteří framework už používají. Průzkum vývojářů v Djangu 2025, který provedla Django Software Foundation s JetBrains na 4 655 filtrovaných odpovědích sesbíraných mezi listopadem 2024 a lednem 2025, zjistil, že 82 % píše v Djangu profesionálně, 77 % ho označuje za svůj nejpoužívanější framework a 48 % aktualizuje s každým stabilním vydáním, oproti 40 % o rok dříve. Respondenti se přihlásili sami, takže to popisuje současnou uživatelskou základnu, ne trh. Šířka používání a hloubka závazku jsou různé signály a druhé číslo Djanga je zdravější než první.

Místa, kde FastAPI vítězí, jsou užší a ostřejší, než napovídá rozestup v průzkumu. Typy řízená API plocha, kde vaše modely Pydantic tvoří validační vrstvu a vygenerované schéma OpenAPI je smlouva, poráží Django plus vrstvu serializerů. FastAPI je na úrovni požadavku asynchronní od základu, ale jeho vlastní dokumentace je explicitní : operace cest lze psát oběma způsoby a handler nebo závislost deklarované prostým def běží ve vnějším threadpoolu.

A služba bez administrace, bez formulářů a bez šablon táhne baterie Djanga jako mrtvou váhu: platíte za názory frameworku a používáte z nich čtvrtinu. Pokud stavíte právě tohle, ten rozjezd není hype a měli byste ho následovat.

Kdo by si měl vybrat Django?

Po Djangu ve verzi 6.1 sáhněte, když administrace, autentizace, formuláře a ORM tvoří většinu práce, která vás čeká: interní nástroje, tržiště, back-office SaaS. Je také správnou volbou pro malý tým, který tyhle věci potřebuje funkční už první den, a pro tým, který potřebuje už teď vědět, jak bude jeho okno podpory vypadat v roce 2029.

Produkty, u nichž názory frameworku pokryjí většinu skutečné práce. Cokoli s maticí oprávnění a spoustou CRUD za přihlášením. Tady je to, že strukturální volby dělá framework, přednost, ne náklad, protože právě tyhle volby by tvořily většinu toho, co byste stejně stavěli.

Malé týmy, které musí být produktivní hned první den. Se třemi vývojáři a bez platformového inženýra jeden tým začne psát funkce, zatímco druhý začne vyhodnocovat autentizační knihovny. Od té chvíle se ten rozdíl nabaluje.

Týmy, které už na Djangu jedou a plánují další tři roky. Django 5.2 vám dává podporovanou podlahu až do dubna 2028 a roční kadence vám po ní dává předvídatelnou. Čitelná dráha podpory má při plánování cenu peněz a je nezvyklé dostat ji takhle jasně do ruky.

Kdo by si Django vybírat neměl?

Nevybírejte Django pro API s vysokou propustností nebo streamováním, za nímž není žádná administrace: pro tenhle tvar projektu je čistší výchozí volbou FastAPI. Nevybírejte ho, pokud letos potřebujete asynchronní přístup k datům včetně transakcí, protože 6.1 to nemá. A nevybírejte ho s očekáváním, že vám baterie budou spouštět úlohy na pozadí.

Jediné API s vysokou propustností nebo streamováním, bez administrace a bez formulářů. U tohohle tvaru projektu neunese téměř nic z toho, v čem je Django dobré, takže byste udržovali strukturu celého frameworku kvůli službě, které stačil směrovač a validátor.

Týmy, které dnes potřebují plně asynchronní přístup k datům včetně transakcí. Django 6.1 nepodporuje transakce v asynchronním režimu. Obalit zápisy do sync_to_async() je legitimní vzor, ne obezlička, ze které letos vyrostete, a tam, kde je to nepřijatelné, jde o zásadní překážku, ne o škrábnutí.

Týmy, které čtou „vše v ceně“ tak, že to pokrývá i spouštění úloh na pozadí. Tasks worker nepřináší. Pokud váš plán počítal s tím, že 6.0 odstranila frontu z vašeho stacku, musí se do plánu fronta vrátit dřív, než se k frameworku zavážete.

Který webový framework se učit jako první je jiná otázka s jinou odpovědí; krátkou verzi najdete v častých dotazech níže.

Právě vědomí toho, kde Django končí, dělá začátek s ním bezpečným: východy popsané výše jsou vidět dřív, než se zavážete, ne až potom.

Časté dotazy

Je Django mrtvé?

Ne. Django vydalo mezi prosincem 2025 a srpnem 2026 dvě funkční verze a zveřejnilo přestavěný plán vydání sahající do třicátých let. FastAPI rychle rostl a v průzkumu vývojářů v Pythonu 2024 vedl nad Djangem 38 % ku 35 % napříč všemi respondenty, zatímco mezi respondenty, kteří Python používají hlavně na webový vývoj, vedlo Django 61 % ku 56 %. Rychlý růst novějšího frameworku a smrt toho staršího jsou různá tvrzení.

Je Django dobré pro začátečníky?

Ano, s výhradou, že je toho najednou k naučení nejvíc. Produktivní dělá Django právě jeho šířka, a to znamená, že začátečník narazí na ORM, migrace, šablonovou vrstvu i administraci dřív, než cokoli vypustí. Opačný pohled stojí za přečtení: příspěvek na Bite Code! tvrdí, že začátečníci by měli začínat právě s Djangem, protože jeho výchozí nastavení předchází architektonickým chybám, které vás minimalistický framework nechá udělat o samotě.

Je Django rychlejší než Flask?

Univerzální odpověď neexistuje. Pro tuhle recenzi se žádný benchmark nespouštěl a žádnému bych nevěřil, aniž bych znal jeho zátěž a nasazení. V mnoha aplikacích váží databázové dotazy, N+1 a volání externích API víc než režie frameworku. Pokud je pro rozhodnutí důležitá surová propustnost požadavků, změřte tu aplikaci a tu serverovou konfiguraci, kterou skutečně plánujete provozovat.

Na které verzi Djanga začít nový projekt?

Začněte na 5.2, pokud vám nejvíc záleží na nejdelším okně podpory: je to současné LTS, podporované do dubna 2028. Začněte na 6.1, pokud chcete framework Tasks a nejnovější funkce řady 6.x, smiřte se s hlavní podporou zhruba do dubna 2027 a rozšířenou do prosince 2027 a naplánujte si upgrade na Django 6.2 LTS, až v dubnu 2027 vyjde. U Djanga 6.2 je rozšířená podpora naplánovaná do dubna 2030. Od ledna 2028 nese každé roční funkční vydání tři roky podpory.

Máte se nejdřív učit Django, nebo FastAPI?

Učte se ten, který odpovídá práci, kterou chcete dělat. Django vás naučí, jak do sebe zapadá celá webová aplikace: datové modelování, migrace, autentizace, formuláře, šablony a administrace, přičemž struktura je rozhodnutá za vás. FastAPI vás naučí navrhovat typovaná API a psát asynchronní Python, přičemž za vás není rozhodnuto téměř nic. V abstraktní rovině není přívětivější pro začátečníky ani jeden, a vybrat ten bližší práci, kterou chcete dělat, je lepší než vybrat ten snazší.