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.

I've been using Django since before 1.0, and the upgrade story has been nothing short of fantastic for something that's been around this long. But still, YMMV!

Depending on how ancient a project you run into, it definitely can be a major pain, even with the original authors' best intentions. For example, Django didn't have its own DB migration system until 1.7 (relying on third party solutions); this means you also have to adjust the deployment procedure, which means recreating an ancient setup (ideally in an easily repeatable fashion, because you're going to be trying that migration at least a dozen times).

The builtin admin system is also a pretty decent CMS on its own, but falls short as you run into slightly more complex use cases (such as basically anything that requires even a single line of JS). The docs will encourage you to copy and override the builtin templates; this often becomes a pain point during upgrades. It's wise to get off the builtin admin system as your project grows.

And go to another superbly robust and easy to use actual CMS: wagtail.

Also it's been a few years since I've last used it, but the overwhelming dominance of deeply nested JSON fields makes ordinary DB migrations unnecessarily interesting.

Isn't that a good thing for a Content Management System?

I am not sure I understand what you think could be done to either the admin (or wagtail) to make them "CRUD frameworks".

Is building out the UI clunkier with Django templates than with JSX? Absolutely.

But not having to worry about both server and client side state is such a time saver and you know it is going to continue to work.

For the past few years I've been using Go (using Gin) in place of Django, and it works nicely and is quite a bit faster. However, recently I've been toying around with Django again, thinking about making it my default for new projects because it really does take care of so much that you'd otherwise have to deal with yourself.

Django handles the database migrations and user accounts/models/etc - and you get the useful admin to boot, which is just incredible if you ever need to open up the data layer to someone else.

Then just write the API interface in Go/Rust/your language of choice. It decouples the DB modeling from the API layer, but in practice... I've just not run into significant issues with it. I'm sure it could be an issue though, so YMMV.

You are ultimately still right, I think - just a personal nuance I guess.

At the end of the day I’m delivering reliable and productive solutions for my clients, and they don’t care what the tech is.

However the Django API, GraphQL with React front end stack I’ve inherited is an frustratingly flakey to use and a nightmare to develop :-/

It’s so bad I’m regretting all my life choices that led me to this point LOL

To be fair, in semver that means a breaking change of some sort.

More of a side comment, but I'm skeptical of the way HTMX encourages partial renders like this. It feels like a premature optimization that adds more complexity on the back end. `hx-select` takes care of it, but to me it feels like it should be the default (it's what Unpoly does).

I will admit, Elixir and Phoenix have better real-time and scalability stories.

If I had a choice I would probably prefer Elixir/Phoenix/LiveView when joining an org to work on an established codebase that may have actual scalability needs and concerns. But I would probably prefer Django when starting from scratch.

But I’m abandoning the heavy JS paradigm in favor of htmx. Aside from the fact that I don’t want to duplicate routing and data validation across client and server, htmx is intentionally a single JS file with no build step, so in theory it should run fine as long as browsers maintain backward compatibility.

my biggest beef with it is code organization, which will only get better with more experience. and it's a side project so it doesn't matter. i do worry about using it on a team because i could this stack getting messy if not done the right way.

Related Community Resources

* New goodies in Django 5.0 [blog]: https://fly.io/django-beats/new-goodies-in-django-50/

* What's new in Django 5.0 [video]: https://youtu.be/lPl5Q5gv9G8?feature=shared

* Database generated columns⁽¹⁾: Django & SQLite [blog]: https://www.paulox.net/2023/11/07/database-generated-columns...

* Database generated columns⁽²⁾: Django & PostgreSQL [blog]: https://www.paulox.net/2023/11/24/database-generated-columns...

* Building a Bootstrap styled form in vanilla Django [blog]: https://smithdc.uk/blog/2023/bootstrap_form_in_vanilla_djang...

Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.

Admin interface was extremely helpful, when we are trying to validate business idea.

I find this pretty easy to get used to and re-use. though I do admit I like them defined as actual model-fields with verbose names etc...

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.

Once I had that one migrated route, though, the rest were very simple. (And I am very happy with the migration overall!)

I've had quite enough of DRF's tower of mixins and rails like magic. It always sucks up development time and fails too easily.

Django + REST framework takes a little more to learn than something like FastAPI, but once you understand how all the middleware, permission and query classes work, you can be hyper productive

In recent years Django had multiple major releases, I still remember it as being in 1.x forever. Does somebody know what changed within the Django Community that they break backward compatibility more often?

The deprecation policy[2] is taken very seriously and Django doesn't opt to break things if it can.

Recently there was a very interesting discussion[3] between the Fellows as to whether the version numbering is confusing as this doesn't follow the same pattern as other libraries.

1: https://docs.djangoproject.com/en/dev/internals/release-proc...

2: https://docs.djangoproject.com/en/dev/internals/release-proc...

3: https://fosstodon.org/@carlton/111300877531721385

Idk. I have to grant that Django ORM likes to make your life easy, but lazy loading on property calls is a dark pit full of shap punji sticks. Just overlook one instance where this is happening in a loop and say goodbye to performance and hello to timeouts left and right...

Try using: https://github.com/har777/pellet

Disclaimer: I built it :p

You can easily see N+1 queries on the console itself or write a callback function to track such issues on your monitoring stack of choice on production.

Also we often had something that was more like 1+3N, basically a 1+N problem but it was looping through the same 3 queries over and over.

I don't really have a pitch but here is why this was made:

1. we had a production DRF app with ~1000 endpoints but the react app consuming it was dead slow because the api's had slowed down massively.

2. we knew N+1 was a big problem but the codebase was large and we didn't even know where to start.

3. we enabled this middleware on production and added a small callback function to write endpoint=>query_count, endpoint=>query_time metrics to datadog.

4. once this was done it was quite trivial to find the hot endpoints sorted by num of queries and total time spent on queries.

5. pick the most hot endpoint with large number of queries, enable debug mode locally, fix N+1 code, add assertNumQueries assertions to integration tests to make sure this doesn't happen again and push to prod.

6. monitor production metrics dashboard just to double check.

7. rinse and repeat.

For me this ability to continuously run on prod -> find issues and send to your monitoring stack -> alert -> fix locally workflow is the main selling point. Or of course you can just have it running locally on debug mode and check your console before pushing your changes but sometimes its just hard to expect that from every single engineer at your company. Then again your local data might not cause an issue so production N+1 monitoring is always nice.

Unless it adds a bunch of overhead, seems like a no-brainer to enable.

The header feature can also be useful. If you have a client on-call who's complaining about super slow page loads. Just check their network tab and see which response has a query count/time header which seems unnatural.

I like to describe it as Django's ORM will satisfy 80% of your needs immediately, 90% if you invest and sweat, 95% if you're quite knowledgeable in the underlying SQL. But there are still some rather common query shapes that are inexpressible or terribly awkward with Django's ORM.

SQLAlchemy on the other hand never tries to hide its complexity (although to be fair they've become much better at communicating it in 2.0). On Day 1 you'll know maybe 20% of what you need to. You might not even have a working application until the end of week 1. But at the end of, idk, month 6? You're a wizard.

The long-term value ceiling of SQLAlchemy/Alembic is higher than Django's, but Django compensates for it with their comparatively richer plugin ecosystem, so it's not so easy to compare the two.

If maximum performance, 100% of the time was the end-goal, I would not be writing Python.

Guess who had to refactor this mess and steer away from catastrophy.

I’m haunted to this day.

POC whipped together without good architecture. Having proven itself, usage increases until the application starts to burst at the seams. Program must be redesigned, avoiding performance gotchas.

I still think Django + the ORM give you a lot of runway before performance should be a concern.

FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.

  for book in select * from books:
    author = select * from authors
             where id == book.id
    print book.title author.name

But I have no idea if there are database interfaces that make this problem simplistic. In my experience with Django, anything but the most simplistic page will be so noticeable slow that one has to go through the queries and use things like select related. Occasionally it is also better to just grab everything into memory and do operations in Python, rather than force the data manipulation to be done as a single database query.

It is a good tool for its purpose, but it is no replacement for SQL knowledge when working with complex relational databases.

And as already written above, a slow but correct page is preferable to a wrong page because you ORM is omitting related data.

I've got a customer with two Django apps. One was developed enthusiastically in the object orientation way. The database is a nightmare. The other one was developed thinking table by table and creating models that mimic the tables we want to have. That's a database we can also deal with from other apps and tools.

Where Django’s ORM shines is in the modeling stage: classes in models.py are your single source of truth, relationships only need to be defined once, no separate “schema” file, and most of the time migrations can be generated automatically. It’s truly top-notch.

https://docs.djangoproject.com/en/dev/internals/release-proc...

When a product I think is going to need users and roles and permissions, I grab Django off the shelf and never look back.

Thank you mister reinhardt

There are so much structural mistakes in our codebase, they use async python but messed it up in all the important places yet believe that Django is slow or innadequate.

They belive that Django is too "old school" and that if you want good results you need vue.js an api and all that.

Truth is, no one has the time and experience to make something good with that.

Developpement is very slow and code is buggy management is unsatisfied with the results yet they refuse to try it out.

It seem their ideas are made up and won't change.

- The complete lack of any motivation to support type hints (yes I know about stubs and the other 3rd party).

- The GraphQL situation is a mess. Graphene on again off again development and Strawberry being not quite all the way stable yet sucks compared to how baller DRF is. It's still a massive fight to get subscriptions working well. It would be nice to see the foundation throw them a bone like they did with Channels.

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.

If anyone is curious, I updated my Django / Docker starter app to use Django 5.0 at: https://github.com/nickjj/docker-django-example

It pulls together gunicorn, Celery, Redis, Postgres, esbuild and Tailwind with Docker Compose. It's set up to run in both development and production.

[1] https://github.com/cheatcode/joystick

That's the problem.

Over the years, Django has kept up with changes in web development. An example of this is when database migrations, which used to be a separate project, were integrated into Django itself. The Django community is also strong with great ecosystem projects like DRF for APIs, Django Channels for real-time features, and social-auth for social sign-ins.

My recent use of Django is in (https://github.com/trypromptly/LLMStack). We use Django Channels for WebSocket support, DRF for APIs, and ReactJS for the frontend.

I've read a lot of love for Litestar (formerly Starlite), since it seems people prefer it over FastAPI, Flask, etc.

https://litestar.dev

Or is the preferred web framework still Django?

What do I mean by "cross cutting concerns"? I'm thinking about ORM/models, migrations, admin UI, caching, sessions, misc security middleware, user accounts, validation/forms, templating, RSS feeds, logging, testing infrastructure, etc. Django's pieces all fit together well, and any time I've done this with Flask/etc I've found myself spending so much time solving issues gluing these bits together and working around impedance mismatches between libraries.

We had a large Django site at my last place and would just suggest new starters worked through the Django tutorial, because our site basically still worked like that.

1. You're making something with 100 lines, which you're absolutely sure will stay 100 lines. Go with Flask.

2. Otherwise, Django.

Django is great at getting out of your way when you don't need its functionality, so you can just ignore most of it if you don't need it.

And I've done smaller things with Flask where it would make no sense to go with Django as well but those were things not really built around a db or CRUD API etc.

I used to like DRF (Django Rest Framework) and Django + DRF was a powerful combo to drive single-page-application sites. But DRF can get a little painful if you're not using some of the out-of-the-box classes. Painful as in... lots of code to right and very hard for someone to maintain without knowledge of how DRF magic is made under the hood.

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

The only two things it lacks great support of is typing and async. However the async is actively being worked on and does work (with some quirks), and python's type support has only gotten half-mature just recently (coming from typescript at least).

I would personally be hesitant to try something new just because django is so battle-tested at this stage, unless you just absolutely require better async support.

I recently tried to implement it in a project using the new ORM a-methods (which AFAIK are not even async under the hood) and it resulted in an explosion of complexity bubbling up in many places in the codebase. I reverted everything to sync and re-implemented the hot functions with multi-threading... I think I'll keep to this approach until I see some good guides, codebase examples, and overall feature maturity.

[1] https://lp.jetbrains.com/python-developers-survey-2022/#Fram...