Hacker News new | ask | show | jobs
by Ancapistani 438 days ago
I mostly agree - but not entirely.

Use Django if Django fits your use case. It's really as simple as that. Django is awesome: its features are well-considered, mature, and easy to learn and use. The "batteries included" philosophy means that as long as you're on their happy path, everything will go smoothly and you'll end up saving ridiculous amounts of time.

The problem starts when you try to bend Django to fit your use case, instead of vice-versa. Then all the benefits Django brings to the table turn into things you have to intentionally and carefully work around.

I've used Django ORM without using Django itself several times. It's been a while since I had that particular need, but at one point I'd built out a whole set of in-house ETL pipelines and all their supporting infrastructure using it. Most of that code was in data processing scripts that were only ever called via CLI - but because that company didn't have a ton of Python experience (it was an "enterprise" company circa 2008), and I chose Django ORM because we'd already our people already had experience with it; our reporting system was a Django project. Why require the whole team to pick up another ORM when they already knew one that would work just fine?

I've also used Django without the ORM. I really only wanted a quick web UI that wrapped an existing internal API for a dashboard. I could have used any web framework - or none at all. In fact, the whole thing _could_ have been built in CI and deployed as a static site. I used Django instead because we already had several Django projects in production - so we had documented processes in place to deploy/monitor/manage Django projects, CI templates, and an infrastructure team that we at least knew wouldn't have to get five levels of approval to deploy a "new type of application".