It makes doing the standard thing extremely easy. It also removes much of the repetition (problematically so at times!) For example working on a typescript nex

It makes doing the standard thing extremely easy. It also removes much of the repetition (problematically so at times!) For example working on a typescript next.js app, you'll have definitions in your Prisma schema, you'll have some form of model wrapper to load and save your model instances, and you'll have front end code to render your model instances. All of that is gone with rails. The default is that your schema defines the attributes of your model, and your model has no code. If you scaffold your controllers, your entire app consists of a set of routes, a schema file, some empty model files, a default controller, and generated views. I am admittedly a rails expert, but I could redo most of the typescript apps I've worked on in a few weeks as rails apps, but not so vice versa. That being said, these days I mostly choose Typescript because the long term sustainability of a flexible type system beats the short term productivity gains that rails builds in for you. But if I was building a prototype or wanted an MVP as fast as possible because I was bootstrapping with my own money, I would reach for rails. There's no better framework for discovering what your customer actually wants to pay for.