Why Ruby on Rails still matters

Original Article ↗ Hacker News Discussion ↗

Rails, CRUD, and Application Shape

  • Many describe Rails as naturally favoring “1 model = 1 concept = 1 REST resource” and CRUD-style flows (list → form → updated list), which match a huge share of real-world back-office and line-of-business apps.
  • Others note real UIs almost always mix multiple models per screen, which strains strict REST and pushes complexity to the frontend.
  • Rails’ responders: you’re not forced into 1:1; you can build composite controllers, multi-model forms, dashboards, and partial updates, especially with Turbo/Hotwire and nested forms.

API Design and GraphQL Debates

  • Pain points with REST in rich UIs: overfetching, many small requests, ad‑hoc query parameters, or view-specific RPC endpoints. No approach feels clearly “right” at scale.
  • Some see GraphQL as a clean view–model boundary; others argue it’s complex to harden, easy to abuse (expensive queries, broad data access), and ends up devolving into whitelisted, REST-like calls anyway.
  • Several argue it’s fine for the UI to make many REST calls, especially with HTTP/2 and caching, and that APIs should be designed around use cases, not tables.

Rails vs Next.js and the JS Ecosystem

  • Next.js is praised as React’s “Rails-like”: conventions, routing, SSR/CSR, good for highly interactive products.
  • Critics counter that it’s not “batteries included”: no built-in ORM, jobs, mailers, attachments, or auth/authorization; those must be assembled from many libraries.
  • In contrast, Rails is viewed as a full-stack, opinionated monolith that remains extremely productive for 0→1 apps and complex CRUD-heavy systems, with Hotwire covering a large slice of SPA-style interactivity.

Other Frameworks: Django, Phoenix, Elixir, Rust, Go

  • Many say everything argued for Rails applies similarly to Django; some Rubyists find Django “behind” Rails; others prefer Python’s broader ecosystem and typing.
  • Phoenix LiveView is repeatedly praised as a stateful, reactive alternative that inspired Hotwire/Turbo; Elixir is seen as attractive for concurrency and scaling but has a smaller ecosystem and a bigger conceptual jump.
  • There’s curiosity about Rails‑like frameworks in Rust/Go; current options feel more like low-level libraries or microservice tools than integrated “Rails for X”.

Typing, AI Tools, and Rails’ “Age”

  • The article’s claim that Rails struggles with LLM streaming and parallelism is disputed; several report streaming LLM chat UIs and concurrent IO working fine with Rails + Hotwire.
  • Lack of strong typing is seen by some as a drawback for AI-assisted coding and refactoring; others report LLMs perform very well in Rails codebases because conventions and structure compensate for missing types.
  • Broader thread: static types help with refactoring and correctness, but LLMs are reducing the autocomplete advantage of typed languages.

Why Rails Still Matters (and Critiques)

  • Pro-Rails comments emphasize: convention over configuration, batteries-included stack, mature ecosystem, and the fact that most business software is “just” CRUD plus a few special features (“spreadsheets on the internet”).
  • Critics cite dynamic typing, metaprogramming, and large monoliths as long-term maintenance risks, and argue many successful companies eventually outgrow Rails—though others point out major firms still run large Rails codebases.
  • There’s meta-discussion about Rails’ image: some quietly ship with it; others feel compelled to periodically assert it’s “not dead” amid hype around Next.js and AI.