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.