I still love Rails, but when your front end is mostly done using React (or something similar) you lose many of the advantages you previously had when almost your full stack was inside Ruby and Rails.
If I could scaffold CRUD interfaces with basic React components already integrated with the Rails API, and then start developing from there, I would become a much happier programmer :)
Trufflejs and Truffleruby are high performance engines implemented in top of JVM JIT. already trufflejs claims reasonable compatibility with nodejs.
It would be amazing to have a single runtime running a Ruby backend and a react front-end.
ASP.Net MVC has the same issue, but Microsoft headed that off by creating WebAPI, which is a better fit for the single page applications. Not that you couldn't do everything in WebAPI in MVC, but MVC was more of a website framework, while WebAPI has no rendering capabilities.
But when I need more (auth, orm, logging, etc.), I feel like I'm spending more time searching for and curating packages and then trying to get them integrated than I am actually building an application.
Rails (especially its API flag) has caught my attention recently because this becomes a non-issue - you pretty much just use what Rails has included.
Frameworks like Rails and Django cover a ton of functionality and gluing together and maintaining a set of packages to cover even a fraction of that functionality is a ton of work that's often for very little gain.
The goal is still the same - get up and running with an idea as fast as possible while not being cornered - scaling with the product. The FE has simply become where most of the effort and innovation is now. Rails will benefit from helping on that side of the coin.
I haven't kept up-to-date on Rails news, but I thought the Ember.js + Rails pairing was supposed to be their long term answer to that problem. (In that, "we support using Rails with everything, but Ember.js is the philosophically-similar, lowest-friction option"). Is that not happening anymore?
But it really is a one-way relationship. Rails itself now has webpack included as of 5.1+ and its implementation has integrations for React, Vue, Angular, and even Elm - but no Ember. I don't think the Rails core team is opposed to Ember insofar as they're just embracing what appear to be the most common or upcoming SPA frameworks/libs. Ember just never really broke out.
I myself would often spin up a rails api + react frontend.
With rails 5.1 and especially webpacker_react I've seen a possible new direction which combines the best of both worlds.
I think we could see something pretty exciting in this space soon if the integration of rails+react can tighten up a bit.
You lose a lot of that when you go away from Rails and start using a JS based front end. It's not that rails-api doesn't work - it works quite well. It just neutralizes, to some extent, the productivity gains you got from rails.
Here's a quote from the rails doctrine that sums it up nicely: "Rails specifically seeks to equip generalist individuals to make these full systems. Its purpose is not to segregate specialists into small niches and then require whole teams of such in order to build anything of enduring value."
What drives me nuts is when people write an SPA to stand in for a set of web forms, with almost no gain, and a huge increase in complexity (and drop in productivity). Sometimes I get the feeling people on HN are working on more cutting edge stuff. Truth is, an awful lot of business software really is a series of web forms persisted to a database. I do think you can get these apps done with half the staff, twice as fast, with better code clarity, stability, and test coverage, by sticking with Rails. In fact, the slowdown in Rails activity is probably a good indication that you should use it for these apps, not that you shouldn't!
Unless, well, you do have to. Unfortunately, my guess is that a lot of people writing this code aren't doing it because they're on one of those projects that actually really needs it (or benefits substantially from it). We have to do this because our orgs require it, a software architect said it should be used, or because we know we won't get hired for our next gig without this experience, so we bring it into our current project even if it isn't helpful.