It does, but at this point it’s like saying that JavaScript is DOM even though you can use it outside a web browser. Or it’s like blaming Python for TensorFlow. Like, yes, Rails is a use case for Ruby, and a popular one, but not the only one.
The point is valid though. Yes Rails is particularly bad, but I've been working with Ruby for ~15 years now, and plenty of non-rails codebases in that time. The metaprogramming and implicitness runs deep in most of the community, it's common to find highly magic and hidden implementations in Ruby generally.
I often find the sort of over-the-top implementations you describe in gems that were written by Rails users. Since other frameworks and vanilla are not super uncommon, it's fairly normal to make your gem that you envisioned being used within a Rails app not dependent on Rails. If those developers read too much Rails framework code (or toxic blog posts from DHH) and got the wrong idea, then it's not surprising they imitated what they thought was the way to do things.
Agreed. Ruby is not Rails in so many ways, even on philosophical grounds. Rails is full of magic, implicitness, and conventions, which enables a great deal of very speedy development but also becomes† a minefield if you steer away from The Way; while plain Ruby is very explicit and in plain sight, there's no magic. It's a blank page, an open field, it's raw material for creative ground.
Rack or Minitest for example are very Ruby. RSpec on the other hand is full of Railsy magic, just yesterday testing some threaded stuff I was bit by `let` because it has concurrency consequences, and the magic becomes darkness as you have to look behind the curtain and beat it into submission in roundabout ways that obscure the thing you're actually doing.
> also becomes† a minefield if you steer away from The Way
Reminds me of Angular vs React-- In my opinion it's much easier to get immediately productive in React, but it's very easy to produce a rats nest over time if you aren't experienced with the framework. Versus Angular which has a lot of upfront learning curve, but it's prescribed structure makes it fairly easy to scale out the app over time.
Rails is definitely more like React in this respect. It turns out you can absolutely color outside the lines and still enjoy the speediness, but it's not something that I experienced devs should try to do without making a huge mess.
If the DOM APIs were full of really bad patterns, or used a bad language feature, then the blame would partially lie on Javascript for promoting those patterns or not having better alternatives.