- Al crear una app de gestión de setlists (setlist.rocks) para la banda, redescubrió el placer de desarrollar con Ruby on Rails después de mucho tiempo
- El más reciente Rails 8 mantiene la estructura MVC tradicional, pero se moderniza con un frontend “no-build” basado en Hotwire (Stimulus·Turbo) y con Solid Cache/Queue/Cable, entre otros
- SQLite se ha optimizado al punto de ser apto para servicios reales solo con la configuración por defecto, y la herramienta de despliegue Kamal simplifica el despliegue sin tiempo de inactividad basado en contenedores
- Gracias a la filosofía de Rails de “convención sobre configuración” y a su rico ecosistema de gems, es posible pasar rápidamente de la idea al prototipo
- Aunque la popularidad de Ruby y Rails ha bajado respecto al pasado, sigue siendo un framework OSS maduro y coherente que ofrece placer al desarrollar
Proyecto paralelo y regreso a Rails
- Para gestionar los setlists y las notas de canciones de la banda, desarrolló una webapp por su cuenta, buscando una forma más eficiente que las hojas de cálculo o el chat
- Durante el desarrollo, volvió a sentir la simplicidad y productividad de Rails, y menciona que, frente a la complejidad reciente del ecosistema web, sintió el “placer puro de desarrollar”
- Ruby sigue siendo valorado como un lenguaje con sintaxis natural y gran expresividad, fácil para trasladar ideas al código
- Según la encuesta de Stack Overflow 2025, la popularidad de Ruby y Rails ha caído, pero en proyectos personales siguen siendo una opción preferida
Cambios en Rails 8 y frontend
- Rails 8 ofrece integración de frontend basada en Hotwire (Stimulus·Turbo) mientras mantiene la estructura MVC existente
- Turbo intercepta clics en enlaces y envíos de formularios para ofrecer capacidad de respuesta a nivel de SPA
- Stimulus agrega comportamiento JS solo donde hace falta, lo que permite crear una UI interactiva con la mínima cantidad de JavaScript posible
- Con la incorporación de Importmap, es posible cargar librerías JS directamente desde un CDN sin Webpack ni npm
- Aunque usó herramientas de IA para generar la UI, también expresa dudas sobre la relación entre la creación y el carácter artístico del código
Flujo de trabajo y productividad en desarrollo
- Con la filosofía de Rails de “convención sobre configuración”, se pueden estructurar rápidamente modelos, rutas, controladores y vistas
- Como ejemplo, muestra el proceso de crear el modelo
Tag, automatizar el routing RESTful y procesar respuestas JSON
- Las plantillas ERB y la recarga en vivo permiten prototipado rápido
- El abundante ecosistema de gems facilita integrar funciones diversas como CSV o PDF
Mejoras de backend: serie Solid* y SQLite
- Solid Cache/Queue/Cable viene incluido por defecto en Rails 8, lo que permite manejar caché, colas de trabajos y WebSockets sin Redis
- Solid Cache usa caché basada en base de datos para ahorrar RAM y simplificar la arquitectura
- Solid Queue gestiona trabajos en segundo plano sobre base de datos y se ejecuta solo con la configuración
SOLID_QUEUE_IN_PUMA=1
- Solid Cable ofrece funciones en tiempo real como adaptador de Action Cable basado en base de datos
- SQLite aplica por defecto optimizaciones como modo WAL y sincronización NORMAL mediante la configuración
pragmas: en database.yml
- Incluso sin un servidor de base de datos aparte, puede usarse de forma práctica en entornos de producción pequeños
Automatización de despliegue y Kamal
- Al mencionar la complejidad de los despliegues del pasado con Capistrano y Ansible, presenta Kamal como la herramienta de despliegue por defecto en Rails 8
- Automatiza el proceso de construir contenedores → hacer push → desplegar en el servidor → health check → cambio sin downtime
- kamal-proxy se encarga del cambio de tráfico y del manejo de SSL
- El archivo
.kamal/secrets permite la gestión segura de secretos basada en variables de entorno
- Integrado con GitLab CI, el despliegue puede hacerse solo con
git push, recreando la simplicidad de Heroku de antes
Autenticación y otras funciones
- Rails 8 ofrece un generador de autenticación integrado (auth generator), con el que se puede construir un sistema de autenticación más simple que con Devise
- Devise sigue siendo útil por sus funciones abundantes y su documentación, pero también se valora la simplicidad de la autenticación nativa de Rails
Estado actual y continuidad del ecosistema Rails
- Aunque la popularidad de Ruby y Rails ha disminuido, servicios importantes como Shopify, Basecamp, SoundCloud y GitHub lo siguen usando
- Muchas gems están en fase de mantenimiento, pero Rails mantiene un ciclo de lanzamientos constante cada año
- Se le describe como un framework con el que sigue siendo divertido desarrollar, aunque la llegada de nuevos desarrolladores haya disminuido
Conclusión
- Rails se ha mantenido a cierta distancia de las tendencias más recientes, pero se destaca como una herramienta que permite recuperar el placer de desarrollar y la simplicidad
- Más que la popularidad, se pone el foco en el placer de crear y la creatividad, y cierra con el mensaje de “probar Rails una vez más”
4 comentarios
Si no me falla la memoria, en Rails era "convención sobre configuración", no "configuración sobre convención"...
> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails descartó todo eso e introdujo la noción de “convención sobre configuración”
Parece que el LLM lo imprimió exactamente en el orden de entrada, sin cambiar el orden de las palabras. En el original sí está correctamente.
El LLM se equivoca en cosas como esta. Ya lo corregí. Gracias.
Comentarios de Hacker News
Me gusta mucho Rails, pero después de haber trabajado en una base de código grande sin tipado estático, me cuesta volver a Rails para algo que no sea un proyecto personal.
Una base de código grande sin tipos es una pesadilla de mantener, incluso con un IDE potente como RubyMine.
Me da curiosidad cuánto ha avanzado Sorbet últimamente, especialmente qué tan bien encaja con RoR.
Sigue muy bien la filosofía de Rails y al mismo tiempo hace más fácil aprender Rust.
Vale la pena probarlo un fin de semana.
Hay que clonar datos reales de producción en local o conectarse por SSH al servidor y revisar el estado desde un REPL.
Depurar desde el IDE era una experiencia infernal.
Realmente amaba Ruby, pero después de vivir la depuración en tiempo real se hace difícil.
Ya no hay una razón real para elegir Ruby o Python.
Python aguantará un poco más por ML, pero al final creo que desaparecerá.
También me alegra que alguien diga esto públicamente.
Últimamente estoy cansado de la arquitectura de microservicios excesiva.
En las noches trabajo en proyectos que simplemente resuelven el problema, sin estructuras innecesarias.
Antes lidiaba mucho con estructuras en PHP, pero tanto Rails como PHP al final son solo herramientas para resolver problemas.
Se siente como en el viejo desarrollo con IDE de escritorio, donde todo funciona “dentro de una caja”.
Es como recuperar la simplicidad enfocada en productividad, lejos de tener que gestionar todos los componentes complejos del desarrollo web.
Además, me encanta no tener que usar TypeScript. Creo que TypeScript es verboso y está lleno de boilerplate innecesario.
Llevamos ejecutando apps de Rails en producción desde 2007.
El secreto de la longevidad de Rails no está en la edad, sino en su estabilidad y practicidad.
La idea de que usar JavaScript en el backend te hace más eficiente ya quedó refutada.
La mayoría de los cambios de stack ocurren por optimización del currículum o por ansiedad de seguir tendencias, no por necesidades reales de ingeniería.
Rails ha seguido impulsando negocios reales silenciosamente.
Nadie pensará en serio que los 3.1 millones de paquetes de NPM ofrecen más funcionalidad que los 190 mil de RubyGems.
Estamos migrando con Inertia + Vue.js, y es una combinación tan potente que casi no hace falta tocar el backend.
La mejora de productividad compensa incluso la dificultad de contratación.
Y mientras más usuarios haya, más saludable es el ecosistema.
Pero como RubyGems también tiene muchos paquetes antiguos, creo que no es una comparación tan simple.
Me gusta la filosofía de "incluye baterías" de RoR o Django, pero mantener proyectos viejos consume mucho tiempo.
Actualizar un proyecto de 5 o 6 años vuelve la gestión de dependencias una carga importante.
Por eso últimamente prefiero desarrollar con frameworks simples en Go, o incluso sin framework.
Si usas solo las librerías realmente necesarias, mantenerlo es fácil.
Fuera de los parches de seguridad, me pregunto por qué habría que actualizar tanto.
En el último año y medio subí 5 versiones mayores y aun así fue relativamente simple.
Si se arma con cuidado al principio, casi no hay que tocarlo durante mucho tiempo.
Creo que la experiencia de actualización está subestimada.
Next.js cambia por completo su estructura en cada versión mayor, mientras que Rails es mucho más estable porque su ciclo de deprecación gradual es lento.
Cuando estás desplegando productos de forma continua, la estabilidad de la interfaz importa mucho más que el paradigma más nuevo.
El cambio de pages a app router en Next.js fue prácticamente una replatforming completa.
En cambio, Rails tiene rutas de actualización documentadas y ciclos de deprecación predecibles.
La gestión de versiones de Ruby también elimina casi por completo los problemas de diferencias de entorno gracias a rbenv/asdf.
Llevo más de 10 años usando Rails para todo, desde DevOps hasta desarrollo web en solitario, y volvería a elegirlo.
Rails es un framework limpio y productivo que lo trae todo.
Incluso en la encuesta de Stack Overflow sigue estando dentro del “Top 5 de stacks que la gente quiere usar en su próximo proyecto”.
Casi no hace falta preocuparse por la infraestructura y desplegar es sencillo.
Al final lo importante no es lo que piensen los demás, sino usar la herramienta que te funciona a ti.
Salió un año antes que Django.
Enlace a la encuesta
Antes pensaba que Ruby/Rails era la solución óptima para la mayoría de los problemas, y sigo pensándolo hoy.
Nunca he usado Rails, pero sí conecto con lo caótico que se ha vuelto el entorno de desarrollo web hoy en día.
Por eso yo elegí Elixir y Phoenix pensando en el futuro.
Seguro lo probaré en mi próximo proyecto.
Me da curiosidad qué tiene Elixir de tan atractivo y en qué debería fijarme al acercarme por primera vez.
Hace 10 años construimos en Rails el frontend de streaming de una gran emisora sueca.
En Heroku manejó más de 1 millón de usuarios concurrentes, y funcionó realmente bien.
Después me moví a otras áreas como infraestructura de streaming, API, AI/ML, etc., pero no porque Rails hubiera fallado, sino porque la naturaleza del problema cambió.
Rails encaja bien en problemas centrados en modelos de datos y lógica de negocio, y para problemas centrados en concurrencia o infraestructura otros lenguajes encajan mejor.
Ruby sigue siendo un lenguaje bello y expresivo, y lo extraño mucho.
Pero siento que es difícil desprenderse por completo del sesgo personal hacia un lenguaje que te gusta.
Me da curiosidad saber con qué lenguaje hiciste tu siguiente proyecto.
Para quienes extrañan la ausencia de tipado estático, hay soluciones excelentes como Sorbet.
Puedes disfrutar al mismo tiempo de la productividad de Ruby, tipado estático e integración con LSP.
Gracias a Shopify, Sorbet también tiene buen soporte en Rails.
Me encanta tanto este ecosistema que todavía quisiera seguir trabajando con Rails.
Gracias al avance de las herramientas de IA, ahora siento que el único límite es el tamaño de tu imaginación.
Con eso construí un agente de e-commerce que monitorea una tienda 24/7 y envía alertas por Slack.
Si vas a hacer proyectos relacionados con IA, vale la pena revisar selzee.com/openclaw.