What’s better?
But as soon as you go to the JS world, you won't find any full-featured framework like Django or Rails. The Django's philosophy is that all components are built by Django team itself whereas in the JS world, existing frameworks tend to gather independent components and define conventions to make them work together in an elegant way, which is very different.
Switched from Django two years ago and never looked back. Having worked with both, Rails is more polished and pleasant to work with.
Side note: if you're building a business and already know Python/Django, stick with them!
When it comes to arguing over large projects, the difficulty to rebuke comes not from subjectivity, or trivial-ism, but from the project being so complex there are few with the context/experience who can properly compare the two.
I’m not disagreeing with you at all (as you’re expressing your valid opinion!) but wanted to leave a note to say Django is still great and still preferred for many of us. I also agree with you that it’s probably not worth switching if you’re already on one framework or the other; they both have their strengths and good communities.
As someone who has used Django, Rails, and Node, I’d recommend Elixir and Phoenix. Elixir has excellent tooling and dependency management, is functional and therefore easier to write concurrent applications with, it stores threads in private memory and uses the actor model for interprocess communications, and since it is truly concurrent, it is much more scalable than the other options I just mentioned.
Phoenix is a flexible, clean, and easy to use framework with very little, if any, magic. LiveView lets you create things like SPAs, without the use of a front-end JS framework, using standard message passing. Phoenix is also scalable as hell.
One of my favorite things about Elixir and Phoenix is the ability to handle issues in a very atomic way. If you compare an Elixir cluster with a Kubernetes cluster, Elixir is able to handle an issue with tweezers where Kubernetes would handle the same issue with a bulldozer.
https://redmonk.com/sogrady/2021/08/05/language-rankings-6-2... https://www.tiobe.com/tiobe-index/ https://spectrum.ieee.org/top-programming-languages/
There are so many architectures, API approaches, frameworks, and languages these days. Almost any one could be argued as being better or worse off of different criteria.
Also Django being batteries included makes most comparisons very apples to oranges. Even comparing a basic CRUD web app / API in Django + DRF to Flask means pulling in like a dozen packages to help vs just the one with Django.
In the world of Python web frameworks specifically, FastAPI is really nice these days for a lot of REST API type use cases.
Number one is OpenCMS.
https://en.wikipedia.org/wiki/Genshi_(templating_language)
https://pythonhosted.org/Genshi/templates.html
https://genshi.readthedocs.io/en/latest/api/template/
Templating languages that use almost-but-not-quite-entirely-unlike-XML or -HTML don't work well with standard XML and HTML tools, because they don't recognize XML-or-HTML-with-some-magic-non-standard-syntax-sombody-nailed-on-to-the-side.
Even when I'm not using FastAPI now, I use Pydantic everywhere. Types in Python, while not nearly as useful as in a strongly typed language, are a dream come true.
The only gripe I have with Pydantic is that sometimes it has really opinionated type coercion that can get you in trouble sometimes. For instance, `Union[int, float]` will accept either an int or a float, sure, but it will always output an int. This isn't difficult to fix but may only realize it after having shot yourself in the foot.
Either is good if what you are building is something small and very focused or if you already know exactly what you want to build and want to have freedom making decisions about most aspects of the application.
But if you don't know yet what the product will be, a battery included framework like Django is very nice to get out the door quickly without having to worry too much how to structure the code, what library to use for x, etc.
Also, I think that Django is a good choice over Flask if you've never done anything in flask. But if you have an existing Flask site that can serve as a skeleton, I think it's just as good as Django as a starting point; details such as code structure and common library choice is then already handles - in fact just following https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial... will get you a lot of this too; Do you have any other batteries in mind? Ialso see Django having plenty "gotchas" (although it maybe have changed since I last used it). I definitely much prefer SQLAlchemy over DjangoORM.
But you need to spent at least once quite significant time following mega-tutorials, thinking about how to structure your application, what libraries to use for x, how to integrate them etc.
If you do that, it's great. But what I have seen in practice in various large flask app developed over years is, that in the very beginning people just jump in hacking away because it is so simple, just an app.py and a requirements.txt. Then over time they slap on the same thing Django has, but in a much less robust, hard to maintainable way. I'm guilty of the same, often simply not having time due to reality to really think things trough (the mega tutorial and similar didn't exist when I last started a Flask app).
If you're trying to write a CRUD app with a lot of admin screens, no, unless you're happy to roll your own auth, admin screens, mailer etc. (I use Go for building web apps like this and am very happy with it, but it's definitely more work thank something like Django or Rails).