Can someone explain in concrete terms this sense that ROR let’s people be highly productive?

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?

A web framework can be conceived as a selection of design choices already taken for you. The choices RoR does for you are extremely successful and very simple to understand, hence the name: you are developing "on rails" and as such you build things much faster.

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.

Simple litmus.

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.

So batteries included user signup auth flow?

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?

Django provides built in auth that is pretty great and extensible. OAuth/SAML and canned or customized registration flows are just a matter of adding the django-allauth module.

It isn't batteries included sign up. You have to select a 3rd party lib for that (a gem).

Yeah that was first thing that struck me about Rails, I had kept hearing "batteries included", then DHH suggests rolling your own auth? Always seemed a strange gap.

No. My point isn’t about using devise (I’m almost certain that’s what ChaGPT recommended). My point is that if you actually attempt to do both (code a simple app using ROR vs. another framework), you’ll find ROR just works 95% of the time. You might not like Ruby, or the syntax, or how a lot of what’s actually happening isn’t obvious. But to people who need to standup and build an MVP in a weekend there’s nothing that allows you to do it as fast.

Sane defaults for most (all?) aspects of the run-of-the-mill CRUD app, a.k.a. "convention over configuration". Helps focus development energy on solving the problem at hand as opposed to on bike shedding or being slowed down due to decision fatigue.

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.

And that is the sole reason many rails projects are still easily maintainable 10 years later. Even if they aren't your own

It makes doing the standard thing extremely easy. It also removes much of the repetition (problematically so at times!)

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.

If you want type system you can use PHP and Laravel.

You get built in support (and "couple of lines in config file" integrations with several popular options) for things like: auth, xsrf protection, database access, queues, logging, email, file storage, testing, cli tasks, and countless other things. There are other language ecosystems that have something comparable: notably Python with Django and PHP with Laravel. But most don't have anything nearly so complete.

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.

There's also the factor that while some of these things also exist sometimes in a more automated way than with Rails, the way Rails does them still seems to come out ahead.

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.

I really don’t follow this. It sounds like you are favouring what you are familiar with, and are back-solving a justification.

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.

Maybe I am? I'm not sure. But there is a philosophical difference here that has practical impacts. Django says "the model file is the source of truth". Rails says "the database is the source of truth". My gut feel is that the former creates a situation where you're more reliant on the quality of the abstraction, and putting the database entirely in the control of the framework is what you expect.

> 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.

> 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!

Implying that anyone touting the benefits of an established technology is against learning is just intellectually dishonest. Being able to tell what is and what is not worth looking further into is a mark of a seasoned expert in any field.

And most of the newer things are more or less the same thing as the old, except different. Sometimes that's good, sometimes it's not, and often it either depends or doesn't actually matter all that much. The trade-offs are often different, but it's of course fanatically denied by the zealots who claim that the trade-off doesn't even exists in the first place.

It's comical to say that Rails heyday is over when Remix hasn't even had a heyday.

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.

Isn't remix just dealing with view and controller of MVC? That looks difficult to compare with Rails

Okay, so Remix and some persistence layer. What’s the point?

> 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!

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.

> The lack of typing leads to way more maintenance

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

Are you willing to share examples?

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) 

Static typing isn't your answer.

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.

> a CRUD app, which covers the vast majority of business software.

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).