There are cooler frameworks, there are more minimal frameworks, there are more "modern" frameworks. Whatever that means. Yes I would like to work with FastAPI, it is great. But...
Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it.
Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great.
Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it.
Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.
While I have no experience with Django, this could exactly be said about Rails. It's great these two exist and are being worked on for so long and have this level of maturity.
I wonder why Django seems to have a easier time in hiring, considering it should be a smaller market than Rails. Even on HN monthly hiring list Rails and Django open positions is roughly 3:1. And yet I rarely hear Django people ever complain about the lack of talent pool.
As a former Rails dev, my two cents is that the language keeps breaking.
The small changes in 2.7 were understandable, but quiet a few gems that I used broke in 2.4, and in 2.5. It was a pain to fix, some were never updated.
Much how people complain that changing strings in Python 2->3 hurt adoption; we have had breaking changes that can break gems almost every release.
Ruby is a great language, but Python is so much less stressful, easier to find working libraries, and easier to find jobs. The last reason is likely because of the first two.
It is fine to add things, but when you keep changing the language and breaking things; people hesitate to write software in it. There is a reason the Linux kernel has a rule about (almost) never breaking user-space.
I reckon, Ruby and Rails while still heavily used has fallen out of fashion since it's peak time, whereas Python has gotten a huge boost in recent years from data science and being a common teaching language which spilled over to other uses of the language.
In the mid 2010s the python web application space felt very stagnant to me, many semi abandoned projects, lots of people leaving for other technologies. But there has been quite some reversal on that since.
You list a bunch of libraries, but Django is not a library. It is a framework.
The Django file structure, for example, is not exactly optional in Django. Realize FastAPI follows in the footsteps of Flask. Neither FastAPI or Flask are frameworks. As a FastAPI user myself, I do think it’s closer to a happy medium, but it’s nothing remotely comparable to Django.
When using Django, the best advice I have is to dive all the way in. Follow the docs and the best practices first. Besides, manage.py is just like having a well-developed kit of shell scripts/ in your repo.
You write views, and they render templates. There's a file called `urls.py` where you import a view and attach it to an actual url.
So
appconfig/urls.py depends on
yourapp/views.py which renders html using a template at
yourapp/templates/sometemplate.html
Presuming that you want to interact with the database `yourapp/views.py` probably also depends on models from `yourapp/models.py` or some other apps database model.
agreed, I'm more convinced now that django is really enough and get shit done even if there a poor support of async, more convinced after reading this blog post that async python is not faster (was on hn) : https://calpaterson.com/async-python-is-not-faster.html
It's not significantly faster (or slower), it's the author that doesn't know how to run a benchmark. You can read my take on his take [0].
Leaving that aside, async is very advisable (even a must) if your backend throws requests against external and potentially blocking services and you want to keep answering your own clients without scaling for no reason.
This is a question that's largely impossible to answer, but there's a performance vs developer (or business) time calculation to be made.
More aptly, if one can throw another physical server at it, is it worth fixing the underlying performance issue?
Sometimes the answer is yes. If you're at a place with even a thousand physical servers running your process and you can save 2% overall performance with a rewrite, that's saving you 20 physical servers worth of performance.
But often the answer is that it's not worth it. That 2% performance increase on a set of 10 servers is not calculable, and more often even a 10% performance benefit is only noticeable on some specific task, not as a constant overhead.
On the other hand, developer time is expensive and can often be best spend on core functionality.
If Django is, let's say even 20% slower than an async framework like FastAPI, but it's going to save three developers a week of development time to implement a feature in Django, then that's probably a much cheaper solution.
I've used Django, Flask, Sanic and FastAPI[1] and today I often choose FastAPI for my projects, but I think Django is still what I'd turn to if I needed to make a full fledged web application quickly, despite its performance not being as good as FastAPI.
[1] Before I learned Django, I also used Zope, and TurboGears.
That remind me of a meeting a few days ago where we were discussing if we should add another server or spend a bit more time developing something. After some time, I asked about the server cost, and it ended up being something like 100€ a month more to not have to worry about performance for the next year. In that case the decision was easy enough, but maybe some organisations have fixed server budgets and developers. For those, being able to trade developer time for performance, even if it seems inefficient, may be better than nothing.
Yes, 100% it depends on many factors. 100€ euro a month = 1200€ euro a year... Now if a developer can address that in 15 minutes- wonderful, but if it takes her a week... have you won very much, because it's not just the time calculation but it's the other would this same developer could have been doing in this same time.
Moreover, you're right to calculate this per year because maybe you'll throw this entire code away in a year, or maybe it will become the key code for something else, and you'll need to optimize it anyway.
Even sometimes having a meeting to discuss the performance is not cost effective. Six employees around a table for an hour discussing whether or not to improve the performance of 1200€ a year is not cost efficient.
But then again, sometimes it really is. In one environment we were asked to use some tooling on top of the OS that reduced performance by 5%. It was some management toy that would have made the Linux boxes do the same thing as the Windows boxes, but there was a performance penalty of 5%...
5% of 1000 machines is 50 machines, or just over one rack of servers, and so we could go back to management and say "The performance penalty of this is over a rack of machines. Are you sure you want this?" and then they can decide if it's worth it or not.
Server upgrade costs can vary wildly depending on what it entails. The cost of adjusting your EC2 Auto-Scaling Group maximum instance count will be very different than contacting HPE sales department.
At this point it seems that only mainframes can get more expensive than cloud auto-scaling.
But yeah, some places have a very expensive acquisition procedure. To the point that the labor in buying expensive things costs more than the thing itself. But those places "solve" the problem by buying large batches, and the hardware x developer costs comparison don't change much.
> if your backend throws requests against external (and potentially blocking) services and you have the "audacity" of wanting to keep answering your clients.
If you have enough processes/threads running, the CPU scheduler should take care of that , no?
Yes, but more processes means more memory footprint, almost 4 times as much in that benchmark, something the author didn't cover. Threading solves that, but it's way more prone to shooting yourself in the foot than async, especially since it's not baked into Django (i.e. you gotta cook your own solutions over callbacks, polling, etc).
Interesting, those results are the opposite of the techempower frameworks, which find that the async frameworks are always faster: https://www.techempower.com/benchmarks/#section=data-r20&hw=.... Though in general I'm not sure about the value of bringing async to Django. If you want more performance, you can already either throw more machines at it, or isolate some part in a service that can be written with FastAPI/Go/something. Async in general makes the code more complex and harder to write, which seems to be the opposite of what Django is for.
For an alternative to async, with better support (granted the use cases aren't exactly the same), you can hand off some processing to Celery and then get the result to the user via Channels.
It's also quite easy to swap out the templating engine for whatever front end framework that you'd like to use. Django provides tons of value even when used solely as an API server and ORM.
Agreed. Although I usually hate marketing taglines, I think Django quite realizes its tagline of "The web framework for perfectionists with deadlines."
I love Django and have been using it for many many years. Lately, however, I’ve been finding it increasingly difficult not to be annoyed by some aspects of the developer experience. For example I’d choose React + Typescript over Django templates any time of the day.
You shouldn't be downvoted for saying this. As a server-side developer of 20 years the server-side templating languages have a lot to learn from the frontend experience. And I say this as a user of Smarty, Jinja2 and now Twig & nunjucks. Template inheritance is fantastic. But...
Being able to develop and test standalone HTML components using Storybook is a whole lot nicer than splitting a server-side template into components (which Twig certainly doesn't support cleanly), building a tool to render them and then maintaining your own component library. So normally we end up with HTML bits in Storybook which are copied and pasted into Twig templates, placeholders added and then you can guess they get out of sync.
I appreciate the argument that I should "use JS server-side and render ${js_fe_framework_of_choice} server-side" and it's valid. But I'd also like to be able to run components in _any language_ and get the same DX. Note none of this is talking about hydration - I'm wanting to leverage the JS FE frameworks as clever templating engines which output dumb HTML.
I'm talking entirely out of my rear end, but I'm curious if there is any validity to some of these projects that let you run pythonic code in the browser, either through Webassembly or brpython. For example, this projects https://github.com/stefanhoelzl/vue.py claims to let you write Vue.js in Python in the browser, which then gets turned into regular Vue.js components. I imagine a performance penalty, but a developer performance benefit of allowing something else to run on top and make a more composable experience.
Up the wrong tree :) Vue.py gives you a way to write Vue to run in the browser using a Pythonic syntax. I'm talking about running actual Vue code (or anything else in that style) server-side as Django templates.
> For example I’d choose React + Typescript over Django templates any time of the day.
What's stopping you? I use Django Rest Framework to write views and React + Typescript for the front end. Using templates is often way simpler, though.
But that means throwing out a large part of Django and writing lots of "interconnect" code. At that point I think it's better to choose a different backend, one that will generate typed Typescript client code (or use Typescript on the server and some clever metaprogramming).
The thing is that there's no TypeScript backend that gives you as much stuff out of the box as Django. You're either going to spend time on how to communicate between Django and TS, or spend time on how to recreate Django functionality in TS.
Not a Django person, but I've used a few server-side templating languages, and I agree. I'd love to go mostly/entirely server-side, cut down on boilerplate AJAX calls, and ship smaller/less JS-heavy sites to the browser. But I'd also like to write my view logic in a full language, with typechecking and a solid developer experience. I'm hopeful React Server Components will help with at least some of this.
I disagree with that. They are fine for regular forms, tables (as in grids), etc. I usually have a few views using plain old Django templates (with a couple of template tags for additional functionality), and then maybe one view with a full blown SPA in it. No need to build your login page etc in React.
I disagree. The way you can extend sections of other templates without creating an inheritance chain works very well (and I missed in template systems, for Java, for example)
To be clear, I use them as well. And every time I come to regret it unless it's on a site I absolutely do not touch once it's finished.
Templates make it harder to find and debug issues. They have extremely little tooling to give assurances about what they're compiling, whether the syntax is correct etc. This requires you to build massive, flaky test suites.
I'll take react and typescript any day over even one tenth of that.
Well, It is more of a design problem than a Django template problem. If you add more and more logic in the template itself instead of dealing with it in the views context or templatetags, you are bound to find yourself in such position that you have very hard to test code.
The tooling is fine and almost always lets you know where you are breaking stuff. Also, comparing react tooling with it is not fair, it is a much modern ecosystem that has pitfalls of its own.
I have been writing Django professionally for 10 years and React + Django together for 4+ years, so I really know what I am talking about here.
I basically agree. Templates are basically strings, while jsx is in the end a full programming language (js).
It has the downsides you mention (the error reporting is okayish I think). On the other side, you can write html directly (no classname, etc), and there is no transpiling/build tools/server-side rendering to add.
String templates are also side-effect free.
For spa I would prefer React (with Typescript): for a request/response old-fashioned app, or something like htmx/hotwire text templates can be very productive. I see your point though.
Wouldn't all of python have that problem? What you're saying is that there's very little static checks until the code is run, but all of python has that problem too, doesn't it?
Either you write big test cases covering everything, or you live with the knowledge that very unexpected things can be passed in to your methods without you getting notified.
It's less about static checking than it is runtime debugging. When you have a syntax error in a template, Django's error reporting is super opaque about the problem, usually just raising a TemplateSyntaxError with a vague description. This just gives you the python error stack with little information of the actual context of the actual problem in the template itself.
By contrast, if you have a problem in the python code, the exception stacktrace will point you to exactly where the problem originates. If you add a `breakpoint()` call in the source before the exception point and run the request again, you'll get dropped into a live debugging repl
Just the one if you're using CRA. None if you're embedding react as is.
The answer depends on how you're using react, and what advantages you want to get from it. "How many tools" is not a real question to ask. If you're concerned about ease of development and learning curves, then that gives you an actual goal to optimize for, and it won't coincide with the amount of tools (react is harder to use embedded than with tooling, hence why the latter is more popular).
For each and every tool that is added to my project, it needs to be installed by every developer, it needs to be understood at least on some level by every developer, and it needs to be maintained by someone.
I love Django a lot too. It has made MVPs really easy to deliver. At the same time, I am interested in understanding about the disadvantages/quirks of using Django. Do you have more examples that you could share?
Obviously nothing is stopping me, that's not the point. I was just highlighting the fact that in my opinion the DX of parts of Django is inferior compared to the JS frontend ecosystem. As the Django community, I think this is something we should have an eye on.
You're absolutely right in the sense that the Django and other communities should not stagnate and should also keep an eye on what the other frameworks are up to. Maybe the default template engine should be replaced in Django?
Template engines are already configurable and pluggable for quite a while.
The "problem" is that most of the third-party apps that want to provide templates end up using the default, so either you have to reimplement those or stick with the default engine.
You can use both the Django Template Engine and other template engines side-by side in the same project. You can then write your custom templates in whatever you want, and have your third-party apps use whatever template engine they want to.
If anyone's looking something close to FastAPI but for Django, checkout django-ninja [1][2]. I recently joined a team that uses it, and it's pretty nice so far.
Great to see this project moving forward with new features and support for other backends etc. Every now and then I try out other frameworks but come back to Django for many of my projects.
Love Django. But we are using Django with Gunicorn at work and we are having massive concurrency issues (1 process, gthread)... More than 4 concurrent requests waiting on a slow IO and the whole thing melts down...
This is definitely something about your local setup or config. We routinely run hundreds and thousands of simultaneous connections through various versions of Django without much trouble.
One thing I've never been able to figure out with Django is how to properly handle javascript. How do you all handle stuff like js dependencies? What I do now is just copy and paste a dependency like mapboxjs and keep it in the static folder. Would be great if I could use node or something like that and then have a way to import js dependencies in django templates. I've been using htmx and alpine js to sprinkle some js into my templates, but maintaining all of those js files always feel so clunky
Select yes when asked if you want "custom_bootstrap_compilation"
That will configure a gulp task runner that is capable of manage your javascript dependencies, bundle your CSS/JS, and minify your HTML, CSS, JS and images. You will still need to install npm etc. as described here. You will also need to become familiar with how to install and update Node packages.
https://cookiecutter-django.readthedocs.io/en/latest/develop...
Thanks for the tip! Just checked it out. I'm going to give it a go with an existing project. I guess for deploying I nees my build pipeline to have access to node/npm so it can build the right static files right? But I should not need npm in production.
You can use npm or similar to download and install packages, then link them in your template. Just need to get them into the right folder or perhaps link them.
- django.core.cache.backends.redis.RedisCache cache backend provides built-in support for caching with Redis
- The runserver management command now supports the --skip-checks option.
- The shell command now respects sys.__interactivehook__ at startup. This allows loading shell history between interactive sessions. As a consequence, readline is no longer loaded if running in isolated mode.
- New QuerySet.contains(obj) method returns whether the queryset contains the given object. This tries to perform the query in the simplest and fastest way possible.
- Lookup expressions may now be used in QuerySet annotations, aggregations, and directly in filters.
As someone who mostly has worked with minimal web frameworks (no ORM, admin site, etc), Django seems appealing. My only concern is that the ORM seems to be pretty coupled with different pieces of the framework, and I'd prefer to write SQL and wrapper it on a function on the model. Is my observation on the coupling off? Does anyone here have a good bit of experience using the raw SQL option for queries most of the time? I've seen people do it once and a while in situations they needed it, but no one who uses it as heavily as I'd plan to use it.
I took that approach on my latest Flask project and it’s gone quite swimmingly. The problem I ran into was that a lot of the ecosystem, and therefore documentation, blog posts, helper libraries, etc., are all written under the assumption that you’re using an ORM. It took a while to figure out how to work around that, but once I did, I was home clear.
I also used a helper library to automatically map namespaced .sql files onto python functions with various return types, which made the development process way more elegant: https://nackjicholson.github.io/aiosql/. Absolute game changer if you plan to go this route - can’t recommend it highly enough.
I remember seeing aiosql a bit back and being impressed. I'll give that a shot.
Right now I have a Flask application with separate dataclass models where I write a function like `get_by_id` and then then query the DB and get a dict back (using psycopg2 with DictRow returns) and then I can pass that directly to the dataclass constructor with `User(**row)`. Very flexible and working really well so far. Not sure how this scales though, but I'm happy with it at the moment.
Last week I was trying develop a quick prototype, and instead of setting up a C# project, I tried Django.
At first, everything seemed super easy, but later I hit so many road-blocks that I had to give up (For example defining a self-referential m2m relationship with a custom join table, and getting it working on the admin site).
Don't people really have such problems with it? It really feels like a huge burden when you do things outside the happy-path. Also the documentation is indeed superb but you also hit a lot of outdated info when searching the web.
I used Django for 4 years, their ORM is a mess imo. I wouldn't expect someone new to it to be able to discover how to do this after a couple of hours of reading.
The ORM is great ... but is a question of taste/previous experiences. Once you start playing with annotations, DB-side functions and subqueries, it is very nice.
Only frustration I have is the power/possibilities of mysql (which I use 99% of the time for various reasons) versus postgre. The latter seems far better and advanced, and it does reflect in the ORM.
I agree. I can generally do what I need to with the ORM, except in extreme cases where you probably should be writing custom SQL anyway. I do fight with Subquery and OuterRef now and then, thinking OuterRef isn't being used in a Subquery when it is, but a little debugging usually resolves that.
The one thing I really wish Django had after all these years is multi-column PK support. I bring it up every time I see a thread about Django, hoping the devs or an open-source contributor will take it on. But after 10+ years, the open ticket just keeps passed on and I don't know that I have the skills to do it myself.
Django currently requires that every table have a _single_ primary key column. You can have a unique multi-column index, but you _also_ need to have a single primary key column, which sometimes makes working with existing databases tricky or inefficient.
Basically, the multi-columns end up needing to be exposed as a single python object (CompositeField) to stay compatible with the rest of the framework, but do changes to the individual "subfields" on the row-object need to be kept in sync (data binding) with the CompositeField-object and maybe vice-versa? Now we need an "Observer" (which Django doesn't currently have) to watch for changes to fields, etc. So a lot of new concepts end up needing to be introduced to make this happen. And it needs to work with migrations and serialization while trying to maintain backward-compatibility.
That might be a matter of taste, or which ORM you've used previously. Personally I think it's the only sort of okay ORM, besides Go's sqlx, which is barely an ORM.
You do need to have the documentation handy, and writing efficient queries can be tricky, but it is the ORM that makes the most sense to me, and the easiest to get started with.
When you're a Django beginner, yes, it can be annoying to go from something that's just super easy to having to stitch together something yourself. I'm not sure what exactly causes this feeling, but I did learn that you need to have the right perspective on some things and either let it go or find some other way.
For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack.
I think that most of the time, Django just gets out of the way. At least if you stay away from the inheritance spaghetti that is class-based views. Use the functions, Luke. :)
> For instance, in my experience the admin site is best thought of as glorified DB UI. If you need something more than what it can offer out of the box, you should switch to coding it yourself, or live with a quick hack.
Agreed. My biggest Django headaches ultimately resulted from me trying to make the admin console do more than it's meant to do.
There are certainly limitations to the admin console/module, but it is still rather amazing. The amount of stuff that it will allow you to do is pretty impressive.
Sure, you easily get into a situation where you're out of luck using the admin module, but there are also entire classes of problems that can be solved using only the build in admin functionality.
Yeah, the trick I've learned is to design my models in a way that I know will work well in the admin. It's a little backwards, but it means I can keep using the admin.
With Django as soon as I have anything to do with a database I seem to hit this with the ORM. So I start working around it. Next thing you know it all seems to fall apart because of how coupled the rest of the application is to Django's assumptions about views and entities in the DB.
So "You gave up instead of reading the docs.": I go back to flask, or recently FastApi where you have to figure your schemas and access patterns out for yourself in advance instead of building thorough and deep knowledge on how to deactivate parts of Django when they become redundant. Opinion my own, results may vary, IANA your dev, etc
For most frameworks,etc... I find that things get harder as the project grows in size and more code is added. Strangely, I find the complete opposite with Django. I find that adding new features and apps in my day job is easy and I barely even think that I'm using Django, but trying to start a hobby project with it is initially a bit of a nightmare
That being said, weighing up the good with the bad, its still my favourite web framework
Not my experience. I inherited two Django projects, and adding features is quite cumbersome. I had to add one boolean switch which Django only has to pass from an Angular form to a template, and I had to alter the code in 7 places (one of which is the Angular code). It's just not suitable for REST-like access from a front-end, nor for data that's not a tree, nor for heavy processing: I ended up pulling all kinds of tricks to keep processing time limited, and at a few points resorted to writing SQL queries. It's pretty heavy on CPU and memory.
> It's just not suitable for REST-like access from a front-end, nor for data that's not a tree, nor for heavy processing
It obviously depends very much on your opinion on what defines "heavy processing", but we do all those things without too much trouble. Obviously we may, and probably do, do things differently to you (we dont use Angular for example, though that seems like it wouldnt be too big a factor) so YMMV, but yeh, for us its been pretty solid
You can assume that I have the decency to check the docs before I even ask on Stack Overflow, let alone complain about it on HN :)
I did follow the docs, it gave errors for one reason after another, and I don't have the time to dive into Django internals anymore when stuff like that keeps happening. From there came my opinion that non-happy path is not very much supported.
I am usually a symfony developer, but have also worked for some clients projects which needed to be done with ASP.Net MVC, and I would agree with you that Django, I think, is the most limited one. If you are used to work on a complete and extensible frameworks. But I also think that python is not really made for making extensible code, as without typing or interfaces it gets really hard to create something solid
I think he refers to that you can customize the table Django sets up to handle the m2m which normally is "hidden" (i.e. you don't define it explicitly). But if you want to track for example the time a relation was set up, you can define a custom m2m object that contains a DateTime.
Django Admin is not really designed to be an all-encompassing admin solution I've found, it's a good start but normally you design your own admin console anyway using your API so I've not cared that much about those shortcomings.
Interestingly, I also considered doing a recent prototype in C#, but opted to try Django. I didn't hit any roadblocks like this though, overall the experience was pretty nice. The fact that the Django admin site allows you to get instant CRUD functionality from your models with almost zero effort is something I've not seen in other web frameworks (maybe nest.js gets close, but I'd love to see a .NET equivalent to the admin site).
I had the same impression when I tried it a few years ago (also coming from a .NET background).
I never got the chance to use it professionally so I didn’t get the “fully under control” feeling I get when working with .NET, thus never had the confidence to push for it in my company/clients out of fear of not being able to fix whatever went wrong.
Kind of regretting not making the switch back then, but well, nowadays .NET is good enough. Never managed to squeeze as much productivity as I did with those small college projects back then.
I think with Django, you should pick the parts that you like and not touch the others. Then, design your application around the limitations of Django.
If you have a data model that requires a self-referential m2m relationship, think if there is another way to model it ("collection" object), or don't tell Django about it.
OT, but how do you feel C# (w/ ASP and EF, I suppose?) stacks up in productivity and TTM? What's the kind of problem you run into where you start feeling like you're not working on the domain but on side details?
I didn't want to deal with the front-end. It took me, however, less time to create a custom front-end (for a particular task) than dealing with Django-admin. YMMV.
With Entity Framework and Dapper, I don't think I can be more productive at the back-end in any other stack than I'm with .NET. If I have a couple of models, I'm usually done with basic CRUD, including REST controllers under an hour.
For the front-end, I wrote a couple of purpose-built generators for now.
There’s this enterprise mindset surrounding .NET where it feels like you need a lot of boilerplate to do anything, all for the sake of testability. I think I just dislike working with interfaces.
For beginners, there are much better alternatives and, frankly, Django way of development is severely restricting.
Starting off with an API backend and a React/Angular/Vue front end, allows new developers to learn better abstractions (and not merge front ends and back-ends)
The very idea of "sending UI code to the front end for every request" is unsuitable for medium to large projects. But, if you start building smaller projects with an vertically integrated system like Django, it becomes increasingly difficult to think about larger projects.
I think for beginners Django rocks. I dont do software at all in my career (Engineering), but I can pick-up a django project, look through the example project in the documentation and then throw (and I mean throw) together a working django project in a few evenings. With a very much an amateur knowledge of python. As in another thread, the css takes longer.
Are they any other beginner alternatives I should be looking at ?
What medium to large projects do your speak of? Somehow, Basecamp, Instagaram, Facebook made it to so many users without using any front end framework?
Starting of beginners with MVC /MVVM model is not any different than Server <-> API, If you stick to its rules.
Django/Python is the first "real" thing I ever learned while teaching myself to become a developer (through Harvard's CS50web course), and I found it very easy to learn and pleasant to work with. It has its quirks, but what doesn't?
Once you move on to using Django (probably with REST Framework) for the backend and React or some other JS framework for the front-end, you get some slightly difficult things involving Auth and some other stuff, and of course you can take the complexity as far as you want and I'm sure there are some Django devs with 10-15 years of experience who are experts in parts of the framework that I'm not even aware of, but I don't think learning Django to the point where you can ship a reasonably competent app is more difficult than learning Node/Express, or Rails, or whatever.
"sending UI code to the front end for every request" makes more sense to some than ending up with client-side generated bloat of severe cases of divitis and/or custom tags nested ad infinitum. :-)
Django gets the shit done. There are plenty of developers to find for it. Lots of good quality plugins. Every problem you have, infrastructure wise, is often already solved and there is a blog post of it.
Its good parts and its bad parts are widely written about. And if that is not enough: the documentation is great.
Great framework to get your product to market, it allows me to focus on building products. I dont want to think about routing forms processing, or project layout again. I want to write code for the product, not for the framework. Django is just good enough. Forms, URL routing and models are not what delivers value to products I am working on. So I don't want to spend time on it.
Remember: no customer cares about your product being run on cool-async-framework-X. Customers just want a good looking and good working product.