Batteries included frameworks+languages such as .NET or RoR or Springboot and similar was perhaps optimal choice 5 or 10 years back.
They balanced developer velocity over time and the learning curve needed to use them. Learning curve is important because steeper the curve, more experienced/skilled developers are needed and that translates to more $/hr cost of dev time. Simpler learning + with codegen tools was the pitch that RoR or .NET and all the frameworks inspired by them had in late 2000s.
Today it has shifted, to models like Firebase, Supabase or Hasura, NextJs or similar stacks using GraphQL, gRPC or occasionally RESTful APIs generation workflows instead of boilerplating tools .NET, Springboot et al provided . These frameworks come with hosting services and typically language agnostic, however TypeScript/ JavaScript is dominant choice in this model the developer now only focuses on business logic and not worry about organizing code or running it or about standard components like auth, so frontend teams are more likely to own this now and they will write TS/JS more often than not.
Even runtimes like Deno are getting into the game, instead of just writing the runtime code and make money with consulting, Deno wants to make DX for running code in their managed runtime so simple that a lot of small teams would just use that out of the box.
Until the app is at 10s of million scale - non NodeJS + unmanaged stacks won't make economic sense. People will build software in any system of course, because it is what they know not because it is the rational decision.
They balanced developer velocity over time and the learning curve needed to use them. Learning curve is important because steeper the curve, more experienced/skilled developers are needed and that translates to more $/hr cost of dev time. Simpler learning + with codegen tools was the pitch that RoR or .NET and all the frameworks inspired by them had in late 2000s.
Today it has shifted, to models like Firebase, Supabase or Hasura, NextJs or similar stacks using GraphQL, gRPC or occasionally RESTful APIs generation workflows instead of boilerplating tools .NET, Springboot et al provided . These frameworks come with hosting services and typically language agnostic, however TypeScript/ JavaScript is dominant choice in this model the developer now only focuses on business logic and not worry about organizing code or running it or about standard components like auth, so frontend teams are more likely to own this now and they will write TS/JS more often than not.
Even runtimes like Deno are getting into the game, instead of just writing the runtime code and make money with consulting, Deno wants to make DX for running code in their managed runtime so simple that a lot of small teams would just use that out of the box.
Until the app is at 10s of million scale - non NodeJS + unmanaged stacks won't make economic sense. People will build software in any system of course, because it is what they know not because it is the rational decision.