I think from a business perspective, the hiring pool for Rails is small and younger engineers don’t have an interest in learning Rails (check recent university hackathons). It takes a decently long time (2-3+ months) to upskill a non-ruby engineer to be productive in Rails (although this is dampened by AI tools these days) and many senior non-ruby engineers aren’t interested in Rails jobs whereas you can get an Node or Java engineer to come to your Go shop and vice versa. Rails can also be hard to debug if you work in a multi-language shop, you can’t map your understanding of Java or Typescript over to a Rails codebase and be able to find your way around.

All that being said I still use (and like) Rails, currently comparing Phoenix/Elixir to Rails 8 in a side project. But I use typescript w/ Node and Bun in my day job.

If you "screw up and succeed" by gaining many users/customers, any Ruby or Python framework provides orders of magnitude fewer requests-per-second on the same VM or hardware than a comparable solution deployed with node.js, go, Java, C# (Including DotNet Core on Linux), or rust. And this will quickly ballon your cloud compute costs to keep up.

The biggest downfall in my experience has been it can be a massive pain to find out where a method is defined in a huge codebase, especially with all the crazy ways in which one can declare methods. You can spend a non-trivial amount of time just trying to find the definition for a method.

Downside? … One day when you’re successful and have large numbers of customers, you might need to migrate aspects of your stack to something else.

I tried rails when it was pre version 1 and the early stages. I always felt like rails is very powerful and lots of things feel like magic until you come to a point where you want something that isnt implemented in that way.

You can prototype stuff very fast with rails and its a mighty tool in the right hands.

Downsides:

Rails is a sharp knife. There is Rails way to do things. You may of course choose to do them differently (this is a contrast with other toolkits that fight this hard), but you are going to have to understand the system well to make that anything but a giant hassle.

With rails, the way it scales is statelessness. You have to map the front end actions to individual endpoints on the server. This works seamlessly for crud stuff (create a thing; edit a thing; delete a thing; list those things). For other use cases it works less seamlessly. NB: it works seamlessly for nested "things" too.

Complex multi-step flows are a pain point. eg you want to build data structures over time where between actions on the server (and remember, you must serialize everything you wish to save between each action), you have incomplete state. Concretely: an onboarding flow which sets up 3 different things in sequence with a decision tree is going to be somewhat unpleasant.

You must keep most state on the server and limit FE state. Hotwire works extremely well but the FE must be structured to make hotwire work well.

I've actually found it to work pretty well with individual pages build in react. My default is to build everything with hotwire and, when the FE gets too complex, to fall back to react.

Rails is nobody's idea of a fast system. You can make it perform more than well enough, but fast it is not.

Upsides, my take: it is the best tool to build websites. The whole thing is built by developers for developers. DX and niceness of tools are valued by the community. Contrast with eg the terrible standard lib that other languages (hi, js) have. Testing is by far the most pleasant I've used, with liberal support for mocking rather than having to do DI. For eg things like [logic, api calls, logic, api calls, logic, db calls] it works incredibly well. It is not the most popular toolkit and it's not react, so that can count against you in hiring.

Did you miscalibrate your time machine and just make it back?

You have to be comfortable with the ORM in every layer - it lives inside your domain models, rather than in another layer shuffling DTO's to presentation/rendering. It also makes it easy to avoid separation of concerns and stuff all your logic in a controller method and call it a day.

The upsides is that by not trying to hide the database and pretend it doesn't exist you can avoid a whole class of work (and the safety abstractions provided) and be incredibly productive if the requirements align.

You have to program it using Ruby which is not a good language. It's slow. It doesn't have good static type annotations (as far as I can tell the community "gets it" even less than in Python).

Rails also uses way too much magic to dynamically construct identifiers and do control flow.

The over-use of magic and the under-use of static types makes it extraordinarily difficult to navigate Rails codebases. It's one of those things where you have to understand the entire codebase to be able to find anything. Tractable for tiny projects. For large projects it's a disaster.

Rails is a bad choice (as is Ruby).

My favourite web framework at the moment is Deno's Fresh. You get the pleasure of TSX but it's based around easy SSR rather than complex state management and hooks. Plus because it's Deno it's trivial to set up.