This is actually part of why I created Nodewood [1], because every new Node project required pulling all that together, and every new SaaS idea I had had the same basic requirements (user management, subscription management, teams support, etc). Then I figured, if I found this useful, surely others would too, so I packaged it up and have had a few happy customers since then, who have helped me refine it, which feeds back into making my projects better, too.
To each his own, personally I stay away from Django and full fledged frameworks (context: I run a few small saas and launch new products frequently).
I find that having to dig to find out how things are done and trying to hack around the framework is the cause of bugs and frustrations.
I still manage two services based on Django and they're a continue cause of pain.
I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies.
Then evolving things is fairly easy, just a matter of skimming through the code.
> I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies.
Same.
The only time that I've gone away from this strategy is when I need to get other developers to buy-in to a framework (or hell just a "system of work"). In leadership roles, I've found that a highly-opinionated framework with lots of batteries included really helps keep people coloring inside the lines. For me anecdotally that's more important than having a low-dependency codebase that's very appropriately sized to the problem it's solving.
I've found it's way easier to dodge the inevitable "X way sucks" from my colleagues/subordinates by using "full framework" tools that I can pitch to non-technical management vs. a bespoke solution.
Batteries included frameworks solve people problems more than they do software problems.
---
Just want to reiterate that I absolutely agree with you and the only time I find tools like Django appropriate is when other developers need tooling that keeps them "in the lines," and/or when I'm expecting to have to pitch my solution to non-technical peers/leadership.
> I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies.
Me too. I don't use create-react-app or anything else to set up my Node.js/React/TypeScript/SWC projects. I install each package I need manually, and configure each item precisely how I want it (tsconfig.json, webpack.config.ts, .swcrc, even .eslintrc.json). Makes for a nice, lean project every time.
[1] - https://nodewood.com