In hindsight, maybe I should've tried to use Django for my previous project instead of build a lot of custom stuff in Go and React. It was basically an admin interface, but with dozens of models and hundreds if not thousands of individual fields, each with their own validation / constraints. But it was for internal users, so visually it mainly needed to be clear.
Some notes on starting to use Django
41–50 of 145 posts
Re: Some notes on starting to use Django
#42I much prefer Python but am not really seeing any point to doing anything other than JavaScript for web projects at this point. I also do not see much reason to do more than emit JSON on the server side.
> I much prefer Python Well... that's a valid reason. Why should I work with tool B when I prefer tool A ? > I also do not see much reason to do more than emit JSON on the server side. That's the "SPA over API" mindset we need to reconsider. A lot (and I mean A LOT) of projects are way easier to produce and maintain with server-side rendered views.
HTMX with Django backend really excels in this regard.
Re: Some notes on starting to use Django
#43After spending a lot of my time on Django, it's fine for simple to moderately complex things. The ORM mostly good. DRF is fine for APIs. And the admin is super nice as well. But once something gets significantly complex, the ORM starts to fall down, and DRF becomes more of a hindrance. But if you're just doing simple CRUD apps, Django is perfectly serviceable.
What does significantly complex mean though? You have to make sure you understand the queries made by the ORM, avoid pitfalls like SELECT N+1 queries and so on. If you don't do this, it'll be slow but it's not the ORM's fault - it's that of the programmer.
Significantly complex means when ORM starts to become bigger and bigger and you need multiple threads and more complex processes that run in workers. When you start to run into scaling problems, your solution is within that framework and that becomes a limiting factor from my experience.
Then as a programmer, you have to find workarounds in Django instead of workarounds with programming.
PS: Dealing with a lot of scaling issues right now with a Django app.
Re: Some notes on starting to use Django
#44Earlier quoted context omitted.
This is the main reason I'm extremely disciplined about making sure all of my personal projects have automated tests (configure to run in CI) and decent documentation. It makes it so much easier to pick them up again in the future when enough time has passed that I've forgotten almost everything about them.
I'm finding that in this build fast and break things culture, it is hard to revisit a project that is more than 3 years old. I have a couple of android projects that are four years old. I have the architecture documented, my notes (to self) about some important details that I thought I was liable to forget, a raft of tests. Now I can't even get it to load inside the new version of Android Studio or to build it. There…
Build fast and break things works great if you're the consumer, not the dev polishing the dark side of the monolith (helps if you're getting paid well though)
Re: Some notes on starting to use Django
#45Earlier quoted context omitted.
Its crazy to me after all these years that django-like migrations aren't in every language. On the one hand they seem so straightforward and powerful, but there must be some underlying complexities of having it autogenerate migrations. Its always a surprise when i went to Elixir or Rust and the migration story was more complicated and manual compared to just changing a model, generating a migration and committing. In…
There is no way to autogenerate migrations that work in all cases. There are lots of things out there that can generate migrations that work for most simple cases.
I end up needing to write a manual migration maybe once every other year in real world use.
Re: Some notes on starting to use Django
#46Django aside, I think this is a really important point: Being able to abandon a project for months or years and then come back to it is really important to me (that’s how all my projects work!) ... It's perhaps especially true for a hobbyist situation, but even in a bigger environment, there is a cost to keeping people on hand who understand how XYZ works, getting new people up to speed, etc. I, too, have found found…
"Cold-blooded software" is a great term for that https://dubroy.com/blog/cold-blooded-software/ (HN: https://news.ycombinator.com/item?id=46488261 )
Re: Some notes on starting to use Django
#47After spending a lot of my time on Django, it's fine for simple to moderately complex things. The ORM mostly good. DRF is fine for APIs. And the admin is super nice as well. But once something gets significantly complex, the ORM starts to fall down, and DRF becomes more of a hindrance. But if you're just doing simple CRUD apps, Django is perfectly serviceable.
In my experience, django-ninja is a great alternative to DRF, precisely because it's so thin, unlike DRF.
Re: Some notes on starting to use Django
#48After working with Django for 8 years, I find it hard to move on to anything else. It's just the right amount of magic, and just the right amount of flexibility, and it's just such a joy to work with.
Re: Django is OK for simple CRUD, but falls apart on anything complex - this is just untrue. I have worked in a company with a $500M valuation that is backed by a Django monolith. Reporting, recommender systems, file ingestion pipelines, automatic file tagging with LLM agents -- everything lives inside Django apps and interconnects beautifully. Just because it's a Django app doesn't mean you cannot use other libraries and do other stuff besides basic HTTP request processing.
Recently I had the misfortune of doing a contract on a classic SPA project with Flask and sqlalchemy on the backend and React on the frontend, and the amount of code necessary to add a couple of fields to a form is boggling.
Re: Some notes on starting to use Django
#49Earlier quoted context omitted.
> I much prefer Python Well... that's a valid reason. Why should I work with tool B when I prefer tool A ? > I also do not see much reason to do more than emit JSON on the server side. That's the "SPA over API" mindset we need to reconsider. A lot (and I mean A LOT) of projects are way easier to produce and maintain with server-side rendered views.
HTMX with Django backend really excels in this regard.
I'd prefer Unpoly over HTMX, but yes, it excels.
Re: Some notes on starting to use Django
#50The author makes a great last point about Settings and it’s something I’ve not considered… ever! I wonder if there’s a feature request for this because having a pre-configured object would be nice for the ability to verify correctness on startup.
In TypeScript, I use the same validation library (Zod) anywhere I need to validate data. So, I validate my config / environment variables on startup using a Zod schema, I validate my RPC endpoint arguments the same way, etc.
I presume you could do the same thing with Django— use Django’s validation feature to validate everything including your config. It’s a nice pattern that gives uniformity and predictability to all of your validation logic.