Ruby on Rails
Ruby on Rails, answered
The questions people ask next
Ruby on Rails documentation, source and downloads
Where the real Ruby on Rails material lives: the guides, the API documentation, the source on GitHub, what became of the wiki, what installing Rails actually means in 2026, and who created it.
A Ruby on Rails example application
What a real Rails application is made of, walked file by file: models, controllers, routes, views, jobs, schema and tests, with the parts that are Rails itself kept separate from the parts somebody decided.
Is Ruby on Rails hard to learn
How hard Rails is depends on where you are starting from, so this answers it three ways, names the parts that are genuinely difficult rather than merely unfamiliar, and says which tutorials are still current in 2026.
Does anybody still use Ruby on Rails?
Who runs Ruby on Rails in production in 2026, what shipped in Rails 8.0 and 8.1, and where the framework genuinely lost ground. Named companies, release dates and survey numbers rather than reassurance.
Ruby on Rails vs JavaScript
Rails or a JavaScript stack for your next product: moving parts, the frontend story, hiring, and where each one is genuinely faster. A verdict, and what would change it. Written in 2026.
Twelve questions get attached to the name "Ruby on Rails" every time somebody searches it. This page answers two of them and points at the pages that answer the rest, and every answer here is written against Rails 8.1 in 2026 rather than against the framework's reputation.
What Ruby on Rails is used for
Rails builds the entire server side of a web application, and most of the client side with it. One application handles the database schema and queries, the HTML sent to the browser, the forms coming back, the emails, the background jobs, the file uploads, the WebSocket connections and the JSON API, without those being seven separate services with seven deployments.
That breadth is the point rather than a side effect. A Rails application has one repository, one test suite and one deploy, so a team of two can carry a product that would otherwise need a backend team and a frontend team to agree on a contract before either can ship.
What it is used for in practice is products, not pages. Shopify runs on Rails. GitHub runs on Rails. Basecamp, where it was extracted from, still does. What those have in common is not size, it is that a logged-in user does things that change data, which is exactly the shape Rails is built around.
Where it is the wrong tool: a marketing site with no accounts, where a static generator is simpler and cheaper; a service whose whole job is one CPU-bound computation, where Ruby's speed is the constraint that matters; and a team that wants to choose every component itself, because Rails has already chosen most of them.
Backend or frontend
Backend, and the question keeps being asked because the honest answer has a second half.
Rails is a server-side framework. It runs on your server, talks to your database, and the browser never executes it. In the sense the question is usually meant, that settles it.
The second half is that Rails also produces the frontend, which is why nobody is quite satisfied with "backend". It renders the HTML itself, and since Rails 7 it ships Hotwire, its own answer to interactivity: Turbo swaps fragments of the page over the wire, and Stimulus attaches small behaviours to markup the server already sent. So a Rails application usually has no separate frontend application, no second build, and no API contract between two teams.
You can still put React or Vue in front of it and use Rails as a JSON API only, and plenty of teams do. Ruby on Rails vs JavaScript works through that choice properly, because it is the real decision hiding behind this question.
The rest of what people ask
Four questions get asked about the framework itself, and they are the ones worth a page each.
Whether anybody still uses it is the one people mean most seriously, and Does anybody still use Ruby on Rails answers it with names, release dates and what shipped in the last two years rather than with reassurance.
How hard it is to learn depends entirely on what you already know, which is why Is Ruby on Rails hard to learn splits the answer by where you are starting from, and says which parts genuinely are hard.
Whether to pick it over a JavaScript stack is Ruby on Rails vs JavaScript, which takes a position and names what would change it.
Where the real sources are
Five of the eight things people search alongside the name are looking for the same thing: the official material. The documentation, the source on GitHub, the old wiki, the download, and who created it.
Ruby on Rails documentation, source and downloads is the map: which of those five is current, which is a historical artefact, and which one to open for which kind of question. It links out to each, because sending you to the real thing is the only useful answer to a navigational question.
Seeing one
The remaining search is for an example, and it is the most reasonable request on the list: reading about a framework tells you far less than reading an application written in it. A Ruby on Rails example application walks a real one, feature by feature, and is honest about which parts of it are Rails and which parts are decisions somebody made on top of Rails.