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.
> 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).
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.
FWIW I've also had the same experience; the last version of Django where upgrading took a non-trivial amount of time was 1.8, because it changed how isolation is enforced within test cases. Since then it's rarely taken more than an hour or two, regardless of how big the codebase is.
I'm with you on this, Django + HTMX + Vanilla JS (where needed) just works which is a beautiful thing.
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.
An approach I've done in the past for projects that are publicly API-based:
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.
As a full-time Node.js dev, I agree with your decision! Too much time is wasted on compatibility problems. I'd almost say it was easier when we just had browsers to deal with. At least you could just drop in jQuery and call it a day.
Yes, jQuery is often derided as outdated, but it worked quite well for a very long time, with minimal hassle for developers. In fact, I was working full-time on static Elixir/Phoenix pages with jQuery sprinkled on top as late as 2022… it felt a bit clunky but it worked as advertised and wasn’t frustrating in any significant way.
I absolutely agree. Recently I had to work on a complex client app, and I could simply not believe the amount of trouble you have to go through when you want to increment the version number of things like React, MUI, webpack, TS by.. one!
> I’m going to skip the drama and just use htmx for the client-side. 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.
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).
There is a package, https://github.com/carltongibson/django-template-partials, that is basically like server-side hx-select, when there is some performance concern. Overall, I agree with you though, hx-select is going to be fine most the time.
There is a header that htmx injects to indicate you want a partial render, and it’s really not that hard to add an if on the server-side to check for it. A larger codebase would probably break templates up anyway for maintainability, so it’s just a tiny amount of extra work if you want to reduce the amount of HTML being sent over the wire and swapped in.
Django and django-unicorn is really nice. It feels like meteorjs but for Django, extremely productive. I've been working with the creator closely and he's awesome.
I haven't used Elixir yet and mostly using flask in Python for work but I started with Django (and still think it's better than flask for most apps). If stuff like https://github.com/aesmail/kaffy (first thing I've found on google, never heard of it before) is on par with the Django admin, would you still use Django or Elixir and never look back?
I don’t know if I would “never look back” to Django (I’m a sentimental person). But admin is one aspect, the other big one is auth. I also like DTL better than EEx/HEEx. And all the pieces of Django just fit together really nicely; where Ecto happens to be the preferred way to interact with a database from Elixir, and Phoenix happens to be the preferred way to build Web apps using Elixir, (maybe with Ash layered on top), they weren’t designed by the same people, so you have packages like ecto_phoenix, ash_phoenix, etc. to make them all play together in an elegant way.
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.
If you want a heavyweight JS framework, Ember is the most stable and best supported. I enjoyed Ember when I used it in the 2015-2017 time frame.
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.
Fwiw trying to get an old ember app running was an absolute nightmare. On top of that it is way too heavy for my liking. Pretty much polar opposite of jquery.
i've been using django + htmx and vanilla js where needed. it's great!
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.
My app is a Django backend and a Vue frontend. There are large swathes of Django that I ignore, but to me the core of Django — its ORM, routing and middleware system, and admin interface — are worth their weight in gold. The migration from DRF to Django-Ninja (which is, roughly, FastAPI + Django) has also been a great improvement in terms of productivity and performance.
Not a lot of whizbang features in 5.0, but GeneratedField looks like a very nice addition, and reason enough to migrate.
Mine too - Vue and django, and the django rest framework, it’s super productive - no writing all the crud views manually for the hundreds of models I have, the django admin interface is very helpful like you say, and backend is running (a very highly customized) django celery mix,
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
GeneratedField looks interesting, but I'm not _really_ sure what gains I get over just calling annotate() on my queryset with some computed fields. At least on the backends where the computed GeneratedField isn't stored.
Actually having the derived data in the database would be helpful for simplifying something like a website search implementation. I know I could have used it last month!
Any resources/examples you'd recommend for a Vue frontend w/django? I've been pretty firmly in backend land for a while and would to experiment with the other half of the puzzle!
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:
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.
If you really need VueJs in the frontend, consider, that you can simple serve the VueJs on any page where it is actually needed. VueJs does not necessarily mean you must create a SPA. VueJs can be delivered like any other script and this is often the easiest way without having to commit to build a full blown SPA.
How was the effort to migrate from DRF to Django-Ninja? I saw Django-Ninja mentioned in another post and am thinking of switching one of my projects over from DRF. After skimming their documentation, it looks very pleasant and simple and perfect for my use case.
Going from 0 → 1 migrated route was "medium difficulty", I'd say — there was a non-trivial amount of scaffolding I had to build out around auth, error codes, and so on, and django-ninja's docs are still a little lackluster when it comes to edge cases.
Once I had that one migrated route, though, the rest were very simple. (And I am very happy with the migration overall!)
Sadly I don't use Django anymore at work but it still has a special place in my heart. The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong.
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 release process is time-based as to roughly every 8 months[1] with X.0, X.1, and X.2 (LTS). This is mostly to communicate which release has long term support.
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.
> The ORM model is the best I've ever worked with and any other always feels clunky with sharp edges to cut you when you hold it wrong.
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...
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.
I think Django's ORM is a product of its time, when limitations about the expressibility of the "active record" concept were not fully understood.
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.
Non-performant code is going to eventually slip into any codebase. The trick is to monitor for when performance falls to an unacceptable level. Not toss all ORMs because some minority of generated queries are problematic.
If maximum performance, 100% of the time was the end-goal, I would not be writing Python.
I sort of said this elsewhere. Others are saying "that's just what happens" and "well, Python?" but it doesn't just happen, and slow database queries are nothing to do with the application language. The problem is Django ORM, like Ruby on Rails, uses the Active Record pattern. Alternate ORMs, such as SQLAlchemy or Hibernate, uses Data Mapper pattern, which avoids the pitfalls of Active Record.
There does seem to be a natural conflict between large data with hierarchical structure and the generally flat lists and dictionaries of Python, that quickly leads to poor performance. It usually only takes a few foreign keys to create an exponential number of queries.
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.
The ORM is OK as long as you refrain from using any inheritance. If you do, the database becomes a mess quickly and only that very Django app will be able to read and write to it (including manage.py shell). Anything else, other apps in any language or a SQL client, will be lost in a sea of tables and joins.
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.
I've found inheritance to be a problem with pretty much any ORM I've used extensively (Django, Hibernate, NHibernate, Entity Framework). It helps to design your OOP model with that in mind; having no more than one level of inheritance, and using inheritance only to supplement a set of common records seem to be good enough rules of thumb.
Not who you’re asking, but I’ve used all 3. I think in terms of query interface you can’t go wrong with any of them. In fact, I like Ecto the most because of its separation between the concept of a “Query” (super flexible and composable) vs. a “Repo” (the module where you call an actual database operation). This helps you avoid hitting the database until you’re sure you want to.
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.
Similar to bitcoin, they changed to a time-based versioning scheme. Major releases don't indicated that they DID break compatibility, but that they MIGHT HAVE, and more importantly prior versions are no longer supported. Effectively the same as a LTS release.
Django is such a lovely framework I can't speak higher praises of it. I'm blessed to still be able to use it in my day to day work. It's maybe not the most flashy framework out there these days but Django and Rails are really the Toyota Corollas and Honda Civics of the web dev world that often go so underappreciated for their unfussy reliability. :)
3 years ago I moved to fast growing startup that was founded with fast api slap-dashed together. I jammed Django down their throats and I can safely say it was the best decision we made as an Org. The teams using Django are far far more productive than the others.
When a product I think is going to need users and roles and permissions, I grab Django off the shelf and never look back.
I am trying to show the value of it in my company: fastapi + vue.js and severy short staffed.
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.
Fwiw, it was an investment while short staffed that paid dividends later on.
It sounds like in your case, like mine, it’s a cultural issue that you are trying to solve, not a technical one. A cultural issue of wanting to deploy and ship a product fast and not worry about the stuff that’s already been solved.
You can always do a POC and show the value of it to the stakeholders. What I did was picked a product that would greatly benefit from it and went through the entire migration process with product and got their buy in.
Yeah this is definitely Django's strength - it has a lot of the stuff you're probably going to need already implemented. Massive time saver when you're setting things up.
Python definitely holds it back though. Does it have type hints yet?
I personally use DigitalOcean but now that Hetzner is starting to get US data centers that is looking like a good option too.
With no other context, if I were creating a startup today I'd likely go with DigitalOcean.
AWS is also another option, especially if you think you'll be using some of their services.
But for a typical web app + SQL database + cache + object storage set up DO works nicely, although I would still use S3 for object storage even though DO has it, I find S3 to be more dependable.
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.
Isn't Developer DX mostly a way to get developers locked into your platform? I have avoided Next.js for this reason, it seems like just a way to funnel developers towards Vercel. DX is largely a service specific problem since its coupled to the service you are deploying to.
Readit News
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.
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.
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.
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
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!)
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.
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.
FWIW they do give you assertNumQueries in the testing tools, which makes it relatively easy to catch this as long as you have tests.
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.
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.
It sounds like in your case, like mine, it’s a cultural issue that you are trying to solve, not a technical one. A cultural issue of wanting to deploy and ship a product fast and not worry about the stuff that’s already been solved.
You can always do a POC and show the value of it to the stakeholders. What I did was picked a product that would greatly benefit from it and went through the entire migration process with product and got their buy in.
Python definitely holds it back though. Does it have type hints yet?
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.
I personally use DigitalOcean but now that Hetzner is starting to get US data centers that is looking like a good option too.
With no other context, if I were creating a startup today I'd likely go with DigitalOcean.
AWS is also another option, especially if you think you'll be using some of their services.
But for a typical web app + SQL database + cache + object storage set up DO works nicely, although I would still use S3 for object storage even though DO has it, I find S3 to be more dependable.
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.