We fell out of love with Next.js and back in love with Ruby on Rails

Original Article ↗ Hacker News Discussion ↗

AI tools, typing, and language choice

  • Several comments argue that cursor-style AI editors work best with strongly typed languages like TypeScript, due to tight edit–typecheck–fix loops; others report good results with Elixir and question whether this is really proven.
  • There’s a broader undercurrent that LLMs lower the cost of learning “yet another language,” making polyglot architectures (Rails + Python AI service, Java + Python microservice, etc.) more viable.

Rails vs Next.js and the Hardcover migration

  • Many see the move as less “Next vs Rails” and more “monolith vs overcomplicated JS stack,” noting Hardcover already had a Rails backend and then layered Next, Hasura/GraphQL, and Vercel on top.
  • Supporters frame Rails as ideal for CRUD-heavy products with modest scale and limited funding: simpler hosting, predictable costs, and strong conventions.
  • Skeptics argue the team could have self‑hosted Next.js or simplified their architecture instead of rewriting, and that their UI still feels sluggish post‑migration.

Server‑Side Rendering, SPAs, and complexity

  • Strong thread arguing SSR + “HTML by default” (Rails+Turbo, htmx, Phoenix LiveView, React Server Components) is better for most dashboards/CRUD apps: less client JS, fewer build tools, better first paint and SEO, fewer supply‑chain risks.
  • Others insist frameworks like React from day one are safer: any nontrivial interactivity without a framework degenerates into DOM‑manipulation spaghetti and is painful to retrofit.
  • Big disagreement over SPAs: some say “SPAs = two apps and two states” and are overkill for news sites; others stress that modern SPAs can SSR, cache aggressively, and offer superior UX for highly interactive products.
  • Performance and UX complaints about typical SPAs: blank screens with spinners, broken back-button/history, stale state, and slow rendering on low‑end devices.

Rails strengths and pain points

  • Praised for convention‑over‑configuration, batteries‑included CRUD, thin controllers/models, stable ecosystem (e.g., Devise, Geocoder), and ActiveRecord’s REPL.
  • Criticisms focus on “magic” and metaprogramming making code hard to navigate, the GIL and perceived slowness, ActiveRecord callbacks not scaling to batch operations, and difficulty reasoning without types.
  • Some prefer Django, Phoenix, or ASP.NET/Laravel as “better Rails‑like” takes, especially in typed languages.

JavaScript ecosystem, ORMs, and full‑stack JS

  • Many describe full‑stack JS as fragmented: too many framework choices (Next, Remix, Astro, TanStack, etc.) and no universally accepted ORM; Prisma and Drizzle are common but also draw criticism and churn.
  • There’s pushback against the JS culture of constantly reinventing tooling for marginal DX gains while neglecting UX and long‑term stability.
  • Others defend TS + modern bundlers (Vite, Bun) as “fine” general‑purpose stacks, with good DX and adequate performance for most backend work.

GraphQL and API design

  • One camp loves GraphQL, especially when the API is public or front‑ and back‑end teams are decoupled: flexible queries, reduced over‑fetching, good fit for “API as product.”
  • Another camp finds GraphQL over‑complex and risky: easy to DOS or introduce N+1s, harder to reason about performance, loses HTTP semantics, complicates security, and often re‑implements what a well‑designed REST API already does.

Phoenix/Elixir and other alternatives

  • Multiple commenters highlight Phoenix + LiveView as “a better Rails” with great performance and reduced need for JS, though latency and offline issues are concerns for global or flaky‑network users.
  • Other “Rails‑adjacent” options mentioned: ASP.NET Core, Laravel, Spring Boot, Crystal/Lucky, Kotlin/Ktor, SolidStart, and Inertia.js with various frontends.

Brand, culture, and DHH

  • A side discussion debates whether Rails’ association with its creator is a liability; some dislike his public stances, others see this as culture‑war noise irrelevant to technical merits.
  • Several note Shopify and others now effectively steward Rails, and that its value should be judged on the framework and ecosystem, not personalities.