When Rails-way does not work anymore?

"The AI adoption among developers is not as rapid as you expected - the benefits are obvious. Still, the developers do not seem to be taking advantage of it, and the pace of introducing new changes has not increased much over the last few months."

The benefits are so obvious that they preclude any supporting evidence or research. They are more or less axiomatic/dogma.

Wild take - maybe the pace of introducing new changes has not increased _because_ the "benefits" are not so obvious after all.

All of the growing pains listed in the article can be observed in pretty much any framework in any language. Certain patterns and designs might be more present in some environments than others but I’m yet to see a framework that still guides you at tens or hundreds of kLOC. I don’t see how Rails is an issue here. If anything, I’ve always liked how the Ruby/Rails community discusses how to get the best of their framework and object-orientation. Are there monstrous, hard to evolve Rails app? Yes but the same can be said about Spring, .NET, Django and many others.

The author uses how models are suggested to be used "the rails way" as an example for why it doesn't work anymore, talking about business logic in the models.

But in every framework I've used, the suggested way isn't how a technology is used in reality, in production. The tutorials are almost like a different framework entirely. Years ago as an Android dev the difference was shocking between what tutorials taught you and what was done in practice.

This doesn't technically detract from the author's point but it makes it moot - you just build in the current best practice way or the way that suits your needs, and that's how it often is with languages and frameworks.

Maybe that mismatch between how people are taught initially, or how the framework is intended to be used, is an inefficiency, in which case those who design frameworks should take note.

In the case of Rails I think "the rails way" is appropriate for certain style of apps, and not so much for Shopify etc scale apps.

Most of the article deals with topic orthogonal to stack tech choices. It’s barely about the Rails Way at all. That said, I do think the Rails Guide could have a section on scaling philosophy and tradeoffs.

I've seen several Rails apps where all the mentioned signs happened, and all of them were apps that didn't use the Rails-Way.

And this is accelerated by design patterns that blow up the amount of components used. Then there's the problematic gems such as Trailblazer that cause more problems than they solve, while being difficult for both humans and AIs alike.

Reminds me of the quote from Fred Brooks: "Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious".

Service Objects et al are flowcharts. Rails-way is tables.

What do you mean? The whole point of Ruby on Rails is the rails way? Also the problems you are describing are not new and the community settled on adding some sort of service layer

https://shopify.engineering/shopify-monolith http://sporto.github.com/blog/2012/11/15/a-pattern-for-servi...

HTTP 406 "Your browser is not supported" (whatever that means) seems like a misuse of a response code, no?

In any case, I would not advise anyone to take any advice in web-development from someone who does this.

P.S. My browser is quite fine, release age wise, not that it should matter.

i can't make out the point of this article.