Estás usando Rails mal

• A través de la conversación entre dos desarrolladores sobre la integración de Rails 8 con Vite, se satiriza lo innecesariamente complejo que se ha vuelto el entorno moderno de desarrollo web
• Uno de ellos agrega una gran cantidad de herramientas como Vite, React, Babel, Tailwind, Docker y Husky y asegura que eso constituye un stack “moderno”
• En cambio, la otra persona muestra una app que corre de inmediato solo con Rails base, sin configuración, dejando en evidencia la utilidad de la simplicidad
• Al burlarse de la situación actual, dependiente de cadenas de herramientas complejas, se enfatiza el mensaje de “simplemente usa Rails” y se invita a recuperar la virtud de la simplicidad
• Se señala que se está olvidando el propósito original de Rails: productividad, consistencia y el placer de desarrollar
  > “Just F#$%^& use Rails”

---

Traducción de la conversación original

Kevin: Oye, ¿ya probaste Vite para Rails 8? Es rapidísimo.

John: Lo he escuchado mencionar. ¿Es una herramienta de build? ¿Rails no tenía ya algo así?

Kevin: Sí, tenía. Pero Vite es más moderno. Tienes que instalar Node y npm y configurar algunos scripts, pero vale la pena.

John: Espera, ¿ahora Rails necesita Node?

Kevin: Sí, si quieres usar React. Hoy en día todos usan React.

John: ¿Rails no tenía algo para eso?

Kevin: Sí, pero ahora tienes que usar Vite junto con React Refresh. Así los componentes se recargan al instante. Y si quieres usar TypeScript, también tienes que configurar eso.

John: Solo de oírlo ya suena complicado.

Kevin: No, para nada, no es gran cosa. Instalas Babel, configuras .babelrc, agregas vite-plugin-ruby y para estilos usas PostCSS.

John: ¿PostCSS?

Kevin: Sí. Y claro, también tienes que usar Tailwind — no me vas a decir que quieres escribir CSS a mano, detalle por detalle.

John: Claro que no.

Kevin: Luego ordenas el código con ESLint y Prettier, y si además pones hooks con Husky antes de cada commit, queda perfecto.

John: Entonces Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier y Husky. ¿Eso es todo?

Kevin: Casi. Si quieres renderizado del lado del servidor, tienes que usar Next.js o Remix.

John: Espera, ¿sí seguimos hablando de Rails, verdad?

Kevin: Claro. ¡Hoy en día lo que manda es el stack híbrido! Y si quieres componentes reactivos sin usar un framework de JS, también están bien StimulusReflex o Hotwire.

John: ¿StimulusReflex? Suena como el nombre de un personaje de Marvel.

Kevin: Jaja, es real. Es para actualizaciones en tiempo real. Pero tienes que configurar ActionCable y también necesitas Redis.

John: ¿Redis?

Kevin: Sí, porque necesitas una capa de pub/sub. No te preocupes, solo tienes que levantar otro contenedor de Docker.

John: ¿También hay que usar Docker?

Kevin: Claro. Es indispensable para aislar dependencias. Y si quieres reproducir el entorno completo, también tienes que usar Docker Compose, desplegar en Fly.io y correr un pipeline con GitHub Actions.

John: Eso... suena bastante complejo.

Kevin: Es solo desarrollo web moderno, amigo. Sencillo. ¿Y tú qué haces?

John: Solo estoy jugando un poco con esto.

(John ejecuta un solo comando. La app arranca de inmediato. Los formularios funcionan, carga rápido y la navegación es velocísima.)

Kevin: Wow, se ve bastante complejo. ¿Qué stack usas?

John: Solo Rails puro.

> Just F#$%^& use Rails.

[labeldock]

Yo quiero a ambas herramientas. Son herramientas cuyos ecosistemas y objetivos se cruzan en algunos puntos, pero no son exactamente lo mismo, así que no deberían evaluarse con base en la dificultad. Si escribes con vite, puedes desarrollar scripts de forma amplia y sofisticada. En cambio, Stimulus o Hotwire son más adecuados para minimizar el desarrollo de scripts.

[roxie]

Parece que la mayor parte del contenido está enfocada en el desarrollo frontend...

[GN⁺]

Opiniones de Hacker News

• Este artículo se ha reescrito durante más de 10 años
  Eso que llaman “complejidad” no es más que una lista de herramientas, cada una resolviendo un problema específico
  Las herramientas en sí no son el problema; la realidad es que hay una complejidad inherente al desarrollo web moderno
  Se puede ver una complejidad “oculta” similar también en ASP.NET o en frameworks de GUI de escritorio
  Por ejemplo, si usas Rails como backend de API y React se encarga del frontend, ya es una arquitectura completamente distinta al monolito tradicional de Rails
  Una lista de herramientas como Vite, React o Prettier son opciones dirigidas a problemas totalmente distintos (si quieres usar Rails también para el frontend, simplemente usa Rails; no me gustan mucho las formas intermedias)
  El verdadero problema es cómo se aprende
  Hoy en día muchos desarrolladores aprenden primero el framework antes de dominar las bases de la web (HTML, CSS, lógica del lado del servidor, base de datos)
  Cada herramienta existe por una razón, y todas son herramientas necesarias para la web moderna
  Verlo como “hay demasiadas” es no estar viendo correctamente la realidad de la industria

  • La complejidad no es algo inherente al desarrollo web
    Más bien, ahora se puede hacer más con menos
    Hotwire funciona casi como Rails vanilla, y permite armar con una sola línea una experiencia moderna donde el contenido se actualiza en tiempo real mediante websockets
    La forma común de desplegar JS en Rails también se ha vuelto muy simple gracias a import maps (sin necesidad de una etapa de build separada)
    Incluso Tailwind se puede agregar muy fácilmente
    Hasta el despliegue se volvió mucho más sencillo con kamal
    Así que no estoy de acuerdo con eso de que la complejidad sea esencial, y Hotwire justamente ayuda a reducirla
    El aprendizaje debería orientarse no a “aprender más cosas”, sino a “hacer más con menos”
    La verdadera habilidad no es saber usar 20 lenguajes o servidores, sino superar a mil personas con un equipo de 3 usando solo 4 cosas

  • No creo que la gente se oponga a la existencia de las herramientas en sí, sino a esa idea de que todos necesariamente tienen que usarlas
    Como todos los tutoriales y títulos de YouTube salen con cosas como “¡La stack MONGOOSE que tienes que usar sí o sí!”, termina habiendo principiantes que quieren meter redis a la fuerza en un blog de repostería
    En realidad, la mayoría de los sitios funcionan perfectamente sin una stack especial
    Pero como nadie promociona eso, muchos desarrolladores junior ni siquiera saben que eso es cierto
    Estoy de acuerdo en que se debe priorizar aprender las tecnologías base, pero no es fácil transmitir ese mensaje en medio de empresas promocionando todo tipo de servicios

  • Soy bastante principiante en Rails, pero tengo unos 10 años de experiencia en otros lenguajes
    Si hace falta, está bien agregar herramientas (si realmente se necesitan ya es otra discusión)
    Pero Rails, por naturaleza, ya es un framework gigante todoterreno que incluye desde ORM hasta consola y generación de código con scaffolding
    Si hacen falta herramientas adicionales, ¿no habría que reconsiderar Rails mismo?
    Tal vez algo más modular sería mejor
    La expresión “Rails vanilla” me parece una señal de alerta. Me cuesta entender cómo algo tan grande puede llamarse vanilla

  • El punto central del artículo es que muchas veces la gente ni siquiera se cuestiona desde el inicio si realmente necesita una “aplicación web moderna”, y tampoco sabe que con Rails vanilla puede ser suficiente
    Falta el esfuerzo por entender por cuenta propia las opciones por defecto de Rails vanilla

  • Mencionar la “complejidad del desarrollo web moderno” solo describe una situación problemática, no un requisito indispensable
    Si arrastras miles de paquetes de npm para un sitio que básicamente es una base de datos y unas cuantas consultas SQL, algo estás haciendo mal

• Llevo escribiendo código Rails desde 2007
  Hay razones por las que la stack se volvió más compleja, y prácticamente no existe ningún equipo que “lo haya hecho bien” según el criterio del texto
  El problema de los frameworks Omakase (como Rails, que decide la mayor parte por ti) es que no solo cargas con la elección inicial, sino también con las decisiones posteriores, y además tienes que arrastrar a todo el equipo contigo
  Rails es poderoso, pero ni siquiera sus maintainers pueden prever perfectamente el futuro
  Por eso hoy casi no existen apps que hayan vuelto a Rails vanilla
  Antes, en la era pre-Docker, desplegar Rails era realmente engorroso. Se necesitaba un sistema de despliegue como Capistrano en vez de rsync o tarballs.
  Docker o k8s son cómodos, pero comparados con antes tampoco es que sean peores

  • Si recuerdas el despliegue de Rails de la era pre-Docker como “hacer rsync y descomprimir un tarball”, entonces era un setup realmente desastroso
    Desplegar con el Capistrano de “los viejos tiempos” era muchísimo mejor

  • Me gustaría que explicaran más específicamente qué tenía de malo “hacer push con rsync o tarballs a varias instancias”
    A simple vista no parece algo tan grave

  • Por eso siempre le he tenido cariño a Sinatra

• Es una pena que el mundo JS todavía no pueda reemplazar las utilidades listas para usar que ofrece Rails
  La mayoría de los desarrolladores JS no entiende bien este punto
  Pero JS siempre ha sido un ecosistema de reinventar la rueda

  • Una gran ventaja de JS es que cualquiera tiene la oportunidad de crear una plataforma nueva
    Incluso combinando varias plataformas JS al mismo tiempo, más o menos todo termina funcionando; además es muy escalable, hackeable, y hasta permite construir todo localmente de forma permanente para generar un sitio fijo
    Pero esa libertad requiere moderación
    Frenar al compañero que quiere meter otro framework nuevo termina siendo responsabilidad del equipo

  • Ember.js es un framework all-in-one (“con baterías incluidas”) creado por nombres pesados del mundo Rails
    Pero hay una razón por la que no tuvo tanto éxito como otros frameworks

  • En el ecosistema JS también existen frameworks backend con todo incluido como AdonisJS
    Pero el ecosistema NodeJS nació desde los microframeworks como reacción a frameworks rígidos como Rails o Django
    Incluso el concepto de Express era hacer algo “rápido y al aventón” para usarlo

  • En JS también hay varios frameworks full-stack parecidos a Rails
    Incluso existe uno llamado Sails
    JS resuelve problemas distintos a los que resuelve Rails, así que es natural que los frameworks se vean diferentes

  • Rails sí tiene muchas utilidades, pero a largo plazo puede cansar tener que actualizar periódicamente la base de código y seguir constantemente las tendencias de Rails

• Stimulus y Hotwire ya se establecieron como “la forma Rails”
  Pero incluso leyendo la documentación con atención, sigue siendo demasiado confuso
  Siento como si uno siguiera recreando componentes JS a mano una y otra vez
  En mi opinión, la combinación de Rails 8 + Inertia.js + React reduce más la necesidad de “reinventar la rueda”, sobre todo si usas componentes de shadcn

  • Totalmente de acuerdo con eso
    Nosotros también reemplazamos el frontend con Hotwire por Inertia, y de verdad es otro mundo
    A menos que de verdad estés haciendo un proyecto pequeño tú solo al 100%, Hotwire rápido se convierte en un desastre que nadie del equipo puede tocar

  • A mí, al contrario, me gustó tanto Stimulus que me lo llevé tal cual de Rails a una app en Phoenix
    Pero creo que el problema es el malentendido sobre esta herramienta
    Stimulus no es una alternativa a React
    Si estás acostumbrado a apps JS de decenas de miles de líneas, React puede tener más sentido
    Pero si tu app tiene al servidor como protagonista y solo quieres pulir la UX con unas cuantas decenas de líneas de JS, Stimulus cae perfecto
    En Phoenix, es una solución minimalista que encaja justo entre HTML estático y LiveViews dinámicos
    Nadie dijo nunca que Stimulus fuera para hacer una SPA, y creo que si intentas eso, claramente la vas a pasar mal

  • Stimulus es realmente pequeño, un sistema de eventos con hooks en HTML, y encaja bien con el request lifecycle de Rails
    Me da curiosidad si alguien ha logrado construir con éxito algo muy complejo usando Stimulus
    Mi impresión es que llevarlo tan lejos se vuelve demasiado difícil

  • Yo también podría decir que soy fanboy de Rails, pero me decepciona la situación actual de Stimulus y Hotwire
    El concepto es excelente, y la implementación probablemente también lo sea
    Pero la documentación es terriblemente insuficiente, al punto de que cuesta siquiera empezar, y en cada proyecto faltan referencias para responder si “empezar con esto no me va a encerrar luego en un callejón sin salida”

  • He usado Stimulus con Symfony para pequeñas interacciones, y me pareció bastante bueno por su API pequeña y bien diseñada
    Todo Turbo/Hotwire todavía no lo he usado, y para páginas complejas o con mucho estado normalmente uso Vue

• A estas alturas, los proyectos greenfield (hechos desde cero) prácticamente ya desaparecieron
  Fuera de los fundadores, los greenfield son rarísimos, y si alguien vende algo, el 99% de las veces lo resuelve con un wrapper sobre Shopify o algo parecido
  Incluso en empresas grandes, los proyectos greenfield ya están atados a todo tipo de consideraciones y frameworks internos, así que nadie empieza realmente desde rails new
  Esta discusión ya no tiene mucho sentido, y como es una pelea y una clase de artículo que se repite desde hace 10, 15 o 20 años, ya cansa y aburre
  En lugar de otro artículo nuevo, preferiría que hicieran algo nuevo de verdad

  • Completamente de acuerdo
    Trabajé 10 años con Ruby/Rails, y hasta las bases de código más “recientes” que vi ya tenían más de 5 años
    Siendo sincero, sí llegué a crear una app nueva greenfield en Rails, pero era un microservicio solo API, así que no necesitaba frontend
    En empresas de cierto tamaño, la solución frontend de Rails simplemente se ignora
    Aunque no encuentres ingenieros que sepan Hotwire, desarrolladores React o Vue sí puedes conseguir los que quieras
    La stack FE de Rails además cambia seguido y es difícil seguirle el paso (por ejemplo, me acuerdo de la época de CoffeeScript), casi no tiene documentación decente y en la práctica no tiene influencia
    Por eso toda esta discusión está desconectada de la realidad real

  • No puedo estar de acuerdo con la afirmación de que “ya no quedan proyectos greenfield salvo para fundadores”
    Si solo tomas como ejemplo monolitos viejos de grandes corporaciones o Fortune 500, estás mirando una minoría extrema que no representa el promedio
    Al contrario, me parece admirable el esfuerzo que pone rails new en dejar defaults sensatos y listos para usarse desde el inicio
    Ese enfoque llena muy bien el hueco entre Hello World y documentación de API demasiado simplista
    Incluso si no usas Rails, es algo digno de imitar

• Será bonito, pero eso no habla de la realidad de cómo una app Rails va migrando con el tiempo entre bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling y demás
  Del autoloader a zeitwerk, de Turbo a Hotwire, y así con muchísimas otras cosas que sí han cambiado de verdad
  Basta ver los anuncios en newsletters de Rails: están llenos de “expertos que te ayudan a actualizar tu app Rails”

  • Gracias por mencionar esto
    Es fácil decir “solo usemos Rails vanilla”, pero en los últimos 5 años cada versión de Rails ha cambiado por completo la forma de manejar JS
    Todavía hay muchos gems que dependen de sprockets, así que incluso siguiendo la forma Rails terminas atrapado en un bloque complejo de JS
    Ahorita sí está realmente confuso. Tal vez mejore algún día, pero claramente Rails también tiene responsabilidad en eso

  • Tampoco hay que olvidar CoffeeScript
    Hasta hace poco, la empresa donde trabajé seguía posponiendo portar CoffeeScript, mientras que el código nuevo lo escribían en Vue

• Aprendí por experiencia propia que, si no es un proyecto donde participen al mismo tiempo más de 30 desarrolladores de distintas especialidades, realmente no hace falta la complejidad de separar frontend y backend
  Cuando era freelancer, llegué a sobrediseñar cosas inútilmente incluso para equipos de 1 o 2 personas, pero hoy en día simplemente uso Django con un poco de Tailwind encima

  • Este año contratamos desarrolladores Django, y casi todos los postulantes hacían un backend API delgado con Django y armaban el frontend en grande con React (incluso muchos metían la lógica de negocio del lado del frontend)
    Cuando les preguntábamos por qué, casi nadie sabía explicarlo
    Al final terminamos quedándonos solo con los pocos candidatos que usaban renderizado del lado del servidor

  • Si de verdad necesitas un frontend muy interactivo, entonces sí puede que tengas que pensarlo más

  • También estoy de acuerdo
    En la mayor parte de la industria, a los clientes les importa poco si realmente necesitas hiperescala y microservicios, o si con un monolito y PostgreSQL basta

• Parece que mucha gente persigue solo lo más nuevo y arma setups pensando en escalado infinito
  En realidad, Rails es muy útil incluso con un diseño simple, y muchas veces la gente sobreingenieriza solo porque “es aburrido” o “no es divertido”
  Pero Rails de verdad viene con baterías incluidas, y si dejas el overengineering, simplemente funciona

  • Volví a Rails después de mucho tiempo y al principio fue duro porque tuve que subir un proyecto de más de 10 años de Rails 5 a 8, pero desde entonces, para nuevos proyectos SaaS/CRUD, solo uso Rails
    En algún momento la productividad empezó a parecerme el valor más importante

• Lo único nuevo es que ahora todo se volvió más complejo; estas ideas en sí no tienen nada de nuevo
  Cuando aprendí Django hace 15 años, los tutoriales te exigían instalar cierta versión de Vagrant, VirtualBox y Chef, y casi me vuelvo loco
  Sigo queriendo y usando Django hoy, pero no le presto atención a esas herramientas
  Django Rest Framework también terminaba siendo más una distracción que una ayuda

• La “fatiga por el tooling de desarrollo web” es totalmente real

  • Ya era real hace 10 años, y este tipo de caos normalmente surge cuando los desarrolladores llevan sus gustos de hobby al trabajo
    Y para agregar, no pasa solo en frontend; en DevOps la situación es parecida

  • Como resultado, para postularte en esas áreas parece que tienes que saber todas las herramientas, además de tener 10 años de experiencia, varios backends, SQL y hasta Docker

  • Si te dedicas a esto profesionalmente, lo configuras una vez y listo, pero para proyectos puntuales o si el desarrollo web no es tu trabajo principal, claramente sí puede ser agotador
    Aun así, se puede evitar de esta manera
    Yo hice un sitio web con el framework Fresh(https://fresh.deno.dev/) y con eso fue suficiente
    En general fue mucho más simple que la combinación Node/Webpack, y además pude usar Typescript y TSX
    Si hubiéramos trabajado varias personas, quizá habríamos agregado algo como ESLint, pero incluso sin eso fue facilísimo empezar