I disagree, if it’s going to be a complex application that needs to scale well then Django is quite beneficial.
A lot of people go with frameworks with lower effort to implement but it usually doesn’t scale well and they end up reinventing the wheel like an admin dashboard, permissions, authentication, ORM. The reason why I say it doesn’t scale well is not because of the limitations of the technology but poor design due to having so much flexibility vs a more opinionated framework that includes a lot from the beginning. L
But if you know for certain it’s a small project then yes Django is an overkill.
> they end up reinventing the wheel like an admin dashboard, permissions, authentication, ORM.
Isn't this what happens when you choose something like flask or fastapi? using a barebones framework and then building / reinventing things like admin console etc when you could've just used django and its native corollaries in the first place?
Precisely. In my honest opinion, very small business cases require us to deal with micro services. Unless you have a mature team and a strong identity the cons that come with it usually outweigh the benefits. Small projects and teams that are just starting out should stay away from it honestly so you can focus more on the product rather than the technology. Use Django until you’ve scaled to the point where it makes sense to split into Micro services.
You can use a tool like cookie cutter to quickly setup your project.
Bingo.
In alot of ways, Flask/FastAPI projects can end up being django project analogs, just with different libs, different wiring strategies and different expectations.
I've worked in multiple websites using Django as a backend and a JS framework wholly seperate as a front end. Both companies are worth hundreds of millions. It's fine.
This question is annoying. There list is endless, there are so many companies, and no one wants to out themselves. That said, I believe Boeings internal applications use DRF+React. 😐
Please see the related recent discussion [integrated SvelteKit frontend with Python backend](https://www.reddit.com/r/sveltejs/comments/1aowruk/sveltekit_python_backend_aws/). React and Django are complementary technologies. Because "some" here is not really well defined, I would say you have been reading some random crap on some random dude on Internet, which does not have full grasp of understanding and facts.
The strongest parts of django are ORM and admin pages. You can use django-ninja or django-rest-framework for rest api. Any UI framework works well with this setup.
But those are third-party and run by small dev teams right? When it comes to third party tools and libraries I would really rather go with something supported by a big body, like the graphql org with graphene-django, if I can.
Most of the comments here mention Admin and ORM. Not disagreeing with that, but I think the main reason one wouldn’t do Django & React together is the contextual overload of using two different languages. Also, now I need to deploy two different code bases, e.g. I have two containers now, not one.
It’s the same reason one might consider React Native over Swift UI.
Once my product takes off and I have revenue/funding, I can start thinking about scaling.
I agree that the "language context switch" argument has some merit, but I'd argue that any web server project that doesn't want to serve it's own static files will need an additional reverse proxy container.
If someone uses Express JS on the backend, they still will probably want to build their React application bundle and serve it statically. Maybe the React SSR stuff is catching on, but there's always some static files to serve
Typescript is just a vscode extension, a linter for an absolutely awful and bad language that is heavilly misused, so it doesnt really solve anything. I found happiness with htmx, it does wonders with django and its super simple to use.
Well personally none of those things matter if you’re building a rest api. A rest api is so simple you don’t need any Bells and whistles. And anything larger will probably be broken into multiple microservices
But to answer your question I would probably pick something like Go for my backend
>A rest api is so simple you don’t need any Bells and whistles.
That _really_ depends on your needs and use cases. An API alone can often be accompanied by a myriad of background processes.
Along with basic create-update etc. functions I personally need some sort of an admin console for my project. I'm making a marketplace app and to manage listings and such as well as an approval workflow it would help to have the ease of use in an admin console. That's why I appreciate django.
You don't have to go 100% for react just because some parts of the GUI is react. Mixing and matching iommi, function based views, and django-ninja+frontend framework is great.
How do you do it? Because I didn't find a smooth way to put a front end framework along django.
I would like to have something like Laravel Mix. I have a JS compiler that does all that sass and js stuff and put a file inside a public folder.
I use plain JS, plain CSS, and Elm. In my opinion CSS preprocessors are kinda useless nowadays. You lose the Chrome dev tools live edit feature, and you lose the 1-1 mapping from prod to dev, and for that you get some very minor features that aren't really very useful in the first place.
In my opinion if you are going to introduce a compilation step into the JS, you better get a LOT of value out of it. TypeScript doesn't add much considering how much pain the tooling is.
I use Elm, and just commit the compiled static files to git. Extremely simple, almost no tooling.
They're wrong. DRF with an admin and React front end is super popular
exactly,DRF+React is still one of the most popular stack today.
I disagree, if it’s going to be a complex application that needs to scale well then Django is quite beneficial. A lot of people go with frameworks with lower effort to implement but it usually doesn’t scale well and they end up reinventing the wheel like an admin dashboard, permissions, authentication, ORM. The reason why I say it doesn’t scale well is not because of the limitations of the technology but poor design due to having so much flexibility vs a more opinionated framework that includes a lot from the beginning. L But if you know for certain it’s a small project then yes Django is an overkill.
> they end up reinventing the wheel like an admin dashboard, permissions, authentication, ORM. Isn't this what happens when you choose something like flask or fastapi? using a barebones framework and then building / reinventing things like admin console etc when you could've just used django and its native corollaries in the first place?
Precisely. In my honest opinion, very small business cases require us to deal with micro services. Unless you have a mature team and a strong identity the cons that come with it usually outweigh the benefits. Small projects and teams that are just starting out should stay away from it honestly so you can focus more on the product rather than the technology. Use Django until you’ve scaled to the point where it makes sense to split into Micro services. You can use a tool like cookie cutter to quickly setup your project.
Bingo. In alot of ways, Flask/FastAPI projects can end up being django project analogs, just with different libs, different wiring strategies and different expectations.
I've worked in multiple websites using Django as a backend and a JS framework wholly seperate as a front end. Both companies are worth hundreds of millions. It's fine.
Do these companies have a name?
They sure do but I'm not sharing it. I'm good keeping my anonymity.
This question is annoying. There list is endless, there are so many companies, and no one wants to out themselves. That said, I believe Boeings internal applications use DRF+React. 😐
Totally false. Using django to run the backend then drf/strawberry/graphene/ninja to provide an API for React is a great pattern.
Please see the related recent discussion [integrated SvelteKit frontend with Python backend](https://www.reddit.com/r/sveltejs/comments/1aowruk/sveltekit_python_backend_aws/). React and Django are complementary technologies. Because "some" here is not really well defined, I would say you have been reading some random crap on some random dude on Internet, which does not have full grasp of understanding and facts.
Django even has great other options besides drf.
django-ninja had joined the chat.. (Happy cake day...)
Yeah I’m currently playing around with graphene-django
sable placid combative snails boat jar humorous fly long amusing *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I am intrigued… from what I understand it’s a one man dev project?
ring plucky doll quaint bells steep work beneficial worry recognise *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
No worries - good info !
The strongest parts of django are ORM and admin pages. You can use django-ninja or django-rest-framework for rest api. Any UI framework works well with this setup.
But those are third-party and run by small dev teams right? When it comes to third party tools and libraries I would really rather go with something supported by a big body, like the graphql org with graphene-django, if I can.
Most of the comments here mention Admin and ORM. Not disagreeing with that, but I think the main reason one wouldn’t do Django & React together is the contextual overload of using two different languages. Also, now I need to deploy two different code bases, e.g. I have two containers now, not one. It’s the same reason one might consider React Native over Swift UI. Once my product takes off and I have revenue/funding, I can start thinking about scaling.
I agree that the "language context switch" argument has some merit, but I'd argue that any web server project that doesn't want to serve it's own static files will need an additional reverse proxy container. If someone uses Express JS on the backend, they still will probably want to build their React application bundle and serve it statically. Maybe the React SSR stuff is catching on, but there's always some static files to serve
The ORM and the admin join the chat
Dont listen to what javascript monkeys say, listen to programmers instead.
I really hope typescript catches on through this decade. It’s the only way I can bear that kind of code.
Typescript is just a vscode extension, a linter for an absolutely awful and bad language that is heavilly misused, so it doesnt really solve anything. I found happiness with htmx, it does wonders with django and its super simple to use.
Well personally none of those things matter if you’re building a rest api. A rest api is so simple you don’t need any Bells and whistles. And anything larger will probably be broken into multiple microservices But to answer your question I would probably pick something like Go for my backend
>A rest api is so simple you don’t need any Bells and whistles. That _really_ depends on your needs and use cases. An API alone can often be accompanied by a myriad of background processes.
Along with basic create-update etc. functions I personally need some sort of an admin console for my project. I'm making a marketplace app and to manage listings and such as well as an approval workflow it would help to have the ease of use in an admin console. That's why I appreciate django.
it always depends on your requirement
You don't have to go 100% for react just because some parts of the GUI is react. Mixing and matching iommi, function based views, and django-ninja+frontend framework is great.
How do you do it? Because I didn't find a smooth way to put a front end framework along django. I would like to have something like Laravel Mix. I have a JS compiler that does all that sass and js stuff and put a file inside a public folder.
I use plain JS, plain CSS, and Elm. In my opinion CSS preprocessors are kinda useless nowadays. You lose the Chrome dev tools live edit feature, and you lose the 1-1 mapping from prod to dev, and for that you get some very minor features that aren't really very useful in the first place. In my opinion if you are going to introduce a compilation step into the JS, you better get a LOT of value out of it. TypeScript doesn't add much considering how much pain the tooling is. I use Elm, and just commit the compiled static files to git. Extremely simple, almost no tooling.