Ruby on Rails: Why It Still Runs the World
Rails turned 20 and it still ships faster than most modern frameworks. Convention over configuration is not a slogan; it is an engineering decision that eliminates an entire category of bikeshedding.
Ruby on Rails
Why It Still Runs the World
Convention Over Configuration Is Not a Compromise:
Every Rails project looks the same. Models go in app/models. Controllers go in app/controllers. Views go in app/views. Database schemas live in db/schema.rb. Migrations live in db/migrate with timestamps. This is not a limitation; it is the entire point. When a new engineer joins a Rails project, they know where everything is before they read a single line of code. When we onboard a contractor to help with a client project, they are productive within hours, not days. The framework makes hundreds of decisions for you so your team can focus on the decisions that actually matter: business logic.
Compare this to a typical Node.js or Go project where every team invents their own directory structure, their own ORM conventions, their own routing patterns. We have seen Node projects where finding a route handler requires grepping through six directories. Rails does not have this problem because there is exactly one place each piece of code belongs. You can argue about whether the conventions are optimal. You cannot argue with the velocity they produce.
ActiveRecord and the Monolith-First Architecture:
ActiveRecord is the most productive ORM in any language. Defining a User model means you automatically get User.find, User.where, User.create, associations, validations, callbacks, and scopes. Migrations are version-controlled schema changes that run forward and backward. rails db:migrate applies them. rails db:rollback undoes them. You can look at db/schema.rb and see your entire database structure in one file. This is not magic. This is twenty years of refining the interface between application code and relational databases.
Rails advocates a monolith-first architecture, and we agree. Start with a single Rails application that handles everything: web UI, API endpoints, background jobs with Sidekiq, email delivery with Action Mailer. When specific parts of the system need to scale independently, extract them. But do not start with microservices. We have watched startups spend six months building Kubernetes-orchestrated microservices for an application that serves 200 requests per day. A single Rails server on a $20 EC2 instance would have handled that load and shipped three months earlier.
When Rails Is the Right Choice:
Rails excels at content-heavy web applications, admin dashboards, internal tools, CRUD-heavy business applications, and rapid prototyping where time-to-market matters more than marginal performance differences. Shopify runs on Rails. GitHub ran on Rails for years. Basecamp, Hey, Cookpad, Airbnb's original platform: all Rails. These are not small applications. They are platforms processing millions of requests. Rails scales when you know how to scale it.
We use Rails at MajorLinkx for CypherLearning integrations and internal tooling. The productivity advantage is not abstract. A feature that takes two days in Rails takes a week in most other frameworks because half the plumbing already exists. Generators scaffold models, controllers, and views in seconds. The asset pipeline handles JavaScript and CSS compilation. Action Cable provides WebSocket support out of the box. Rails is not trendy. It is productive, and production does not care about trends.
When Rails Is Not the Right Choice:
Rails is not the answer for everything. Real-time data processing at scale, compute-intensive workloads, systems requiring sub-millisecond latency, or applications where memory footprint is a hard constraint: these are cases where Go, Rust, or Elixir are better fits. Rails' memory consumption per process is higher than compiled languages, and Ruby's Global Interpreter Lock means CPU-bound work does not parallelize well within a single process. If you need to process 50,000 concurrent WebSocket connections, Rails can do it with AnyCable, but Go handles it natively.
The honest assessment is this: pick Rails when developer productivity and time-to-market are your primary constraints. Pick something else when runtime performance and concurrency are your primary constraints. Most business applications fall into the first category, which is why Rails keeps winning despite every year being declared the year it finally dies. Twenty years in and the framework is still shipping faster than the alternatives.