Você está usando Rails do jeito errado

• A conversa entre dois desenvolvedores sobre a integração do Rails 8 com Vite satiriza o ambiente moderno de desenvolvimento web, que ficou desnecessariamente complexo
• Um deles vai adicionando inúmeras ferramentas como Vite, React, Babel, Tailwind, Docker e Husky, dizendo que isso forma uma stack “moderna”
• Já o outro mostra um app que roda imediatamente só com Rails puro, sem nenhuma configuração, destacando a utilidade da simplicidade
• Ao ironizar a situação atual, dependente de cadeias de ferramentas complexas, o texto reforça a mensagem “simplesmente use Rails” e faz retomar a virtude da simplicidade
• Aponta que o propósito original do Rails — produtividade, consistência e prazer em desenvolver — está sendo esquecido
  > “Just F#$%^& use Rails”

---

Tradução do diálogo original

Kevin: Ei, você já usou Vite com Rails 8? É muito rápido.

John: Já ouvi falar. É uma ferramenta de build, né? O Rails já não tinha algo assim?

Kevin: Tinha. Mas o Vite é mais moderno. Você precisa instalar Node e npm e configurar alguns scripts, mas vale a pena.

John: Espera aí, agora o Rails precisa de Node?

Kevin: Precisa se você for usar React. Hoje em dia todo mundo usa React.

John: O Rails já não tinha algo para isso?

Kevin: Tinha, mas agora você tem que usar Vite junto com React Refresh. Aí os componentes atualizam na hora. E se quiser usar TypeScript, também tem que configurar isso.

John: Só de ouvir já parece complicado.

Kevin: Não, é tranquilo. Você instala Babel, configura o .babelrc, adiciona vite-plugin-ruby e, para estilos, usa PostCSS.

John: PostCSS?

Kevin: Isso. E claro que também tem que usar Tailwind — fala sério, você não vai querer escrever CSS na mão, né?

John: Claro que não.

Kevin: Depois você organiza o código com ESLint e Prettier e, antes do commit, coloca hooks com Husky para ficar perfeito.

John: Então temos Vite, React, Babel, PostCSS, Tailwind, ESLint, Prettier e Husky. É só isso?

Kevin: Quase isso. Se quiser renderização no lado do servidor, tem que usar Next.js ou Remix.

John: Espera, a gente ainda está falando de Rails, certo?

Kevin: Está sim. Hoje em dia stack híbrida é o que manda! Se você quiser componentes reativos sem framework JS, StimulusReflex ou Hotwire também são boas opções.

John: StimulusReflex? Parece nome de personagem da Marvel.

Kevin: Haha, mas existe mesmo. É para atualizações em tempo real. Só que aí você precisa configurar ActionCable e também Redis.

John: Redis?

Kevin: Sim, porque precisa de uma camada de pub/sub. Relaxa, é só subir mais um container Docker.

John: Também tem que usar Docker?

Kevin: Claro. É essencial para isolar dependências. E, para reproduzir o ambiente completo, você ainda precisa de Docker Compose, deploy na Fly.io e um pipeline com GitHub Actions.

John: Isso... parece bem complicado.

Kevin: É só desenvolvimento web moderno, amigo. Simples. E você, o que está fazendo?

John: Só estou mexendo aqui.

(John executa um único comando. O app sobe imediatamente. O formulário funciona, o carregamento é rápido e a navegação é veloz como um raio.)

Kevin: Uau, parece bem complexo. Que stack você usa?

John: Só Rails puro.

> Just F#$%^& use Rails.

[labeldock]

Eu gosto de todas as ferramentas. As duas têm partes do ecossistema e dos objetivos que se cruzam, mas não são exatamente a mesma ferramenta, então não deveriam ser avaliadas com base na dificuldade. Se você escrever com Vite, dá para criar scripts de forma ampla e sofisticada. Já Stimulus ou Hotwire são mais adequados para minimizar o desenvolvimento de scripts.

[roxie]

Parece que a maior parte do conteúdo está focada em desenvolvimento frontend...

[GN⁺]

Comentários do Hacker News

• Este texto vem sendo reescrito há mais de 10 anos
  A chamada “complexidade” nada mais é do que uma lista de ferramentas que resolvem problemas específicos
  As ferramentas em si não são o problema; a realidade é que existe uma complexidade inerente ao desenvolvimento web moderno
  Dá para ver uma complexidade “oculta” parecida em ASP.NET ou em frameworks de GUI para desktop
  Por exemplo, se você usa Rails como backend de API e deixa o frontend com React, isso vira uma arquitetura completamente diferente de um monólito Rails tradicional
  Uma lista de ferramentas como Vite, React e Prettier corresponde a escolhas voltadas para problemas totalmente diferentes (se você quer usar Rails no frontend, então use só Rails; não sou muito fã de soluções intermediárias)
  O verdadeiro problema é a forma de aprendizado
  Hoje em dia, muitos desenvolvedores aprendem frameworks antes de dominar o básico da web (HTML, CSS, lógica server-side, banco de dados)
  Cada ferramenta existe por um motivo, e todas são ferramentas necessárias na web moderna
  Enxergar isso como “tem coisa demais” é não entender direito a realidade da indústria

  • Complexidade não é algo inerente ao desenvolvimento web
    Pelo contrário, hoje dá para fazer mais com menos
    O Hotwire funciona quase como Rails puro, e permite montar uma experiência moderna com conteúdo sendo atualizado em tempo real via WebSocket com praticamente uma linha
    A forma comum de servir JS no Rails também ficou bem mais simples graças a import maps (sem precisar de uma etapa separada de build)
    Também é muito fácil adicionar Tailwind
    Até o deploy ficou muito mais simples com o kamal
    Então não concordo com a ideia de que a complexidade é inerente, e o Hotwire serve justamente para reduzi-la
    O aprendizado deveria seguir a direção de “fazer mais com menos”, não de “aprender cada vez mais coisas”
    Saber usar 4 coisas e, em um time de 3 pessoas, superar mil outras vale mais do que saber 20 linguagens ou servidores

  • Acho que as pessoas não são contra a existência das ferramentas em si, mas contra o clima de que todo mundo é obrigado a usar tudo isso
    Todo tutorial e todo título de vídeo no YouTube aparece como “A stack MONGOOSE que você PRECISA usar!”, então acaba surgindo um monte de iniciante tentando enfiar redis à força em um blog de receitas
    Na prática, a maioria dos sites funciona muito bem sem nenhuma stack especial
    Mas como ninguém anuncia isso, muitos desenvolvedores juniores nem sabem dessa realidade
    Concordo que o aprendizado das tecnologias básicas deveria vir primeiro, mas é difícil passar essa mensagem no meio de tantas empresas promovendo seus próprios serviços

  • Sou bem iniciante em Rails, mas tenho cerca de 10 anos de experiência com outras linguagens
    Adicionar ferramentas quando necessário é ok (se elas são realmente necessárias já é outra discussão)
    Mas o Rails, por natureza, já é um framework gigantesco e faz-tudo, que inclui de ORM a console e geração de código por scaffolding
    Se ainda é preciso adicionar mais ferramentas, não seria o caso de repensar o próprio Rails?
    Talvez algo mais modular fosse melhor
    A expressão “Rails puro” me soa como um sinal de alerta. É difícil chamar de “puro” um framework tão grande assim

  • A ideia central deste texto é que muita gente nem chega a se perguntar se precisa de uma “aplicação web moderna” desde o começo e nem sabe que só Rails puro já pode ser suficiente
    Falta esforço para entender as escolhas padrão do Rails puro por conta própria

  • Mencionar a “complexidade do desenvolvimento web moderno” é apenas descrever um problema, não uma exigência
    Se você está puxando milhares de pacotes npm para um site que basicamente é um banco de dados com algumas queries SQL, então está fazendo algo errado

• Escrevo código em Rails desde 2007
  A stack ficou mais complexa por bons motivos, e praticamente não existe time algum que tenha feito tudo “do jeito certo” segundo os critérios do texto
  O problema de um framework omakase (como Rails, que decide muita coisa por você) é que não são só as escolhas iniciais: você acaba tendo que acompanhar também as escolhas posteriores e arrastar o time inteiro junto
  Rails é poderoso, mas nem seus mantenedores conseguem prever o futuro perfeitamente
  Por isso, hoje quase não existem apps que tenham voltado para Rails puro
  Antigamente, antes do Docker, fazer deploy de Rails era realmente um saco. Em vez de rsync ou tarball, você precisava de um sistema de deploy como Capistrano.
  Docker e k8s são práticos, mas comparados ao passado não são exatamente piores

  • Se a sua lembrança de deploy de Rails na era pré-Docker é “dar rsync e extrair um tarball”, então era uma configuração realmente horrível
    Fazer deploy com o “Capistrano de antigamente” era muito melhor

  • Eu gostaria que explicassem de forma mais concreta qual era exatamente o problema de “fazer push para várias instâncias com rsync ou tarball”
    Pelo que parece, não soa tão grave assim

  • É por isso que sempre tive um carinho especial pelo Sinatra

• É uma pena que as utilidades prontas que o Rails oferece ainda não tenham substituto no mundo JS
  A maioria dos desenvolvedores JS não percebe isso muito bem
  Mas JS sempre foi um ecossistema de reinventar a roda

  • Uma grande vantagem de JS é que todo mundo tem a chance de criar uma nova plataforma
    O fato de várias plataformas JS poderem ser combinadas ao mesmo tempo e ainda assim funcionarem mais ou menos faz com que tudo seja muito escalável, hackeável, e até permita gerar um site fixo inteiro com builds locais permanentes
    Mas essa liberdade exige contenção
    Cabe ao time impedir aquele colega que quer introduzir um novo framework a qualquer momento

  • Ember.js é um framework all-in-one (“baterias incluídas”) criado por nomes grandes do ecossistema Rails
    Ainda assim, existe um motivo para ele não ter tido o mesmo sucesso que outros frameworks

  • No ecossistema JS também existem frameworks backend com tudo incluído, como AdonisJS
    Só que o ecossistema NodeJS surgiu a partir de microframeworks, como uma reação contra frameworks mais engessados como Rails ou Django
    O conceito do Express também era algo como fazer rápido e sem muito rigor

  • Também existem vários frameworks full stack em JS parecidos com Rails
    Existe até um framework chamado Sails
    O JS resolve problemas diferentes dos que o Rails resolve, então os frameworks inevitavelmente acabam tendo outra cara

  • O Rails tem muitas utilidades, mas no longo prazo pode ser cansativo ter que atualizar a base de código periodicamente e continuar acompanhando as tendências do próprio Rails

• Stimulus e Hotwire agora já se estabeleceram como o “rails way”
  Mesmo lendo a documentação com atenção, ainda acho tudo confuso demais
  Fica uma sensação estranha de estar recriando componentes JS na mão o tempo todo
  Na minha opinião, a combinação Rails 8 + Inertia.js + React acaba evitando mais a “reinvenção da roda”, ainda mais usando componentes do shadcn

  • Concordo com isso
    Nós também trocamos um frontend em Hotwire por Inertia, e a diferença é absurda
    A menos que você esteja fazendo um projeto pequeno 100% sozinho, Hotwire vira rapidinho uma bagunça que ninguém do time consegue mexer direito

  • Eu, pelo contrário, gostei tanto do Stimulus que saí usando direto num app Phoenix em seguida
    Mas acho que o problema está no mal-entendido em torno da ferramenta
    Stimulus não é uma alternativa ao React
    Se você está acostumado com apps JS de dezenas de milhares de linhas, React pode realmente ser a escolha certa
    Mas quando o servidor é o protagonista da aplicação e você só quer melhorar a UX com algumas dezenas de linhas de JS, o Stimulus é perfeito
    No Phoenix, ele entra como uma solução minimalista exatamente entre HTML estático e LiveViews dinâmicas
    Ninguém nunca disse que Stimulus serve para construir SPA, e acho óbvio que isso acabaria sendo doloroso

  • O Stimulus é realmente pequeno, um sistema de eventos com hooks em HTML, e combina bem com o ciclo de request do Rails
    Fico curioso se alguém já conseguiu construir com sucesso algo realmente complexo usando Stimulus
    A minha impressão é que ir tão longe com ele acaba sendo difícil demais

  • Também sou daqueles bem fãs de Rails, mas me decepciona a situação atual de Stimulus e Hotwire
    O conceito é excelente e a implementação talvez até seja boa
    Só que a documentação é absurdamente insuficiente, a ponto de desanimar desde o começo, e em cada projeto falta informação para responder à pergunta: “se eu começar com isso, vou acabar preso num beco sem saída depois?”

  • Já usei Stimulus com Symfony para pequenas interações e achei bem legal, com uma API pequena e bem projetada
    Ainda não usei o conjunto completo Turbo/Hotwire e, para páginas complexas ou com muito estado, geralmente uso Vue

• De qualquer forma, projetos greenfield hoje quase desapareceram
  Tirando fundadores, greenfield em si já é raro, e se você está vendendo alguma coisa, em 99% dos casos isso acaba virando um wrapper de Shopify ou algo parecido
  Mesmo em grandes empresas, projetos greenfield vêm presos a várias considerações e frameworks internos, então ninguém começa simplesmente com rails new
  Essa discussão tem pouca utilidade, e essas polêmicas e textos parecidos se repetem há 10, 15, 20 anos; já cansou e ficou entediante
  Em vez de mais um texto novo, eu preferia que construíssem algo realmente novo

  • Concordo totalmente
    Trabalhei 10 anos com Ruby/Rails, e até a base de código mais “nova” com que mexi já tinha mais de 5 anos
    Para ser sincero, até já criei um app greenfield em Rails, mas era um microsserviço só de API, então nem precisava de frontend
    Em empresas de certo porte, a solução de frontend do Rails é simplesmente ignorada
    Pode ser difícil achar engenheiros que saibam Hotwire, mas desenvolvedores React ou Vue você encontra aos montes
    A stack de FE do Rails também muda com frequência e é difícil acompanhar (por exemplo, eu lembro da época do CoffeeScript), quase não tem documentação decente e, na prática, tem pouca influência
    Por isso, essa discussão toda soa desconectada da realidade

  • Não concordo com a afirmação de que “projetos greenfield não existem mais fora dos fundadores”
    Se você usar apenas como exemplo grandes monólitos antigos de empresas gigantes ou Fortune 500, isso vira um recorte minúsculo e fora da média
    Pelo contrário, acho impressionante o cuidado do rails new em montar defaults sensatos e prontos para uso
    Essa abordagem preenche muito bem o espaço entre um Hello World e uma documentação de API simplista demais
    Mesmo que você não use Rails, isso é algo que vale a pena imitar

• É bonitinho, mas isso não fala da realidade de um app Rails que, conforme evolui, precisa migrar continuamente entre bundler, webpacker, sprockets, Propshaft, importmaps, jsbundling e por aí vai
  De autoloader para zeitwerk, de Turbo para Hotwire, e por aí segue: na prática, muita coisa mudou desse jeito
  Basta olhar até os anúncios em newsletters de Rails, cheios de “especialistas ajudam você a fazer upgrade do app Rails”

  • Ainda bem que alguém mencionou isso
    É fácil dizer “é só usar Rails puro”, mas ao longo dos últimos 5 anos, cada versão do Rails mudou completamente a forma de gerenciar JS
    Ainda existem muitas gems dependentes de sprockets, então mesmo seguindo o jeito Rails você acaba inevitavelmente com uma massa complexa de JS
    A situação agora está realmente confusa. Talvez melhore um dia, mas o Rails claramente também tem sua parcela de responsabilidade

  • E não dá para esquecer CoffeeScript
    Até recentemente, a empresa em que trabalhei ainda adiava a migração de CoffeeScript, enquanto escrevia código novo em Vue

• Pela minha própria experiência, se o projeto não envolve mais de 30 desenvolvedores trabalhando ao mesmo tempo em áreas especializadas, então não há necessidade da complexidade de separar frontend e backend
  Na época em que eu fazia freelas, cheguei a superprojetar soluções desse tipo até para times de 1 ou 2 pessoas, mas hoje em dia acabo usando só Django com um pouco de Tailwind

  • Este ano fizemos uma contratação de desenvolvedor Django, e quase todos os candidatos construíam um backend de API fino com Django e um frontend grande em React (muitas vezes até empurrando a lógica de negócio para o frontend)
    Quando perguntávamos o motivo, quase ninguém conseguia explicar
    No fim, sobraram só os poucos candidatos que usavam renderização server-side

  • Se você realmente precisa de um frontend muito interativo, aí talvez valha a pena pensar melhor no que fazer

  • Também concordo
    Na maior parte da indústria, o cliente não liga muito para saber se você precisa de hiperescala e microsserviços ou se um monólito com PostgreSQL já resolve tudo muito bem

• Parece que muita gente vai atrás só das tecnologias da moda e prepara tudo pensando em escala infinita
  Na prática, Rails continua sendo muito útil com uma arquitetura simples, e muita gente acaba caindo em overengineering por achar tudo “entediante” ou “sem graça”
  Mas o Rails realmente já vem com tudo incluído e, se você parar de complicar demais, ele simplesmente funciona

  • Voltei para Rails depois de muito tempo e tive que atualizar um projeto de mais de 10 anos do Rails 5 para o 8, então no começo foi bem difícil, mas depois disso passei a usar só Rails para projetos novos de SaaS/CRUD
    Chega uma hora em que produtividade vira o valor mais importante de todos

• Hoje está mais complexo, mas essas ideias em si não têm nada de novo
  Quando fui aprender Django, 15 anos atrás, o tutorial exigia instalar uma versão específica de Vagrant, VirtualBox e Chef, e eu quase enlouqueci
  Ainda gosto e continuo usando Django, mas nem perco tempo com essas ferramentas
  Django Rest Framework inclusive mais atrapalhava meu foco do que ajudava

• O “cansaço com tooling de desenvolvimento web” é algo muito real

  • Já era real 10 anos atrás, e essa confusão normalmente é resultado de desenvolvedores levando gostos de hobby para o ambiente de trabalho
    E vale dizer: não é só o frontend, com DevOps a situação também é parecida

  • Como resultado, para se candidatar a áreas relacionadas, virou quase obrigatório conhecer todas as ferramentas, ter 10 anos de experiência, dominar vários backends, SQL e ainda Docker

  • Se você trabalha com isso de forma profissional, monta uma vez e segue em frente, mas para projeto pontual ou para quem não tem desenvolvimento web como atividade principal, isso realmente cansa
    Ainda assim, dá para evitar esse caminho
    Eu fiz um site com o framework Fresh(https://fresh.deno.dev/) e só isso já bastou
    No geral, foi muito mais simples do que a combinação Node/Webpack, e ainda dava para usar Typescript e TSX
    Se tivesse mais gente trabalhando junto, talvez eu adicionasse algo como ESLint, mas mesmo sem isso foi muito fácil começar