David Heinemeier Hansson (DHH) pulled Rails out of Basecamp in 2004 and has spent the years since arguing for a particular way to build software: small teams, one codebase, strong defaults, and code that is a pleasure to read. These are the ideas that shape it.
This page is our reading of his ideas, in our own words. His own statement of them is The Rails Doctrine, which is worth reading in full.
Rails inherits this straight from Matz and Ruby. A framework should make the common work feel good, because people who enjoy their tools build better things with them, and stay long enough to maintain them.
Most decisions in a web app don't need to be made more than once. Rails makes them for you: a
Post model maps to a posts table, lives in app/models/post.rb, and is
served by a PostsController. Because everyone follows the same layout, you can open any Rails app
and find your way around, and nothing needs wiring up by hand.
class Post < ApplicationRecord
has_many :comments
endThat one line gives you the table, the foreign key and the query methods, with zero configuration.
Like a chef's tasting menu, Rails ships a full stack chosen to work together: database layer, views, jobs, mail, caching, testing, deployment. You can swap pieces out, but the default is a curated whole rather than a pile of parts you have to assemble and keep in tune yourself.
Splitting an app into many services adds network calls, deployments and failure modes. For most teams, one well-organized application is simpler to build, change and run. Split only when a real, measured need forces it.
Code is read far more than it is written, so how it reads matters. Rails favours expressive APIs like
2.days.ago and validates :title, presence: true because they say what they mean.
Rails trusts programmers with powerful tools, such as reopening classes and metaprogramming, rather than locking them away. The trade is responsibility: use the sharp tool when it makes code clearer, not to show off.
A single framework that covers the whole stack lets a small team, or one person, build a complete product. Recent Rails leans further into this: Hotwire for interactive pages with little JavaScript, and built-in tools for jobs, caching and deployment so you need fewer outside services.
Rails changes, sometimes in ways that require work to upgrade. That is the cost of staying current. Upgrading in small, regular steps is far cheaper than freezing an app on an old version until it can't move.
You don't have to agree with every opinion to use Rails. Plenty of people swap in RSpec, other front-end tools or different patterns, and the community makes room for them.
Conventions are instructions a model already knows. In a Rails app that follows them, an agent can guess where a file lives and what it should be called, and be right. That is why our AGENTS.md asks agents to follow the framework's defaults before inventing their own.
Provided as is, for information only, with no warranty and no liability. Not legal or professional advice. Security and radio material is for authorized, lawful use only. Full disclaimer.
Visits are logged on our own server: IP address, browser and device details, and pages viewed. We use them to understand traffic and spot attacks, and never share or sell them.