Doing Rails Wrong

Original Article ↗ Hacker News Discussion ↗

Rails vs Modern JS Stacks

  • Many argue most real-world apps (CRUD, dashboards, forms) don’t need React+Vite+Tailwind+ESLint+Prettier. Vanilla Rails (especially v8) already gives fast forms, navigation, and “batteries included” productivity.
  • Others counter that almost every app grows in complexity; starting with React/Vue/Svelte makes future rich UI and state handling easier than retrofitting onto Hotwire/Stimulus.

Hotwire/Stimulus vs React/Vue/Svelte

  • Pro-Hotwire view: lets you avoid heavy JS, build modern-feeling apps with server-rendered HTML, websockets, minimal JS, no build step, and leverage browser/server state instead of duplicating it on the client.
  • Critics say Hotwire/Stimulus are confusing, poorly documented, and degrade quickly in multi‑dev projects with complex, stateful interactions. They see component-based UIs (React-style) as the real win of the last decade.
  • Several report replacing Hotwire frontends with InertiaJS + React/Vue and finding it far easier to maintain.

InertiaJS and Hybrid Approaches

  • InertiaJS is repeatedly praised as a “best of both worlds”: Rails/Laravel handle routing, auth, data; React/Vue/Svelte handle views without a separate API or duplicated state.
  • Islands/progressive enhancement approaches are suggested: default to SSR, mount SPA-like components only where highly interactive behavior is truly needed.

Tooling Fatigue and Ecosystem Churn

  • Many complain about “web dev tooling fatigue”: endless stacks in JS and in DevOps (Terraform/Pulumi, k8s toolchains, etc.), and job ads expecting knowledge of everything.
  • Others push back that Vite-based setups are now straightforward, and tools like React, TypeScript, ESLint, Tailwind exist for concrete reasons (types, consistency, bundling).
  • Rails is also criticized for its own churn (Coffeescript, Sprockets → Webpacker → Propshaft, different JS stories), though some say upgrades are manageable if dependencies are kept under control.

Monolith vs SPA + API

  • One camp: for small teams and typical business apps, a monolith (Rails/Django/Laravel + a bit of JS) is simpler, cheaper, and avoids duplicated validation, routing, and state bugs between frontend and backend.
  • The other camp prefers a thin CRUD backend and a rich SPA client, arguing this simplifies each side conceptually and scales to more interactive experiences and multi-platform clients.

Meta & Culture

  • Several note this “you’re doing Rails/JS wrong” argument has recurred for 10–20 years with new names and similar tradeoffs.
  • Opinions differ on whether complexity is inherent to “modern” web apps or mostly self-inflicted via overengineering and fashion-driven tool choices.