Recensione di Django: vale ancora la pena?

Django ha rilasciato due versioni di funzionalità e riscritto per intero la propria cadenza di rilascio negli otto mesi tra dicembre 2025 e agosto 2026.

Tutto questo è capitato a un framework la cui reputazione non si è mossa granché dal 2023: il framework Python completo di tutto, produttivo, con idee precise, solo sincrono e in perdita di terreno rispetto a FastAPI. L'etichetta "solo sincrono" è scaduta, e la storia della popolarità è più complicata di quanto suggeriscano i numeri dei titoli.

Ecco dunque dove mi colloco sulla domanda se Django valga ancora la pena alla 6.1: un verdetto con voto, le forme di progetto a cui si adatta e quelle per cui FastAPI è ormai la scelta migliore.

La versione breve

Sì, a condizioni. Django 6.1 resta la scelta predefinita più solida quando admin, autenticazione, form e ORM sono la maggior parte del lavoro, e il divario sull'asincrono si è ridotto abbastanza da far sì che "solo sincrono" non sia più un motivo per escluderlo. È sbagliato per una singola API ad alta concorrenza senza superficie di amministrazione. 4 su 5.

• Quello che compri è il pacchetto. L'ORM, le migrazioni, l'autenticazione di sessione con i permessi, uno strato per i form e un admin generato arrivano insieme e già integrati, non come cinque librerie più le giunture tra di esse.
• I job in background sono l'asse debole. Il framework Tasks di Django 6.0 ti dà un decoratore e una chiamata di accodamento, ma nessun worker, quindi Celery o un equivalente resta una decisione che prendi tu.
• L'asincrono è molto migliorato ed è chiaramente incompiuto. Django supporta le view asincrone e le chiamate asincrone all'ORM, ma le transazioni non funzionano in modalità asincrona. Sotto WSGI le view asincrone possono comunque eseguire I/O asincrono concorrente dentro una richiesta, però non si ottengono i vantaggi di uno stack di richieste interamente asincrono: le richieste di lunga durata e l'elevata concorrenza di connessioni richiedono ASGI.
• Pianificare oltre il 2027 è diventato più facile. Da gennaio 2028 Django pubblica una versione di funzionalità all'anno, ciascuna con tre anni di supporto, e l'etichetta "LTS" scompare perché ora ogni versione riceve quell'impegno.
• Giusto per prodotti con molta amministrazione e molto CRUD e per team piccoli. Sbagliato per una singola API ad alto throughput o di streaming, senza admin né form, dove FastAPI è la scelta più naturale.

Come ho costruito questa recensione: Questa è una valutazione di Django 6.1 costruita a partire dalle note di rilascio e dalla documentazione del progetto stesso, dall'annuncio sulla governance della Django Software Foundation dell'agosto 2026, dai sondaggi sugli sviluppatori JetBrains/PSF del 2024 e Django del 2025, e da professionisti citati per nome che scrivono pubblicamente della propria esperienza in produzione. Per questo pezzo non ho condotto una prova in produzione di più settimane, e qui non ci sono benchmark: nulla è stato testato sotto carico. Django è gratuito e con licenza BSD, e io non ho alcun rapporto con il progetto.

Che cosa è cambiato davvero in Django dal 2025?

Django 6.0 è arrivato il 3 dicembre 2025 con un framework Tasks nativo e altre aggiunte al nucleo. L'interfaccia ORM asincrona è più vecchia: Django 4.1 ha introdotto le operazioni asincrone su QuerySet nel 2022. Django 6.1 è diventato la versione stabile attuale il 5 agosto 2026. Poi, il 10 agosto 2026, il progetto ha annunciato una versione di funzionalità all'anno da gennaio 2028, tre anni di supporto per ogni versione e la fine dell'etichetta LTS.

Le note di rilascio della 6.1 confermano che la 6.1 supporta Python 3.12, 3.13 e 3.14, con il supporto principale che termina ad aprile 2027 e quello esteso a dicembre 2027.

I numeri di versione cambiano di conseguenza. Portano l'anno: Django 2028, poi Django 2029 (almeno "su che versione siete" diventa più facile da rispondere). I tre anni si suddividono in un anno di correzioni di bug ordinarie seguito da due di correzioni di sicurezza e perdita di dati, che è ciò che LTS significava, per cui l'etichetta scompare.

Questo lascia una finestra scomoda a un progetto che parte oggi. Django 5.2 è l'attuale LTS, supportata fino ad aprile 2028. Django 6.1 è l'attuale stabile, ma il suo supporto esteso finisce a dicembre 2027, circa quattro mesi prima che la finestra di supporto di Django 5.2 si chiuda ad aprile 2028.

Quindi: puntare alla finestra di supporto più lunga significa partire dalla 5.2. Volere il framework Tasks e le funzionalità più recenti della 6.x significa partire dalla 6.1 e accettare un aggiornamento più ravvicinato. Nessuna delle due è sbagliata, e la scelta scomoda sparisce quando Django 6.2 LTS arriverà ad aprile 2027.

Io leggo il cambio di cadenza come un buon segno. I progetti in declino allungano in silenzio le loro promesse di supporto; non le ristrutturano in pubblico con un piano datato. Questo ha semplificato un impegno che stava già mantenendo.

Ciò che Django fa ancora meglio di chiunque altro

Avvia un progetto Django 6.1 e hai già l'autenticazione di sessione funzionante con un sistema di permessi, uno strato per i form che valida e renderizza, un sistema di migrazioni legato ai tuoi modelli, l'ORM e un admin generato, prima ancora di scrivere una singola funzionalità. È tutta qui la proposta, ed è la parte di Django che non ha avuto bisogno di cambiare.

Il valore non sta nel fatto che quei pezzi esistano. Sta nel fatto che sono stati progettati l'uno rispetto all'altro. Gli stessi permessi sui modelli alimentano l'admin, e una modifica al modello genera la migrazione e aggiorna il form dell'admin nello stesso gesto.

Assemblare una copertura equivalente partendo da librerie indipendenti alla fine ti ci porta. Ti porta anche una superficie di manutenzione permanente a ogni giuntura, e le giunture sono il posto dove vivono i bug.

L'admin è uno strumento per il personale interno. La documentazione di riferimento dell'admin dice che il suo uso raccomandato si limita a strumento di gestione interna di un'organizzazione e che non è pensato per costruirci attorno tutto il front end. I permessi sui modelli controllano cosa possono fare gli utenti dello staff una volta dentro, e per entrarci serve is_staff. Consideralo un vincolo, ed è un buon vincolo: ottieni gratis un back office interno competente e non ottieni un'interfaccia rivolta ai clienti, così nessuno è tentato di pubblicarne una.

Le impostazioni di sicurezza predefinite sono l'altra metà dello stesso argomento. La protezione CSRF, la parametrizzazione SQL tramite l'ORM, l'escaping XSS nei template e la protezione dal clickjacking sono attive di default, invece di essere cose che uno sviluppatore esperto deve ricordarsi di chiedere in revisione. Un team piccolo eredita scelte fatte da persone che hanno letto un decennio di segnalazioni di sicurezza.

Poi c'è l'età. Viene letta come una zavorra; io la leggo come l'argomento dell'ecosistema. Django REST Framework esiste ed è noioso nel modo in cui vuoi che l'infrastruttura sia noiosa.

Lo stesso vale per i pacchetti maturi per i problemi che incontri al quarto mese: filtri, throttling, backend di storage, pattern multi-tenant, tracciati di audit. E quando un problema è abbastanza insolito da non essere coperto da nessun pacchetto, di solito esiste un thread di mailing list vecchio di quindici anni che ne parla. Sull'ampiezza non credo che nient'altro in Python ci si avvicini, ed è questo asse il motivo per cui si sceglie Django in partenza.

Dove Django resta indietro

A Django manca ancora una tipizzazione nativa completa su tutto il framework, il passo prudente lascia lacune di cui "tutto incluso" non ti avverte, e al framework Tasks della 6.0 manca il worker. Sono queste le tre carenze alla 6.1. La lacuna sulla tipizzazione è quella che ti infastidisce ogni giorno; Tasks è quella che ti cambia il diagramma di architettura.

Buona parte della storia sulla tipizzazione continui a montartela con strumenti di terze parti. django-stubs fornisce stub di tipo più un plugin mypy dedicato al comportamento dinamico di Django. La sua documentazione attuale indica supporto completo per mypy e supporto di base per pyright, pyrefly e ty. È una situazione migliore di un tempo, ma resta uno strato di compatibilità separato invece di una tipizzazione nativa completa dentro Django stesso.

Arrivando da un framework costruito attorno ai type hint, è una regressione misurabile nell'esperienza quotidiana nell'editor.

Il passo prudente è tanto un costo quanto una virtù. Django aggiunge le cose con cautela e in ritardo, ed è per questo che il framework che hai imparato nel 2019 è quello che sai leggere oggi. È anche per questo che le batterie finiscono dove finiscono: nessuno strato WebSocket nel nucleo, nessuno scheduler, nessuna opinione sull'orchestrazione dei task asincroni. Supera una di queste linee e torni ad assemblare tutto da solo.

Django 6 ha ancora bisogno di Celery?

Non Celery in particolare. Il framework Tasks di Django 6.0 standardizza il modo in cui un task viene definito e accodato, ma non esegue da sé il lavoro in coda. In produzione serve ancora un backend o un processo worker che esegua i task; Celery è un'opzione, non un requisito del framework. Le note di rilascio di Django 6.0 sono esplicite sul confine: Django si occupa della creazione e dell'accodamento dei task, ma non fornisce un meccanismo di worker, e l'esecuzione deve essere gestita da infrastruttura esterna, come un processo o un servizio separato.

Quello che ottieni è l'interfaccia:

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(...) invia il task a un backend configurato. I due backend che arrivano con la 6.0 sono pensati per sviluppo e test (quindi non quello che speravi). Pianificazione, ricorrenza, ritentativi e durabilità sono tutti fuori ambito.

Kevin Renskers, sviluppatore Django in attività, l'ha detto nel modo più netto nella sua recensione di Tasks:

Invece abbiamo ottenuto un'astrazione senza implementazione.

Sulla forma ha ragione. L'intento però lo inquadrerei diversamente. Nel voto dello Steering Council su DEP 14, la proposta di miglioramento di Django dietro la funzionalità, Simon Charette ha sostenuto che "dovrebbe essere qualcosa in cui framework come Celery e RQ si innestano", e l'autore della proposta l'ha descritta come un'interfaccia per worker in background piuttosto che come un runtime. Quindi la critica corretta non è che Tasks sia rotto. È che è molto più ristretto di quanto "tutto incluso" lasciasse sperare, e che la lacuna che colma è quella noiosa: il codice della tua applicazione può accodare lavoro senza importare una specifica libreria di code.

Quindi metti a budget una coda di task in qualsiasi progetto Django 6.1 che abbia bisogno di ritentativi, lavoro pianificato o visibilità sui fallimenti. È la stessa voce di prima della 6.0 e, se speravi che questa versione la cancellasse dal tuo diagramma di architettura, non lo fa.

Se hai già deciso che Django fa al caso tuo e preferisci non assemblare da zero lo strato server, il VPS Django di Cloudzy ti dà un punto di partenza autogestito con Django, Gunicorn, Nginx e PostgreSQL, più accesso root quando ti servono Redis o Celery. Il server resta comunque tuo da gestire: salti la configurazione dalla macchina vuota, non la responsabilità operativa.

LEGGI

Come installare Python su un server VPS? | Una guida passo-passo

Il supporto asincrono di Django è ormai abbastanza buono?

Abbastanza buono perché "è solo sincrono" non debba più fermarti, e non abbastanza buono per costruirci sopra uno strato dati interamente asincrono. Alla 6.1 entrambe le metà sono vere. Quale valga per te dipende da cosa stai costruendo e dal fatto che tu lo serva sotto ASGI o WSGI, perché è quella scelta a determinare se ottieni uno stack di richieste completamente asincrono e una gestione efficiente delle connessioni di lunga durata.

Il lato delle capacità non è in discussione. Ogni metodo di QuerySet che innesca SQL ha una variante asincrona con il prefisso a. Il ciclo async for funziona su tutti i QuerySet, e le API asincrone del database includono metodi di modello come asave() e metodi di QuerySet come acreate(). Puoi scrivere una view asincrona che attende query e chiamate HTTP in uscita concorrenti senza alcun wrapper su threadpool. Rispetto al Django di cui parlava la critica "solo sincrono", questo è un altro framework.

A decidere il comportamento è il protocollo di deploy, non la versione del framework, ed è esattamente il punto che il forum di Django deve rispiegare in continuazione. La guida tematica sull'asincrono afferma che, sotto un server WSGI, le view asincrone girano in un proprio event loop usa e getta, quindi puoi usare le funzionalità asincrone ma "non otterrai i vantaggi di uno stack asincrono".

Servire centinaia di connessioni senza thread Python, streaming lento, long-polling: tutto questo richiede ASGI. Stesso codice, comportamento di concorrenza diverso, e niente nel framework ti dice quale dei due stai ottenendo.

Quella confusione ha vita lunga. Un utente che firmava come tomcypress ha aperto un thread sul forum di Django in cui chiedeva perché richieste consecutive a una view asincrona non eseguissero tutte il loro lavoro in background, e l'habitué del forum KenWhitesell gli ha indicato l'event loop di WSGI. Quello scambio è del 2021 e alla 6.1 non è cambiato nulla.

Ed è pure rafforzata dall'esterno. La pagina sui pro e contro di Django di TechVidvan dice ai lettori che Django "non è in grado di gestire più richieste contemporaneamente", il che è falso per Django 6.1 ed è il tipo di affermazione che chiude una valutazione prima ancora che cominci. La concorrenza non è qualcosa che manca al framework; è qualcosa che decide il deploy.

Il vero stop sono le transazioni, e la documentazione asincrona di Django stessa lo dice senza giri di parole:

Le transazioni non funzionano ancora in modalità asincrona. Se hai una porzione di codice che richiede il comportamento transazionale, ti consigliamo di scriverla come un'unica funzione sincrona e di chiamarla usando sync_to_async().

La stessa pagina classifica alcune parti chiave del framework come "non sicure in asincrono" e ne impedisce l'esecuzione in un contesto asincrono, sollevando SynchronousOnlyOperation se ci provi. La forma di un'applicazione Django 6.1 asincrona è quindi: view asincrone e letture asincrone, con isole sincrone ovunque le scritture richiedano atomicità. Praticabile, e non la stessa cosa di un framework asincrono per natura. Il mio giudizio su questo asse: sensibilmente migliore, non finito, e una promozione netta per tutto ciò che non mette la concorrenza al primo posto.

FastAPI ha reso Django la scelta predefinita sbagliata?

Per una categoria specifica e in crescita di progetti, sì. Il Python Developers Survey 2024 di JetBrains e della Python Software Foundation, raccolto tra ottobre e novembre 2024 con più di 30.000 partecipanti, ha messo FastAPI al 38%, Django al 35% e Flask al 34% sul totale dei rispondenti. Fra chi ha indicato lo sviluppo web come l'uso principale che fa di Python, Django era al 61%, FastAPI al 56% e Flask al 39%.

Guarda bene quella domanda prima di portarla in una riunione di pianificazione, perché è a scelta multipla. Ai rispondenti è stato chiesto quali framework usano, non quale hanno scelto, e uno sviluppatore che mantiene un monolite Django mentre scrive servizi FastAPI conta in entrambi. Non sono quote di mercato esclusive, e qui nessuno ha il 38% di un mercato. Quello che mostrano è un segnale spaccato: FastAPI era davanti a Django su tutti i rispondenti, mentre Django era ancora davanti a FastAPI fra chi usa Python soprattutto per lo sviluppo web.

Il sondaggio specifico su Django aggiunge un altro segnale, da parte di chi il framework lo usa già. Il Django Developer Survey 2025, condotto dalla Django Software Foundation con JetBrains su 4.655 risposte filtrate raccolte tra novembre 2024 e gennaio 2025, ha trovato l'82% che scrive Django professionalmente, il 77% che lo indica come il framework che usa di più e il 48% che aggiorna a ogni versione stabile, contro il 40% dell'anno prima. I rispondenti si autoselezionano, quindi descrive la base utenti attuale e non il mercato. Ampiezza d'uso e profondità dell'impegno sono segnali diversi, e il secondo numero di Django è più sano del primo.

I punti in cui FastAPI vince sono più stretti e più netti di quanto suggerisca la forbice del sondaggio. Una superficie API guidata dai tipi, in cui i tuoi modelli Pydantic sono lo strato di validazione e lo schema OpenAPI generato è il contratto, batte Django più uno strato di serializzatori. FastAPI è asincrono per natura a livello di richiesta, ma la sua stessa documentazione è esplicita : le operazioni di percorso si possono scrivere in entrambi i modi, e un handler o una dipendenza dichiarati con un semplice def girano in un threadpool esterno.

E un servizio senza admin, senza form e senza template si porta dietro le batterie di Django come peso morto: paghi per le opinioni del framework e ne usi un quarto. Se è questo che stai costruendo, lo slancio non è hype e faresti bene a seguirlo.

Chi dovrebbe scegliere Django?

Punta su Django alla 6.1 quando admin, autenticazione, form e ORM sono la maggior parte del lavoro che ti aspetta: strumenti interni, marketplace, SaaS di back office. È giusto anche per un team piccolo che ha bisogno che quelle cose funzionino dal primo giorno, e per un team che deve sapere già ora come sarà la sua finestra di supporto nel 2029.

Prodotti in cui le opinioni del framework coprono la maggior parte del lavoro effettivo. Qualsiasi cosa con una matrice di permessi e molto CRUD dietro un login. Qui il fatto che sia il framework a compiere le scelte strutturali è il punto, non un costo, perché quelle scelte sono la maggior parte di ciò che avresti costruito comunque.

Team piccoli che devono essere produttivi dal primo giorno. Con tre sviluppatori e nessun platform engineer, una squadra comincia a scrivere funzionalità mentre l'altra comincia a valutare librerie di autenticazione. Da lì quel divario si accumula.

Team già su Django che stanno pianificando i prossimi tre anni. Django 5.2 ti dà un pavimento supportato fino ad aprile 2028, e la cadenza annuale te ne dà uno prevedibile dopo. Un orizzonte di supporto leggibile vale soldi in fase di pianificazione, ed è insolito vedersene consegnare uno così chiaro.

Chi non dovrebbe scegliere Django?

Non scegliere Django per un'API ad alto throughput o di streaming senza admin dietro: per quella forma di progetto FastAPI è la scelta predefinita più pulita. Non sceglierlo se quest'anno ti serve l'accesso asincrono ai dati transazioni comprese, perché la 6.1 non ce l'ha. E non sceglierlo aspettandoti che le batterie eseguano i tuoi job in background.

Una singola API ad alto throughput o di streaming, senza admin e senza superficie di form. Quasi nulla di ciò in cui Django è bravo è portante per questa forma di progetto, quindi manterresti la struttura di un intero framework per un servizio a cui servivano un router e un validatore.

Team che oggi hanno bisogno di un accesso ai dati completamente asincrono, transazioni comprese. Django 6.1 non supporta le transazioni in modalità asincrona. Avvolgere le tue scritture in sync_to_async() è un pattern legittimo, non un ripiego da cui uscirai quest'anno, e dove questo è inaccettabile si tratta di un blocco e non di un graffio.

Team che leggono "tutto incluso" come se coprisse l'esecuzione dei job in background. Tasks non include un worker. Se il tuo piano dava per scontato che la 6.0 togliesse la coda dal tuo stack, il piano deve rimettercela dentro prima che ti impegni con il framework.

Quale framework web imparare per primo è un'altra domanda con un'altra risposta; le FAQ qui sotto hanno la versione breve.

Sapere dove Django si ferma è ciò che rende sicuro cominciare: le uscite qui sopra sono visibili prima di impegnarsi, invece di essere scoperte dopo.

Domande frequenti

Django è morto?

No. Django ha rilasciato due versioni di funzionalità tra dicembre 2025 e agosto 2026 e ha pubblicato un piano di rilascio ristrutturato che arriva agli anni Trenta. FastAPI è cresciuto in fretta ed era davanti a Django 38% a 35% su tutti i rispondenti del Python Developers Survey 2024, mentre Django era davanti 61% a 56% fra i rispondenti che usano Python soprattutto per lo sviluppo web. La crescita rapida di un framework più giovane e la morte di uno più vecchio sono affermazioni diverse.

Django è adatto ai principianti?

Sì, con l'avvertenza che è quello con più cose da imparare in una volta sola. È l'ampiezza di Django a renderlo produttivo, e comporta che un principiante incontri l'ORM, le migrazioni, lo strato dei template e l'admin prima di aver pubblicato alcunché. Vale la pena leggere la tesi contraria: un post di Bite Code! sostiene che i principianti dovrebbero partire proprio da Django perché i suoi default prevengono errori architetturali che un framework minimale ti lascia commettere da solo.

Django è più veloce di Flask?

Non esiste una risposta universale. Per questa recensione non è stato eseguito alcun benchmark, e non mi fiderei di nessuno senza conoscerne il carico di lavoro e il deploy. In molte applicazioni contano di più le query al database, gli N+1 e le chiamate ad API esterne che l'overhead del framework. Se il throughput grezzo delle richieste pesa nella decisione, misura l'applicazione e la configurazione di server che hai davvero intenzione di far girare.

Con quale versione di Django conviene avviare un nuovo progetto?

Parti dalla 5.2 se conta soprattutto la finestra di supporto più lunga: è l'attuale LTS, supportata fino ad aprile 2028. Parti dalla 6.1 se vuoi il framework Tasks e le funzionalità più recenti della 6.x, accettando supporto principale fino a circa aprile 2027 ed esteso fino a dicembre 2027, e pianificando poi un aggiornamento a Django 6.2 LTS quando arriverà ad aprile 2027. Per Django 6.2 il supporto esteso è previsto fino ad aprile 2030. Da gennaio 2028 in poi, ogni versione annuale di funzionalità porta con sé tre anni di supporto.

Conviene imparare prima Django o FastAPI?

Impara quello che corrisponde al lavoro che vuoi fare. Django ti insegna come si incastra un'applicazione web completa: modellazione dei dati, migrazioni, autenticazione, form, template e l'admin, con la struttura già decisa per te. FastAPI ti insegna il design di API tipizzate e il Python asincrono, con quasi nulla deciso per te. In astratto nessuno dei due è l'opzione adatta ai principianti, e scegliere quello più vicino al lavoro a cui punti batte scegliere quello più facile.