First of all, you should use the right tool for the job. Having said that, Rails kept giving me the icky feeling. What you gain in speed of development, you lose in performance and server costs and all sorts of crazy gem meta-magic.
My current middle-ground stack is Golang API (I use go-chi) + (LitElement front-end (web components) + Redux). I'm kinda happy, though my gripe is with Go sometimes, not the stack.
To the far right where people are complaining on: React + GraphQL, etc. Well, I think you went into the deep end, so rightfully you think about veering back left again. But hey, there's a middle ground that is more "standard's based".
I tend to describe my issues with Rails in a nutshell: it felt like everything was optimized for day 0 instead of day 30 or 300.
Devise was the ultimate example of this. `rails generate devise:install`. Instant authentication system with almost zero changes to your code base.
Yet now something as central and important as authentication is implemented outside of your application in some highly abstracted software. To do something as simple as figure out the name of the cookie it sets, you have to either dive into its internals or look at the actual cookie it sets instead of just reading code that should've existed in your code base.
Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code, not daisy chaining through a bunch of library code or hoping you cache-hit the library's FAQ so you don't have to deep dive.
There seems to be a lot of "why is there no Rails in {JS,Go,Rust,Clojure,...}" lately and it's no surprise to me why there isn't. The same reason Ember and Meteor never took off to the degree that React did.
There was some sort of "glue code just isn't that bad" renaissance.
> Rails was the first "language" I learned so I was its best case subject. It was able to indoctrinate me in the beauty of metaprogramming and things like that. Yet that still wasn't enough to keep the light from shining through the veneer when working on a real world projects where you just want to know how something works by reading application or glue code
I think the hidden magic is the worst part, but after a while I got pretty good at simply diving into various gems to see where the magic's happening (or failing to happen) and I don't mind that aspect now.
pry is an awesome tool. Put a `binding.pry` breakpoint in your code, do a `show-source Foo.borked_method` and explore from there.
Also, popular Rails-related gems tend to have good tests. I learned that those tests often demonstrate things that the docs don't.
Devise however is a good example how some parts of the rails ecosystem grow on complexity with your needs. I can start out with a bare devise system. But first you generate the views and handle them yourself and more often then not I end up overwriting some parts of devise controllers as well.
Sure it's kinda complex but their interface makes every form of extension rather easy.
My current middle-ground stack is Golang API (I use go-chi) + (LitElement front-end (web components) + Redux). I'm kinda happy, though my gripe is with Go sometimes, not the stack.
To the far right where people are complaining on: React + GraphQL, etc. Well, I think you went into the deep end, so rightfully you think about veering back left again. But hey, there's a middle ground that is more "standard's based".