Django 5.0

I'll preface all of this with a couple esoteric design goals that I had in mind:

1. I actually _want_ an SPA. You might not need an SPA, if you don't need one then Vue/React/etc are overkill, etc.

2. I want to power as much of the SPA as I can using the same REST API as my core product, both for dogfooding reasons and for consolidation. Many people might argue that this is a bad idea.

---

With that in mind, some specific packages that I highly recommend:

1. Django-vite (https://github.com/MrBin99/django-vite). This makes it very easy to serve an SPA from the actual django response/request model

2. Some sort of way to get type information (if you're using TypeScript) into the frontend. I use a frankensteined system of the OpenAPI spec that django-ninja generates + openapi-typescript (https://github.com/drwpow/openapi-typescript). This means when I add, say, a new field to a response in Django, I immediately get typechecking for it in Vue — which has been _tremendously_ useful.

3. Django-typescript-routes (a package I extracted and open-sourced!: https://github.com/buttondown-email/django-typescript-routes) which gives your front-end routing information based on the Django router.

can you list the features that are lacking in django?

Django made me fall in love with programming 13 years ago, and since then it has always had a special place in my heart.

I’m revisiting a business idea I was working on for a couple years, before I sought and found employment in the industry (where I used Java for a couple years, then Elixir for a couple more). My project was built with Django and Django REST Framework, and Ember on the client-side. 6 years later, the Django side needed minimal changes and is up and running (I jumped all the way from 1.11 to 5.0 beta).

Meanwhile, the Ember part is “lost in time… like tears in rain”. I tried everything, downloading older versions of Node and even the now-deprecated Bower. I don’t fault Ember (which is actually the most stable of the major JS client frameworks). But the JS (especially Node) ecosystem is beyond redemption in my eyes.

For my rewrite of the client, I’m going to skip the drama and just use htmx. Render Django templates server-side, include a single JS script, thrown in some HTML attributes, distinguish between full page requests vs. requests for a partial with updated data, and call it a day. No TypeScript, no Webpack, none of that nonsense. If I need special interactivity I can throw in some hyperscript.

At work I’ve used Elixir/Phoenix/LiveView and it’s revolutionary, truly awesome tech. But to get to market I would rather not have to customize an auth system and build a decent admin interface myself (I tried Ash; its auth and admin are not mature enough to be compared to what “just works” with Django). Yeah, it won’t be as scalable as a Phoenix app, but to me, Django seems like the most clean and rapid way to get to a point where you’ll actually need scalability.

IMHO... Django hold a high standard in terms for projects running beyond the infamous 5+ years of support... still have some projects that with minimal changes (mostly configs and dependencies that got redundant/integrated into django -like choices-) are working with the latest version, surely 5.0 will not be that drastic if you are already doing software "the django way".

Things that are Django achilles heel are not developing software "the django way", mostly anything that needs some client-side to work is a PITA, requires lots of rewriting and custom templates that at some point you gotta start looking django as a backend more like the full stack framework that was meant to be. Also anything related onto getting things to production is another PITA that hasn't been solved or touched in years, dx deployment is one of those things almost any JS Framework out there is doing things better than what django supports.

I choose between Django and Litestar these days.

I wish I had a hard and fast rule for the choice, but it's something like:

- Litestar if I know with certainty (a) the thing I'm building is and always will be a tiny service and (b) I probably won't have to evolve the backing data schema much. Wrap an ML model? Litestar. Have a small database I want to expose via API, read-mostly? Litestar.

- Django if I know (a) I'm going to be building on this over a longer timeframe, (b) I have complex user/group auth needs, (c) my data schema will likely go through substantial evolution, or (d) I will need an admin UI in the early goings, either for the managing team or for customer support.

I have plenty of SQLAlchemy+Alembic+Litestar backends but I vastly prefer the creature comforts of Django's ORM + migrations; it hits that 80% sweet spot so very well. SQLalchemy is both raw power and, often, far too much friction.

I used to choose between Django and Flask, but Litestar -- while still young -- seems to capture most of the key things I liked about core Flask but in a more modern package. (Maybe Quart, aka async Flask, will ultimately win the day; not sure.)

It's not targeted at the use case, but I wonder if Datasette will replace my need for the Django admin UI at least in some limited set of cases.

These days, most of my front-ends are React+Typescript+Vite.

(FWIW I personally avoid FastAPI entirely. I appreciate the impact it had getting the python community to think about (a) async (b) proper use of type hints in the web context and (c) the need for OpenAPI support, etc. but there are a lot of footguns and so many issues still opened that its (amazing, lovely) single maintainer probably won't get to. SQLModel -- aka the merging of Pydantic + SQLAlchemy ORM models -- is an even bigger trap, IMO.)