- Ao criar o app de gerenciamento de setlists (setlist.rocks) da banda, o autor redescobriu o prazer de desenvolver com Ruby on Rails depois de muito tempo
- O Rails 8 mais recente mantém a estrutura MVC tradicional, mas foi modernizado com um frontend “no-build” baseado em Hotwire (Stimulus·Turbo) e com Solid Cache/Queue/Cable
- O SQLite foi otimizado a ponto de ser adequado para uso em produção apenas com a configuração padrão, e a ferramenta de deploy Kamal simplificou o deploy sem downtime baseado em contêineres
- Graças à filosofia do Rails de “convenção em vez de configuração” e ao rico ecossistema de gems, é possível ir rapidamente da ideia ao protótipo
- Embora a popularidade de Ruby e Rails tenha diminuído em relação ao passado, eles ainda oferecem a alegria de programar como um framework OSS maduro e consistente
Projeto paralelo e o retorno ao Rails
- Para gerenciar os setlists e as notas das músicas da banda, o autor desenvolveu o próprio webapp, buscando uma forma mais eficiente do que planilhas ou chats existentes
- Durante o desenvolvimento, voltou a sentir a simplicidade e a produtividade do Rails e comentou que, em comparação com o ecossistema web recente, isso lhe trouxe a “pura alegria de desenvolver”
- Ruby continua sendo avaliada como uma linguagem com sintaxe natural e expressiva, fácil de transformar pensamento em código
- Segundo a pesquisa Stack Overflow 2025, a popularidade de Ruby e Rails caiu, mas eles ainda são preferidos em projetos pessoais
Mudanças no Rails 8 e frontend
- O Rails 8 mantém a estrutura MVC existente, mas também oferece integração de frontend baseada em Hotwire (Stimulus·Turbo)
- O Turbo intercepta cliques em links e envios de formulários para oferecer reatividade em nível de SPA
- O Stimulus adiciona comportamento JavaScript apenas onde é necessário, permitindo criar uma UI interativa com o mínimo possível de JavaScript
- Com a introdução do Importmap, é possível carregar bibliotecas JS diretamente de uma CDN sem Webpack nem npm
- O autor usou ferramentas de IA para gerar a UI, mas também expôs seu dilema entre criação e a dimensão artística do código
Fluxo de desenvolvimento e produtividade
- Com a filosofia do Rails de “Convention over Configuration”, é possível montar rapidamente modelos, rotas, controllers e views
- Como exemplo, ele demonstra o processo de criação do modelo
Tag, automação de rotas RESTful e tratamento de respostas JSON
- Com templates ERB e live reload, é possível prototipar rapidamente
- O rico ecossistema de gems permite integrar com facilidade várias funcionalidades, como CSV e PDF
Melhorias de backend: série Solid* e SQLite
- Solid Cache/Queue/Cable vêm incluídos por padrão no Rails 8, permitindo processar cache, fila de jobs e WebSocket sem Redis
- O Solid Cache faz cache com base no banco de dados, economizando RAM e simplificando a arquitetura
- O Solid Queue gerencia jobs em background com base no banco de dados e roda apenas com a configuração
SOLID_QUEUE_IN_PUMA=1
- O Solid Cable oferece suporte a recursos em tempo real como adaptador do Action Cable baseado em banco de dados
- No SQLite, otimizações como modo WAL e sincronização NORMAL são aplicadas por padrão via configuração
pragmas: no database.yml
- Mesmo sem um servidor de banco de dados separado, ele pode ser usado de forma prática em pequenos ambientes de produção
Automação de deploy e Kamal
- Ao mencionar a complexidade dos deploys antigos com Capistrano e Ansible, o autor apresenta o Kamal como a ferramenta de deploy padrão do Rails 8
- Ele automatiza o processo de build de contêiner → push → deploy no servidor → health check → troca sem downtime
- O kamal-proxy cuida da troca de tráfego e do tratamento de SSL
- O arquivo
.kamal/secrets oferece suporte ao gerenciamento seguro de segredos com base em variáveis de ambiente
- Integrado ao GitLab CI, o deploy pode ser feito apenas com
git push, recriando a simplicidade do antigo Heroku
Autenticação e outros recursos
- O Rails 8 oferece um gerador de autenticação embutido (auth generator), permitindo montar um sistema de autenticação mais simples do que com o Devise
- O Devise ainda é útil graças aos seus recursos abundantes e à boa documentação, mas a simplicidade da autenticação nativa do Rails também é vista como um atrativo
Estado atual e continuidade do ecossistema Rails
- Embora a popularidade de Ruby e Rails tenha diminuído, grandes serviços como Shopify, Basecamp, SoundCloud e GitHub ainda os utilizam
- Muitas gems estão em fase de manutenção, mas o Rails mantém um ciclo consistente de lançamentos anuais
- Ele é avaliado como um “framework em que menos novos desenvolvedores estão entrando, mas no qual ainda é divertido desenvolver”
Conclusão
- Embora o Rails esteja distante das tendências mais recentes, ele é destacado como uma ferramenta que devolve a alegria e a simplicidade de desenvolver
- Em vez da popularidade, o texto valoriza o prazer de criar e a criatividade, encerrando com a mensagem: “tente Rails mais uma vez”
4 comentários
Se for Rails, lembro que era "convenção em vez de configuração", não "configuração em vez de convenção"...
> most of the web frameworks I’d (...) required endless amounts of XML boilerplate and other configuration to wire things up. Rails jogou tudo isso fora e introduziu a noção de “convenção em vez de configuração”
Parece que o LLM gerou a saída exatamente na ordem de entrada, sem alterar a ordem das palavras. No original, está correto.
O LLM erra nessas coisas. Já corrigi. Obrigado.
Comentários do Hacker News
Gosto muito de Rails, mas depois de trabalhar em uma base de código grande sem tipos estáticos, ficou difícil voltar para Rails fora de projetos pessoais
Uma base grande sem tipagem é um pesadelo de manter, mesmo com uma IDE poderosa como o RubyMine
Fico curioso para saber o quanto o Sorbet evoluiu hoje em dia, especialmente em combinação com RoR
Ele segue bem a filosofia do Rails e ainda facilita aprender Rust
Parece valer a pena testar num fim de semana
Você acaba tendo que copiar dados reais de produção para o ambiente local ou entrar por SSH no servidor para inspecionar o estado via REPL
Depurar na IDE foi uma experiência infernal
Eu realmente amava Ruby, mas depois de passar por depuração em tempo real ficou difícil
Agora já não há motivo para escolher Ruby ou Python de propósito
Python deve resistir mais um pouco por causa de ML, mas acho que no fim vai desaparecer
Também fico feliz que alguém diga isso em público
Estou cansado da atual obsessão por arquitetura de microsserviços
À noite, mexo em projetos que simplesmente resolvem o problema sem estrutura desnecessária
Antigamente lidava muito com estruturas em PHP, mas no fim tanto Rails quanto PHP são só ferramentas para resolver problemas
Parece desenvolvimento em IDE desktop de antigamente, com tudo funcionando “dentro da caixa”
Dá a sensação de recuperar a simplicidade focada em produtividade, longe da gestão de peças complicadas do desenvolvimento web
Além disso, é ótimo não precisar usar TypeScript. Acho TypeScript verboso e cheio de boilerplate desnecessário
Operamos apps Rails em produção continuamente desde 2007
O segredo da longevidade do Rails não está na idade, mas na estabilidade e praticidade
A ideia de que usar JavaScript no backend aumenta a eficiência já foi refutada
A maioria das mudanças de stack acontece por otimização de currículo ou ansiedade de tendência, não por necessidade real de engenharia
Rails segue tocando negócios de verdade em silêncio
Ninguém realmente acredita que os 3,1 milhões de pacotes do NPM oferecem mais funcionalidade que os 190 mil do RubyGems
Estamos migrando para Inertia + Vue.js, e é uma combinação tão forte que quase não precisamos mudar o backend
O ganho de produtividade compensa até a dificuldade de contratar
Quanto mais usuários, mais saudável tende a ser o ecossistema
Mas como também há muitos pacotes antigos no RubyGems, acho difícil fazer uma comparação direta
Gosto da filosofia "batteries included" de RoR ou Django, mas manter projetos antigos consome muito tempo
Atualizar um projeto de 5 ou 6 anos torna o gerenciamento de dependências um peso grande
Por isso, hoje prefiro usar frameworks simples em Go, ou até desenvolver sem framework nenhum
Se você usa só as bibliotecas realmente necessárias, a manutenção fica fácil
Tirando patches de segurança, fico me perguntando por que seria preciso atualizar tanto
Nos últimos 18 meses subi 5 versões major, e ainda assim foi relativamente simples
Se você montar tudo com cuidado no início, quase não precisa mexer por muito tempo
Acho que a experiência de upgrade é subestimada
No Next.js a estrutura muda completamente a cada versão major, enquanto no Rails o ciclo gradual de depreciação é mais lento e muito mais estável
Ao manter um produto em entrega contínua, estabilidade de interface importa muito mais do que o paradigma mais recente
A transição do Next.js de pages para app router foi praticamente uma replataformização completa
Já o Rails tem caminhos de upgrade documentados e ciclos de depreciação previsíveis
O gerenciamento de versões do Ruby, com rbenv/asdf, também quase elimina problemas de incompatibilidade de ambiente
Trabalho com Rails há mais de 10 anos, de DevOps a desenvolvedor web solo, e faria a mesma escolha de novo
Rails é um framework limpo e produtivo que já vem com tudo
Mesmo na pesquisa do Stack Overflow, ele ainda apareceu no Top 5 de “stacks que eu gostaria de usar no próximo projeto”
Quase não é preciso se preocupar com configurar infraestrutura, e o deploy também é simples
No fim, o que importa não é a opinião dos outros, mas usar a ferramenta certa para você
Saiu um ano antes do Django
Link da pesquisa
Antigamente eu achava que Ruby/Rails era a solução ideal para a maioria dos problemas, e ainda continuo achando isso hoje
Nunca usei Rails, mas me identifico com a confusão do ambiente atual de desenvolvimento web
Por isso escolhi Elixir e Phoenix olhando para o futuro
Com certeza quero testar no próximo projeto
O que em Elixir é tão atraente, e em que vale prestar atenção quando se tem o primeiro contato?
Há 10 anos construímos o frontend de streaming de uma grande emissora sueca com Rails
No Heroku, atendemos mais de 1 milhão de usuários simultâneos, e funcionou muito bem
Depois migrei para outras áreas, como infraestrutura de streaming, API e AI/ML, mas não porque Rails tivesse falhado, e sim porque a natureza do problema mudou
Rails serve bem para problemas centrados em modelo de dados e lógica de negócio, enquanto problemas centrados em concorrência ou infraestrutura combinam melhor com outras linguagens
Ruby ainda é uma linguagem bonita e expressiva, e sinto muita falta dela
Mas acho difícil abandonar totalmente o viés pessoal por uma linguagem de que gostamos
Fico curioso sobre qual linguagem você escolheu para o projeto seguinte
Para quem sente falta de tipagem estática, há excelentes soluções como Sorbet
Dá para aproveitar ao mesmo tempo a produtividade do Ruby, tipagem estática e integração com LSP
Graças à Shopify, o suporte ao Sorbet no Rails também é muito bom
Eu ainda gosto tanto desse ecossistema que adoraria continuar trabalhando com Rails
Com o avanço das ferramentas de AI, acho que agora o único limite é o tamanho da imaginação
Com base nele, criei um agente de e-commerce que monitora a loja 24 horas por dia e envia alertas no Slack
Se você vai fazer projetos relacionados a AI, vale a pena dar uma olhada em selzee.com/openclaw