What I've gathered, over the years, is that the people who dislike Rails because it makes a lot of decisions for them think they're just too cool for that. It insults their programming ability. OK, I can see that. So, go ahead; have it your way. But while you're still writing thousands of lines of boilerplate in both the front and back ends, and getting your types sorted out, I'm done with my app, and moving on to the next one.
Been working with Rails close to a decade now. I've built several, non-trivial products using Rails for the API, by myself. What I and my coworkers dislike about Rails is the sheer amount of magic. Oh and concerns, let's not forget that pattern.
Rails is amazing at standing up a CRUD app (really API) in a matter of minutes. I can have a basic CRUD app with authentication, authorization, API, caching, background jobs, local development (docker compose), production in any cloud / k8s and CI/CD done within a day. Adding business logic that's well tested is simple.
Once the app starts to get serious usage, needs to integrate with complex enterprise systems, handle huge loads of data, etc. it becomes necessary to step away from Rails-way of doing things. All of a sudden you can't push more into Sidekiq cause of how much it impacts the DB via ORM loading. Now you're writing custom SQL. It's not all that hard to do in Rails, but at that point, you're writing Ruby and not using Rails magic any more.
Your dismissive comment does not address the realities of building a solution that goes beyond CRUD. It ignores the many levels of experience present on a team or the amount of technical debt one accrues while building a non-trivial production system.
While it doesn't take much experience to get started with Rails or to get a good amount of progress on a product, it takes skill to keep the technical debt under control. Or to make good decisions about architecture. Or to understand which parts of the system to optimize. It requires actual experience building web solutions without the crutch of a framework to know when to ignore Rails and when to double-down on it.
And your dismissive comment attempts to imply that I haven't done "real" work with Rails, but I can assure you that, with 25 years of professional development experience, 13 of which using Rails as my primary stack, I have integrated with many legacy systems, and I find Rails works really well for that, actually. And, while I admit there's usually a place or two in an application to have to "shell out" to hand-coded SQL -- and even more tellingly -- that's usually some of the most-important functions of the application, it's hardly a reason to throw the baby out with the bathwater.
Making good architectural choices for complex problems/solutions is difficult with any framework or language though. What I like with rails is that it's easy to work on the easy parts, but it doesn't stop you to make more complex choices on the difficult parts.
class Assignment < ApplicationRecord
belongs_to :project
belongs_to :release
accepts_nested_attributes_for :release, reject_if: :all_blank, allow_destroy: true
end
Would represent several hundred lines in Java and Angular.
Do you really need to see every line of code required to explain every object and how they relate to each other to the various compilers in your application?
Ok I'll bite - what else have you tried and what made rails so more productive?
My experience with big web frameworks - though I can't speak to rails in particular - is that everything is sunshine and rainbows until I veer a little bit off the standard path (or rail) and then it all becomes a nightmare. Where as if I'd done a little bit more myself up front, the thing is more resilient and can easily go where I want it.
Really happy to be wrong here, would love it if rails became my secret weapon. I'm a big ruby fan. But I'm sceptical.
Rails has a ton of escape hatches when you want to make a different choice from the defaults, just as long as you’re writing a web app or HTTP API. The challenges I’ve run into in the Rails ecosystem more revolve around 3rd-party extensions making assumptions about how my app works and not being as flexible as the framework.
I've done web apps with PHP, ASP.NET, .NET Core, and, unfortunately, Java/Angular. The only thing that really hangs up .NET for web apps these days is its reliance on Entity Framework. What I've finally concluded is that I'm glad to tradeoff speed and strong typing of .NET/EF for the flexibility and "omakase" of Rails/AR. Obviously, YMMV.
