I was buying into your observation until I remembered that consider those other frameworks you mentioned to be bloatware
The node stack isn't that complicated, and the things that become complicated have preventative solutions (nvm to pin node versions and environments in isolation, pin packages to specific versions)
I can acknowledge that large applications often become unwieldy, not unique to JS but not helped by JS, but I still considered these to be system design problems. The way I develop my own applications is very streamlined to serve a lot of people and generate revenue in a 1-2 step funnel, and is very different from having to maintain some pre-revenue venture backed companies’ 30-step funnel because they want to data mine everyone and sell the promise of engagement to raise even more capital. The latter becomes difficult to juggle.
This isn't a "JS" problem. A consistent story/UX around common tasks isn't "bloatware". Queuing jobs on the backend, managing CRUD-ish stuff like native objects, multi-part file uploading (including CORS management, storage as blobs in the DB if you need it), user/auth management, sending mails, and so on really is just the basics.
Of course you can a la carte your own solution together every time, but the API at every different layer is almost guaranteed to be markedly different, the level of testing, support, size of the userbase/ecosystem is unknown, and every minute you spend debating those solutions, wiring them together, maybe creating abstractions so the API "feels" more native, etc is time you are *not* spending writing the actual application.
Finding other developers to work on your homegrown potpourri who won't screw up because they don't fundamentally understand object storage or DKIM constraints when sending mail or can't optimize a query better than the ORM or whatever will be difficult, and even harder if you want to find one who can do that AND nail down which parts of the underlying infrastructure (k8s, DNS, message queue, distributed k/v store, whatever) may or may not be responsible for a problem surfacing for 3% of your users is a harder and harder ask.
You're free to consider DRF and backend Rails and .NET and the rest to be "bloatware". I am not a web person in any way, so I don't have a horse in this race, but I am/was a backend/infrastructure person who has repeatedly had to help "full stack" web devs out of shooting themselves in the foot because they don't understand OIDC/SAML or service lookups in k8s or service meshing or DNS between geo-distributed clusters or how to write an INNER JOIN or you name it.
The "bloatware" lets web devs ("full stack" or not) concentrate on solving their actual problems instead of spending time and getting behind schedules re-inventing comprehensively solved wheels.
> The way I develop my own applications is very streamlined to serve a lot of people and generate revenue in a 1-2 step funnel
Would love to hear the opinions of those that have to maintain applications made "your way" after you leave. Hopefully you're documenting and testing it to the same level that Laravel, Rails and Django are, and hopefully the size of your company compensates for the lack of community around it when the problems show up and you're not there anymore.
The node stack isn't that complicated, and the things that become complicated have preventative solutions (nvm to pin node versions and environments in isolation, pin packages to specific versions)
I can acknowledge that large applications often become unwieldy, not unique to JS but not helped by JS, but I still considered these to be system design problems. The way I develop my own applications is very streamlined to serve a lot of people and generate revenue in a 1-2 step funnel, and is very different from having to maintain some pre-revenue venture backed companies’ 30-step funnel because they want to data mine everyone and sell the promise of engagement to raise even more capital. The latter becomes difficult to juggle.