Ruby on Rails: The Documentary [video]

Original Article ↗ Hacker News Discussion ↗

A new documentary on Ruby on Rails has revived interest in the framework and prompted reflection on its impact: many praise Rails for its strong conventions, cohesive “one big framework” approach, and extraordinary productivity for building full‑stack web apps, even decades after its debut. Commenters contrast Rails with the more fragmented JavaScript ecosystem and other frameworks like Django, Laravel, Phoenix, Spring, and ASP.NET, debating trade-offs in performance, long-term maintainability, and architectural flexibility. While some criticize Rails’ tight coupling, ActiveRecord, and gem sprawl for making large systems hard to evolve, others argue that its consistency, tooling, and evolving features (Hotwire, Turbo, Solid Queue/Cache, etc.) still make it a top choice for quickly delivering and scaling real-world products.

Overall reaction to the documentary

  • Many found it fun, nostalgic, and motivating; some said it rekindled interest in Rails or made them want to try it for the first time.
  • A few felt it was too short and surface-level, more like light hero-worship than a deep history, and wished it covered struggles and long-term evolution in more detail.
  • Several noted omissions of early community figures and resources that were influential to them.

Rails’ core strengths

  • Strong conventions and a consistent app structure were widely praised: most Rails apps “look the same,” which eases onboarding, reduces bikeshedding, and helps agencies/consultants jump into unfamiliar codebases quickly.
  • High productivity is a recurring theme: people report being multiple times faster than in Node, Go, or previous Python/JS stacks, especially for CRUD-style web apps and prototypes.
  • Hotwire/Turbo, Turbo Native, Strada, and integrated tooling (e.g., Solid Cache/Queue, Kamal) are seen as reinforcing Rails as a cohesive full-stack solution with less JavaScript.

Comparisons with other ecosystems

  • JS/Node is criticized for lack of a “one framework” with strong conventions; Next.js is seen by some as closest but still front-end centric. Other JS full‑stack attempts (Adonis, Remix, SvelteKit, etc.) are mentioned but viewed as more assemble‑it‑yourself.
  • Laravel and Phoenix are most often cited as Rails‑like in productivity. Django is seen as the “Rails of Python” but somewhat less batteries‑included for certain web‑app needs.
  • Spring and ASP.NET Core are mentioned as comparable in productivity and more “enterprise‑friendly,” with long-term support and smoother upgrades.

Critiques: architecture, maintenance, and community

  • Some argue the uniform Rails layout pushes “plumbing” (MVC, ActiveRecord) ahead of domain modeling, leading to fat models, tight coupling, and long‑term messiness, especially for complex or non‑CRUD domains.
  • There is debate over whether to keep business logic tightly coupled to Rails vs. isolating it via engines, gems, hexagonal architectures, or repositories; opinions and experiences are mixed.
  • Criticism of the ecosystem includes heavy gem dependency, “magic,” historical upgrade pain, and a culture that allegedly encourages strong framework coupling and resists alternative patterns.

Performance and scalability

  • One side claims Ruby/Rails is “very slow” and ill‑suited to high‑throughput, IO‑heavy tasks (e.g., JSON-transforming API gateways), preferring Go/Java/Elixir for those.
  • Others counter that for typical database‑bound web apps Rails is “fast enough,” proven at large companies, and that performance is rarely the real bottleneck compared to system design and database access.

Ruby, learning curve, and developer experience

  • Some newcomers from Python/JS find Ruby harder to “grok” (symbols, metaprogramming, multiple ways to do things); others report the exact opposite, finding Ruby/Rails far more intuitive than Django or JS stacks.
  • Ruby is frequently described as joyful and elegant; features like everything being an object and the REPL/console are seen as major productivity and testing boosters.
  • A few express concern about governance decisions and the framework’s “ideological” direction, preferring modern TypeScript full‑stack solutions for new projects.