IMO the main value of a framework like this isn't to save you time. That's what they advertise on the homepage, but I suspect that's just because it's an appealing concept to a lot of people. I think the real benefit is an increase in the chance that you build your app in a way that's sustainable. It's a pooling of experience and feedback on choices to create a whole that might not be flawlessly perfect for what you are building, but is likely worlds better than the disaster that usually occurs when you let the in house devs make too many choices.

> ossifies your platform into a fixed point in the hype cycle

Definitely true, but they have gone for some pretty established stuff here. The only ones I can see possibly being contentious in like 5 years or whatever timeline you want are Prisma and GraphQL, but even for those I'd bet on them still being sound choices for a long time. Also presumably the framework continues to develop (Rails 7 is a LOT different than Rails 1.), but that is a bit of a bet on it's adoption.

As a dev I get the appeal of something more flexible that lets you make your own choices, but I think that almost universally ends up being a curse rather than a blessing.

You make some great points here!

> I think the real benefit is an increase in the chance that you build your app in a way that's sustainable

Yes, indeed! We discuss "long-term maintainability" often in the project README and during interviews. This is one of the primary lessons Tom learned when building GitHub on Rails.

> ossifies your platform into a fixed point in the hype cycle

We are learning how to communicate these things better, but conventions, tight integration, and a "golden path" do not equate to lock-in of any kind.

If you read through other comments, you'll find a lot of examples where devs are using alternatives for the API as well as front-end libraries.