Rediscovering Django: Why Building Websites Like It's 2010 Feels Right
Some more things about Django I've been enjoying
I am exploring backend-focused web development in a 2010 style using Django, finding its query builders and template filters surprisingly effective. While I struggle with performance expectations and prefer function-based views over inheritance, features like automatic database migrations and the querystring filter make this journey achievable. Despite some confusion with settings, enabling template caching significantly improved my site's speed.
I've never had a good experience using inheritance in Python and I don't think I'll try to use it again.
- CraigJPerry
There are so many footguns[1] in async python but it really has stolen the zeitgeist of modern python web. Synchronous django has a lot to commend it. If you deploy it reasonably well (workers, behind a caching reverse proxy etc) it's easy to operate in production even under duress.
It's not going to be the right stack for long lived websocket connections or whatever but for a CRUD-ish or enterprise app, often very productive.
[1] buffer bloat is too easy to sleep walk into
queue = asyncio.Queue() # oops
unbounded concurrency
await asyncio.gather(*(fetch(item) for item in items)) # look mum! no outbound sockets left or maybe even no file descriptors
accidental blocking
data = requests.get(url).json() # oops! we're blocking the event loop
and sure you can setup a separate task to measure the event loop latency and alert on that but this is the kinda thing you'll never find in a tutorial, you just need to experience this stuff and figure out a solution you like
I can go on and on about async python (cancellation bugs, leaking a task - that has a cataclysmic failure mode where if you forget to hold a reference to your asyncio.create_task() then it's all weak refs in that machinery so your task can get garbage collected before it ran or completed in production! super tricky forensics. Then there's all the obvious stuff like race conditions, new ways of creating deadlocks, blah blah i really can go on for days.
- a_c
My experience from running a django app with thousands of migrations and dozen of apps
- Testing involving models is slow. It runs all your migration. Python's own "Unittest" is fast for functions not involving models.
- The suggested pattern for business logic is "active record", which is putting functions about a model alongside the model itself. Good for clean case. Doesn't really work when your operation involve multiple models.
- But if you put function about a model inside a model, the migration doesn't serialize the function into migration history (I could be wrong)
- "Data" migration is handy when you want enum-like data in database available to all teammates. e.g. list of currencies
- It is very tempting for new team member just to create an django app, with its own view and model, because it feels like starting a fresh without needing to care about existing business context. On the other hand, designing conceptual boundary between apps is very important. Because starting app is easy, and often (not always) wrong.
- The squash migration utils are limited because I guess of relatively low usage. It squashes linear migration history (with manual curation of starting and ending migration node I think? Not sure about latest state). I wrote a util to squash whole migration history by finding linear segments and squash those segment of history one by one. Didn't release it, but wrote some notes https://gist.github.com/kmcheung12/08b4c234b38c23efd43550da9...
- melodyogonna
Django is nice, but I'm currently migrating a project from Django to Go because Django is too large. I would love to stay with it, but simply assimilating the docs has been a chore. The PDF is 3000 pages, and I love working with tools where all the parts can fit in my head.
- ranedk
I have been using Django since 0.95 and I haven't seen anything which is so flexible with amazing DSLs while also making it easy to understand the magic behind it.
For the last 10 years, even in a Golang stack or Java stack, I still use Django for models and migration. I even have generators which generate Gorm (or other framework) DAO or Java hibernate classes using Django models.
With LLMs, it becomes easier since I can now write all the model, custom querysets in Django, ask the LLM to generate Golang DAO, setters and getters... and test the query against the Django generated queries for completeness.
Atlas, sqlx, sqlc and all other ORM like things in golang cannot do migrations the way Django does.
- echoangle
> Some light load testing (with (ab -n 1000 -c 1) shows that right now we can serve about 2-3 requests per second (on a ~$10/month VM).
> After turning on template caching, it seems like the site can now pretty easily handle 12 requests per second or so without using all of the CPU. I have not carefully benchmarked the before and after but it seems like it’s made a pretty big difference.
That seems crazy low, I think there has to be something else going on here.
- altbdoor
Good ole Django. Worked with a number of frameworks (tm), but nothing really quite scratches my itch like Django does. I still find the ORM and database migration system unmatched.
- hecreto
Not to be a downer since a lot of JEvans’ content is great. People should really give .NET a try. I don’t know if we are just old greybeard curmudgeons who look at this and go “is this a new thing? haven’t we been doing this for decades?”, but .NET out of the box with a few packages for databases, logging, etc is so pleasant you don’t even think about it. Maybe it’s just not a vocal community idk.
- trojans1290
Is Django still a solid choice in 2026 for new backend projects? Have loved the orm, admin, etc.