Ruby on Rails: The Documentary [video]

    I am convinced this is a major contributor 
    to why so many Rails apps turn into an 
    unmaintainable mess over years.

I have two easy answers to why Rails apps turn into messes.

1. Any non-trivial app in any non-trivial language/framework usually becomes a mess eventually, given enough commits and developers

2. Rails (specifically, ActiveRecord) won't stop you from creating circular dependencies between models. This is easy to avoid, but it doesn't warn you about this or try to prevent it. So 99% of Rails apps have like, a User model that depends on (and is depended on by) most of the other models. This is far from a Rails- or ActiveRecord-specific issue though.

    Who measures onboarding in hours? 

You're right of course: that's a one-time cost. It's nice to optimize this but as you say, it's a one-time cost. Assuming a developer will spend multiple months or years working on the app, it would be better to optimize for the rest of that time.

However I think the standardization on MVC pays off here as well. For apps with multiple developer teams you may constantly be "onboarding" as you move between different areas of the app. And you can move forward with less bikeshedding.

    And that's not fine because AR (as an architecture 
    and as how Rails implements it) is very unfit for a 
    large category of applications

I agree, although I also feel strongly that AR is very good at getting out of the way and letting you just use raw SQL when you want.

So IMO/IME it works well for scenarios where some of your data is AR/ORM friendly and some isn't.

     Same with templates/views, JS, Caching, and many 
     more: you can -in theory- replace them with a 
     drop-in alternative

I can't agree. A lot of Rails projects use HAML instead of ERB and while I never set that up myself, I wasn't under the impression that it was a hassle.

Rails' caching backend has been seamless to swap between DB, Redis, in-process, and Memcached backends. As far as the caching "frontend", it's entirely optional, so I can't really imagine there is an obstacle to swapping it for something else? Like, you never have to use `Rails.cache`.

As for the JS side of things, I don't think I totally agree. There aren't drop-in alternatives, but you don't have to use Stimulus, and you can certainly use your own.

    This makes all Rails apps look alike.

This is good in a lot of ways. Less bikeshedding more building. But, also... I have to admit. I am bored to tears with Rails. Happy to be working in another language/framework for the moment and possibly forever.

> I can go an make it using Ruby on Rails all on my lonesome

Sure can. However I won't pretend it's the only framework you can do this with and be productive. I love Rails and Ruby but it has great competitors these days.

> Do I have to deal with JavaScript in any way?

Really depends on what you're doing but probably.

I’d love to see a Go REPL that can do nearly as many things as you can do with a Ruby REPL. It’s just not really possible I think. It could be doable with TS with the existing node REPL, but Ruby really is a huge driver behind why Rails console is as useful as it is.

> What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one

Which is funny because uncle bob cites this as a major downside to architecting code.

> so many Rails apps turn into an unmaintainable mess over years

Does this happen more often for Rails than for other frameworks?

There are many ways in which a Rails project can get derailed. But they seem not different from regular tech debt and I could imagine equivalent problems in other environments.

> AR (as an architecture and as how Rails implements it) is very unfit for a large category of applications

If you plan to build an application belonging to a category where AR is not a good fit, why use Rails?

I wouldn't claim that Rails is a good fit for all problems. Still, I'd say the structure and defaults of Rails are one of its strong benefits.

Or do you mean "application" as in "usage" - i.e. that over time you might notice a problem that's hard to solve with AR? Could you give an example? I'd guess you could use a different approach for a single task, or even move from Rails to a different tool if that becomes a big issue.