HN Reader

Django 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 that my interactions with past versions of myself across decades has been a nice way to learn good habits that also benefit me professionally.

For anybody starting with Django, I had written a bunch of guidelines some years ago https://spapas.github.io/2022/09/28/django-guidelines/ (after more than 10 years using exclusively Django for my work)

Nice.

As a mostly-django-dev for the last 15 years, who's been exposed to FastAPI and various ORMs again recently, I should get round to write a doc about some Django bits.

Django is pretty nice, the changes between versions are small and can be managed by a human.

Part of the reason that you can have the big ecosystem is that there is a central place to register settings and INSTALLED_APPS, middleware etc.

That enables addons to bring their own templates and migrations.

There is a central place a bit further up in manage.py and that enables you to bring commandline extras to Django (and many of the things you install will have them).

Coming to a FastAPI app with alembic and finding a lot of that is build-it-yourself (and easily break it) is a bit of a shock.

The Django ORM at first can seem a little alien "why isn't this sqlalchemy" was my reaction a long time ago, but the API is actually pretty pragmatic and allows easy extension.

You can build up some pretty complex queries, and keep them optimised using the Django-Debug-Toolbar and its query viewer.

The ORM, Templates and other parts of Django pre-date many newer standards which is why they have their own versions. As a Django dev I only just discovered the rest of the world has invented testcontainers, and databases as a solution for a problem Django solved years ago with it's test database support.

I quite like the traditional setup where you have settings/common.py and then settings that extend that - e.g local.puy production.py

If you ever need a CMS in your Django project I strongly recommend Wagtail, it came after the initially most popular django-cms and learned a lot of lessons - feeling much more like a part of Django.

It has the same feeling of being productive as Django does when you first use it.

The Django ORM / migrations are still basically unmatched in happiness factor.

I always return to Django for any project. It's fantastic. Enough batteries are included with it that it is very powerful.

Cool stuff. I just started open sourcing a command-line tool for deploying Django to a server. It handles SSL certs, databases and backups, automatic error emails, and background tasks via celery / redis. The best part? It does not need Docker. It just runs everything on bare metal.

1: https://github.com/mherrmann/djevops

Thanks for this! I wish there were more cross-comparisons like this out there of what it is actually like to use some of these frameworks, the note on Django being a little less magic than Rails makes me genuinely interested in it.

> I love being able to backup by just doing a VACUUM INTO and then copying the resulting single file.

Naively, I would probably just copy the sqlite file. Is that a bad idea?

Claude Code is also very good at building basic CRUD apps with Django.

After 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 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.

After 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.

The 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.

Alternatively look at https://sqlite.org/backup.html for backing up the sqlite db, instead of using VACUUM INTO

IMO Django is a buggy and poorly designed framework that locks you into bad decisions.

It's a combination of things that all suck: the - ORM (sqlalchemy is better in every possible way. django's orm is very poor and can't express a lot of sql constructs at all) - templates (jinja2 is basically identical except performant and debuggable) - routing (lots of wsgi routers exist and are lightyears ahead of django)

Don't use Django.

Reference (me saying the same thing 16 years ago): https://news.ycombinator.com/item?id=1490415

Django is great, but it lacks typing in code, but especially in docs. It would spare me a lot of bugs.

IMO, type annotations should only be omitted in obvious cases or simple/MVP projects.

Here's my notes on starting to use Django: don't

I 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.

Some more Django recommendations from Frank Wiles of Revsys (Django consultancy): https://frankwiles.com/questions/starting-django-projects/

I'll add a few of my own:

* Set up the project using uv

* I name the django project "project"; so settings are project/settings.py, main urls are project/urls.py, etc

* I always define a custom Django user model even if I don't need anything extra yet; easier to expand later

* settings.py actually conflates project config (Django apps, middleware, etc) and instance/environment config (Database access, storages, email, auth...); I hardcode the project config (since that doesn't change between environemnts) and use python-dotenv to pull settings from environment / .env; I document all such configurable vars in .env.example, and the defaults are sane for local/dev setup (such as DEBUG=true, SQLIte database, ALLOWED_HOSTS=*, and a randomly-generated SECRET_KEY); oh and I use dj-database-url to use DATABASE_URL (defaults to sqlite:///sqlite.db)

* I immediately set up up ruff, ty, pytest, pre-commit hook and GH workflow to run ruff/ty/pytest

Previously I had elaborate scaffolding/skeleton templates, or nowadays a small shell script and I tell Claude to adapt settings.py as per above instructions :)

Django is objectively the most productive "boring technology" I've ever worked with for developing web applications. They don't regularly add too many bells and whistles on every release, but they keep it stable and reasonably backwards compatible.