Ruby on Rails: El documental [video]

Reacción general al documental

• A muchos les pareció divertido, nostálgico y motivador; algunos dijeron que reavivó su interés en Rails o que les dieron ganas de probarlo por primera vez.
• Unos pocos sintieron que era demasiado corto y superficial, más parecido a una ligera adoración al héroe que a una historia profunda, y desearon que cubriera con más detalle las dificultades y la evolución a largo plazo.
• Varios señalaron omisiones de figuras y recursos de la comunidad temprana que fueron influyentes para ellos.

Fortalezas centrales de Rails

• Las fuertes convenciones y una estructura de aplicación consistente fueron ampliamente elogiadas: la mayoría de las apps de Rails “se ven igual”, lo que facilita la incorporación, reduce las discusiones triviales y ayuda a agencias/consultores a entrar rápidamente en bases de código desconocidas.
• La alta productividad es un tema recurrente: la gente informa ser varias veces más rápida que en Node, Go o stacks previos de Python/JS, especialmente para aplicaciones web de estilo CRUD y prototipos.
• Hotwire/Turbo, Turbo Native, Strada y las herramientas integradas (por ejemplo, Solid Cache/Queue, Kamal) se ven como refuerzos de Rails como una solución full-stack cohesionada con menos JavaScript.

Comparaciones con otros ecosistemas

• Se critica a JS/Node por la falta de un “framework único” con fuertes convenciones; algunos ven a Next.js como lo más cercano, pero sigue siendo centrado en front-end. Se mencionan otros intentos full-stack en JS (Adonis, Remix, SvelteKit, etc.), pero se perciben más como algo que hay que ensamblar uno mismo.
• Laravel y Phoenix son los más citados como similares a Rails en productividad. Django es visto como el “Rails de Python”, aunque algo menos todo incluido para ciertas necesidades de aplicaciones web.
• Spring y ASP.NET Core se mencionan como comparables en productividad y más “amigables para la empresa”, con soporte a largo plazo y actualizaciones más suaves.

Críticas: arquitectura, mantenimiento y comunidad

• Algunos argumentan que el diseño uniforme de Rails empuja el “plumbing” (MVC, ActiveRecord) por delante del modelado de dominio, lo que lleva a modelos gordos, acoplamiento estrecho y desorden a largo plazo, especialmente en dominios complejos o no CRUD.
• Hay debate sobre si conviene mantener la lógica de negocio estrechamente acoplada a Rails o aislarla mediante engines, gems, arquitecturas hexagonales o repositories; las opiniones y experiencias están divididas.
• La crítica al ecosistema incluye una fuerte dependencia de gems, “magia”, dolor histórico al actualizar y una cultura que supuestamente fomenta un fuerte acoplamiento al framework y resiste patrones alternativos.

Rendimiento y escalabilidad

• Un lado afirma que Ruby/Rails es “muy lento” e inadecuado para tareas de alto throughput y muy intensivas en IO (por ejemplo, gateways de API que transforman JSON), y prefiere Go/Java/Elixir para esos casos.
• Otros responden que, para aplicaciones web típicas ligadas a base de datos, Rails es “lo suficientemente rápido”, está probado en empresas grandes, y que el rendimiento rara vez es el verdadero cuello de botella comparado con el diseño del sistema y el acceso a la base de datos.

Ruby, curva de aprendizaje y experiencia del desarrollador

• Algunos recién llegados desde Python/JS encuentran Ruby más difícil de “entender” (símbolos, metaprogramación, múltiples maneras de hacer las cosas); otros reportan exactamente lo contrario, encontrando Ruby/Rails mucho más intuitivo que Django o los stacks de JS.
• Ruby se describe con frecuencia como alegre y elegante; características como que todo sea un objeto y el REPL/consola se consideran grandes impulsores de productividad y de pruebas.
• Unos pocos expresan preocupación por las decisiones de gobernanza y la dirección “ideológica” del framework, y prefieren soluciones modernas full-stack en TypeScript para nuevos proyectos.