Rewrite it in Rails
Choosing Ruby on Rails for web applications is framed as a pragmatic win for productivity, ecosystem maturity, and “batteries‑included” tooling, especially compared with assembling stacks in Rust, SvelteKit, or lighter frameworks. Commenters argue that most real‑world problems are about team skill, architecture, and long‑term maintainability rather than raw performance, and that Rails still excels at getting products to market quickly. Alternatives like Django, Laravel, Phoenix/Elixir, Node/TypeScript frameworks, and modern frontend stacks are weighed, but many conclude Rails remains a strong default for greenfield apps until scaling needs or organizational context clearly justify something else.
Rails’ appeal and role
- Many see Rails as still the most productive choice for new web apps, especially for startups and small teams.
- Key value: a cohesive, “batteries included” ecosystem (background jobs, websockets, auth, email, caching, DB replicas) and a “right way” for most problems.
- Rails is framed as a cost-cutting, time-to-market tool; if an app grows enough that Rails becomes the bottleneck, that’s considered a success scenario.
Ecosystem vs. language
- Several comments stress that people choose Rails/Django/Laravel primarily for the framework and ecosystem, not for Ruby/Python/PHP per se.
- Integrated stacks are contrasted with ad‑hoc combinations of libraries in Rust/Go/Node, which can be fragile and slow teams down.
- A similar argument appears for .NET, Symfony, Phoenix, etc.: the benefit is coordinated components and large communities.
Maintainability and refactoring
- Divided views: some report decade‑old Rails apps as manageable; others say Rails monoliths often hit “tech bankruptcy” after ~5 years.
- Criticisms: weak tooling (LSP, typing), heavy metaprogramming, hash-based APIs, and lack of strong types make large refactors risky and time-consuming.
- Others counter that spaghetti code is mainly a developer/architecture problem, not specific to Rails.
- ActiveRecord is seen as both the secret to Rails’ speed of development and a source of scaling and testing pain, especially when misused instead of proper SQL/DB design.
Rust, Elixir, and other stacks
- The original Rust choice is broadly portrayed as overkill for typical web apps and costly in productivity.
- Some argue Rust web tooling is maturing (Actix/Axum, emerging “Rails-like” frameworks), but still early for production.
- Phoenix/Elixir is praised as a more natural transition from Rails with strong concurrency (OTP), but concerns are raised about smaller talent pools.
- A minority prefers Rust+modern JS over Rails or Phoenix, citing easier long-term refactoring.
Front-end frameworks, JS, and LLMs
- SvelteKit/Next.js are seen as front-end/SSR tools, not full Rails replacements; they lack built-in jobs, ORM, mailers, etc.
- Rails + Hotwire is often “enough,” though some prefer mixing in React/Svelte for rich interactivity and larger component ecosystems.
- LLMs are said to narrow the gap by generating boilerplate, but they help less with debugging highly “magical” frameworks.