The productivity of Rails absolutely trounces JS-framework-de-jour in my experience. It’s almost certainly the framework I would be recommending for a CRUD app, which covers the vast majority of business software.
Rails is certainly productive in the early days of building something, because so much of what you need is already built. But as time goes on that productivity edge vanishes.
It's far easier to build slick modern UIs in other frameworks, and there are now Typescript frameworks (e.g. Remix) where you can use the same types (and get type safety, IDE auto-completion, IDE warnings, etc.) across the entire stack (it's amazing!) The fact you don't need import statements to use code across a Rails app feels like a blessing at the start, but as the codebase grows, it can become a nightmare trying to figure out where something is defined or how something has been altered. The lack of typing leads to way more maintenance - I have Rails apps that are years old and I still get regular error notifications (method doesn't exist on nil is a particularly common one) whereas I have Typescript apps that I built a few months ago that have never triggered an error ever. The list goes on.
The world turns, frameworks come and go, and the heyday of Rails is over. I don't know why this is a problem for people, quite frankly. If you didn't want to learn new things, then being a software developer wasn't the right career choice, and you were probably told that on day 1!
The half life of these backend frameworks is pretty short. Rails has built a lot of billion dollar businesses. Wake me up when Remix does that.
Nobody asked your opinion on who could be a software developer. Stop being a gate keeper and let people make their choice on what technology works for them.
Surely you are joking, maintenance is THE downside of the node ecosystem if I had to pick the biggest one.
At work we have a roughly 50/50 Rails/React app but on the maintenance side though it's 20% Rails / 80% React. The package churn in the node ecosystem is absolutely insane and just keeping up with it is almost a full time job. And to add even more to the maintenance burden, on the node world the packages are rarely tested well (if at all), you are building on moving sand and theoretically you would need even more testing than in the Rails part to compensate that.
I'm not saying Rails has the best maintenance story, far from it but it's not nearly as bad as anything JS based.
The fact you don't need import statements to use code
across a Rails app feels like a blessing at the start,
but as the codebase grows, it can become a nightmare
trying to figure out where something is defined or
how something has been altered
I was a Rails developer for a long time and it certainly has its pitfalls. But I don't feel that this was one of them and I certainly don't think that explicit imports would solve this problem for you.
Do you have a bunch of global variables (or external data stores like Redis caches etc) being modified by only-God-knows-what? I don't know how explicit imports would solve that. I'm not sure how "import Foo" versus "Foo=42" is going to help you, unless perhaps if you've given your global thing an identifier that is impossible to grep for.
You can also have the behavior you want in Rails, anyway! You have full control over autoloads! Put your code in a non-autoloaded folder. Boom, now you have to explicitly `require` it before using it.
The lack of typing leads to way more maintenance - I
have Rails apps that are years old and I still get
regular error notifications (method doesn't exist on
nil is a particularly common one)
Unexpected nils/nulls/whatever are a runtime error, and are almost always caused by some external resource (typically, the results of a database query or maybe an external API call) being unexpectedly nil, coupled with a sloppy lack of proper exception handling.
I don't care how iron-clad your language's type system is, it won't magically help you handle unexpected external runtime data or make up for a lack of exception handling and/or testing.
It’s hard for me to imagine what could be so much more productive than any number of other languages//frameworks.
What does ROR actually have that the next technology doesn’t?
This was very true more than a decade ago before the Node revolution adn when the alternatives where Struts or Spring MVC in Java, or Zope with Python. Fast forward to 2023, I would say that other platforms have caught up a lot, but my personal opinion is that Rails still has the edge.
AFAICT, one has to go with the conventions as far as possible. Straying off the beaten path can lead one to lose time fighting the framework.
Ask ChatGPT to create a basic Rails app that has authentication, routing, and a dashboard page only accessible after login.
Then ask ChatGPT to do the same thing, but with any other language/framework.
I can see why that would get you going quick. Certainly Django doesn’t provide that. Most other frameworks I know don’t provide that.
I know I’m dead sick of building my 50th user signup flow.
Having said that, once it’s built that’s done. What’s the ongoing productivity gain beyond that?
For example working on a typescript next.js app, you'll have definitions in your Prisma schema, you'll have some form of model wrapper to load and save your model instances, and you'll have front end code to render your model instances.
All of that is gone with rails. The default is that your schema defines the attributes of your model, and your model has no code. If you scaffold your controllers, your entire app consists of a set of routes, a schema file, some empty model files, a default controller, and generated views.
I am admittedly a rails expert, but I could redo most of the typescript apps I've worked on in a few weeks as rails apps, but not so vice versa.
That being said, these days I mostly choose Typescript because the long term sustainability of a flexible type system beats the short term productivity gains that rails builds in for you.
But if I was building a prototype or wanted an MVP as fast as possible because I was bootstrapping with my own money, I would reach for rails. There's no better framework for discovering what your customer actually wants to pay for.
Of course all of these things are achievable in other languages/frameworks. But they require quite a bit more setup, and those setups end up being much less standardised across projects. IMO this doesn't tend to make too much difference over the long term, but something like rails definitely makes it quicker to get started.
The specific example I've got in mind is database migrations. The default with Rails is that you write them yourself, and the model then interpolates what it finds in the database at runtime. With Django, the pattern (again, by default - but defaults matter) is that you change the model and the migrations are generated automatically. The model is the source of truth.
I haven't figured out exactly why yet, but the way Rails splits the responsibilities seems to be much cleaner to me. I'm always slightly uncertain about what Django is going to do. With Rails the database feels closer to the surface, rather than something handed entirely over to the framework.
You’re essentially describing a declarative migration system which on the face of it sounds reasonable. It sounds like you’re dismissing it on this property. After all, the underlying DDL is…declarative, for the initial tables, anyway.
When you create a new migration, Django will tell you which actions it’s written into the migration file, i.e. the actions it thinks need to be taken to get from A to B. I don’t see anything opaque about that?
You can also look at the migration file yourself. It’s entirely readable. You could even write your own if you wanted to.
The Rails community seems to still be carrying a very peculiar compete-with-Django attitude from back in the heyday. I see it all the time here. It’s ridiculous.
> When you create a new migration, Django will tell you which actions it’s written into the migration file
Yes, that's the point. With Rails, I tell it what to do, and if my start point is a specific change I want to make to the database, that's an easier starting point than having to first translate the problem from the database into the model, so that the abstraction can convert it back again, for me to double-check.
Saying that most business applications would be CRUD applications doesn't reflect the reality very well. While technically everything could be broken down to CRUD operations, this term becomes pointless once a relevant amount of business logic is needed to perform the final (database) insert, update or delete. There is a reason why Domain-Driven Design exists (and RoR is, by the way, not the best framework to apply it).