Hacker News Reader

Comment by adamrt | Hacker News Reader

I've heard people complain about Django many time on HN. I started using it back in the 0.96 version, so maybe its just a familiarity thing.

But I built 3 large successful applications in it in that time. I loved it. I don't use it regularly anymore since I mostly moved away from webdev, but I recently came back into contact with my largest project I build in 2018/2019 and its been running perfect this whole time and was a pleasure to dive back into.

Django just felt logically organized, documentation was on point, core was very readable (at least then).

I always just felt so productive in it. I know everyone has different opinions, experiences and products they are building, but I'm always surprised with the negative comments. I definitely prefer SSR with its reasonable though, so maybe thats part of it.

View on HN

Most of the complaints I've read about Django on HN have to do with ASGI support - which Django added. They're valid but outdated complaints.

ASGI support for Django landed in 2019. Those comments are very outdated

https://docs.djangoproject.com/en/5.1/releases/3.0/#asgi-sup...

tbf it was borderline unusable until they added async DB query support in 4.1 (2022) - before that you had to wrap every DB query with sync_to_async, async_to_sync and it generated too much boilerplate code..., and even in 4.1 the DB queries themselves were still sync/blocking, not truly async because at that point they didn't yet rewrite their database "backends" to use async querying, and I believe that as of now the Django's DB engine still doesn't support natively async DB queries/cursors/transactions/...

Also, lots of the "batteries included" into Django don't have async interfaces yet.., for example the default auth/permission system will get async functions like acreate_user, aauthenticate, ahas_perm only in 5.2 which is expected in April 2025, so as of now these still have to be wrapped in sync_to_async wrappers to work...

Also I think most people don't know how much you can scale with gunicorn+gevent before attempting to migrate to ASGI.

My complaint with Django is/was that it's fantastic for building brand new apps starting from scratch, but less pleasure to integrate with existing databases. The last time I tried to add Django models to a DB we were already using, there was an impedance mismatch which made it hard to fully model, and I gave up trying to get the admin to work well with it. The ORM and admin are 2 of Django's biggest draws, perhaps the biggest. Without them, it's not so pleasant.

That's when I first came to love Flask. SQLAlchemy will let you model just about anything that looks vaguely database-like, and Flask doesn't really care what ORM (if any) you use.

TL;DR Django's opinionated. If those opinions match what you're trying to do and you can stay on the golden path, it's freaking great! Once you get off in the weeds, it quickly becomes your enemy.

> If those opinions match what you're trying to do and you can stay on the golden path, it's freaking great!

That's a great summary. I wrote a few significant flask apps many years ago as well and I'm a huge fan of SQLAlchemy. My flask apps were greenfield so I ended up building crappier versions of alot that Django provides. I still enjoyed it but I wasn't as productive. But with a legacy integration, it would be hard to beat SQLAlchemy (I think its great for greenfield too). I've basically landed on your comment above as well.

> less pleasure to integrate with existing databases

Why even do that? Our app integrates with multiple databases and the Django ORM only knows about one of them. For the rest, we use plain SQL.

Reply on news.ycombinator.com