Django é chato, e é por isso que eu ainda escolho

Toda vez que começo um projeto novo, tem um momento em que eu poderia escolher a bola da vez. E, com uma frequência que já virou piada comigo mesmo, eu acabo abrindo um django-admin startproject. Não porque o Django seja o melhor framework do mundo. É porque ele é o meu, e porque ele é chato no melhor sentido que existe em tecnologia.

Mas antes de explicar isso, preciso ser honesto sobre uma coisa: eu não cheguei no Django por mérito. Cheguei por sorte.

Eu estava na sopa

Conheci Python na faculdade, através de um professor, o Marco André. Foi por ele que eu esbarrei, ainda muito verde, em gente que hoje é referência da comunidade: Luciano Ramalho, Osvaldo Santana Neto, Érico Andrei, o Dorneles Treméa, que a gente perdeu. Não fui eu que corri atrás deles. Eu só estava por perto.

Isso me colocou na comunidade Python brasileira num momento específico: quando dois frameworks estavam surgindo ao mesmo tempo, o TurboGears e o Django. Eu não escolhi o Django por uma análise fria. Eu estava ali, no meio da conversa, quando aquilo estava se formando. Colaborei com o site inicial do Django Brasil e com o projeto de tradução, não como protagonista, como mais um par de mãos animadas. Foi quase como estar na sopa nutritiva no começo da vida na Terra: eu não fiz a sopa, só tive a sorte de estar dentro dela.

Depois vieram os encontros presenciais. A Python Brasil 3, aqui em Joinville, me apresentou outras pessoas que também usavam Django. Numa Python Rio, não lembro se foi a 4 ou a 5, eu finalmente botei rosto em gente que eu só conhecia das listas de discussão, como o Andrews Medina e o Semente. A comunidade saiu da tela e virou gente.

E o Django, nesse caminho todo, foi mais professor do que ferramenta. Foi com ele que eu entendi orientação a objetos de verdade. Foi ele que me ensinou MVC na prática. Depois REST. Depois API first. E o tempo todo, lá estava o django admin, as tais baterias inclusas, resolvendo o que eu não precisava reinventar.

Por que eu ainda pego ele

Vinte anos depois, framework nasceu e morreu, hype veio e passou, e eu ainda pego o Django. Os motivos não são glamourosos.

O primeiro é familiaridade, e não tem vergonha nenhuma nisso. Eu conheço a infraestrutura, conheço o MVC dele, conheço as libs, sei onde as coisas quebram. Numa decisão sob prazo, isso vale mais do que qualquer benchmark de página de marketing.

O segundo é que o Django é chato. Boring. Ele funciona. Ninguém acorda com um susto de que a versão nova quebrou tudo. Existe um conceito, "choose boring technology", que é mais ou menos isso: na maioria dos projetos, o valor está no problema que você resolve, não no framework que você usa pra resolver. Uma base estável e previsível te sobra energia pra parte que importa. Quando eu digo que o Django é chato, é o maior elogio que sei dar.

Na prática, o que isso me economiza:

• O django admin resolve CRUD e backoffice em horas, não em semanas. Já vi isso poupar meses de um projeto.
• As migrations deixam eu lidar pouco com o banco no dia a dia, sem perder o controle do que muda.
• O ORM é competente e, quando aperta, me deixa descer pro SQL cru e otimizar a consulta na mão.
• Integra sem drama com o resto do ecossistema Python: Pillow pra imagem, as libs de análise de dados que eu já uso de qualquer jeito.

E aqui vai a parte honesta: quase tudo isso outros frameworks também têm. A diferença não é técnica. É que no Django eu tenho quilômetros rodados. Sei dirigir ele no escuro. "Eu conheço isso a fundo" costuma me servir melhor do que "isso aqui é 15% mais rápido no papel".

O melhor exemplo do que eu chamo de baterias inclusas cabe em poucas linhas:

from django.db import models
from django.contrib import admin

class Produto(models.Model):
    nome = models.CharField(max_length=200)
    preco = models.DecimalField(max_digits=10, decimal_places=2)
    criado_em = models.DateTimeField(auto_now_add=True)

admin.site.register(Produto)

Você descreve o dado uma vez e ganha o banco, as migrations e uma interface administrativa completa de graça. É pouco código pra muita coisa pronta.

Onde eu não pego o Django

Se eu parar por aqui, isso vira propaganda, e propaganda é exatamente o que eu não quero escrever. Django não é resposta pra tudo, e tem cenário em que eu olho pra outro lado.

Quando o que eu preciso é uma API pequena e rápida, sem o peso do framework inteiro, o FastAPI faz mais sentido. É mais direto pra isso.

Quando o projeto é front pesado e eu quero deploy trivial, uma aplicação Next com front e back juntos na Vercel sobe mais fácil do que orquestrar um Django. O Django ainda te empurra pra uma arquitetura mais tradicional.

Quando o gargalo é desempenho bruto e custo de infra, Go costuma sair mais barato de manter e escalar. Django é produtivo, não é o mais leve da prateleira.

E tem as implicâncias do dia a dia. O ORM que eu elogiei é uma faca de dois gumes: ele esconde o banco tão bem que é fácil um dev menos experiente escrever uma consulta que dispara um N+1 e nem perceber. A história de "só HTML e CSS, sem JavaScript" também envelheceu: no momento em que a interface precisa ser rica de verdade, você acaba pendurando algo do lado, um HTMX, um React. E o async do Django, embora exista há algumas versões, ainda é uma área onde dá pra tropeçar se você misturar sync e async sem cuidado.

Nada disso me faz gostar menos dele. Só me lembra que escolher ferramenta é sobre encaixe, não sobre torcida.

O ponto

Se você está começando, o Django é um dos melhores lugares pra aprender, porque ele te ensina os conceitos certos enquanto te deixa entregar coisa de pé. Foi o que ele fez comigo. Se você já tem estrada, o convite é outro: reparar em quanto do seu "melhor framework" é análise fria, e quanto é o conforto legítimo dos seus próprios quilômetros rodados.

Eu não escolho o Django porque ele é o melhor. Escolho porque ele é chato, estável, e porque eu tive a sorte de estar na sala quando ele nasceu. No fim, as duas coisas valem muito.