Por que escolhi Elixir Phoenix em vez de Rails, Laravel e Next.js

 (akarshc.com)
7 pontos por GN⁺ 2025-10-18 | 3 comentários | Compartilhar no WhatsApp
  • O Phoenix LiveView oferece alta eficiência tanto em desempenho da aplicação quanto em velocidade de desenvolvimento
  • Uma vantagem é poder trabalhar de forma monolítica com uma única linguagem, sem precisar manter frontend e backend separadamente
  • Rails Hotwire e Laravel Livewire também foram considerados, mas exigem mais configuração para implementar recursos em tempo real e tarefas em segundo plano
  • O framework Phoenix do Elixir mantém a elegância do Ruby on Rails, mas oferece desempenho muito superior, com tarefas em segundo plano via Oban já integradas e uma sintaxe familiar e limpa
  • O LiveView oferece atualizações bidirecionais em tempo real com base em WebSocket, equilibrando renderização tradicional no servidor e frameworks centrados em frontend, além de permitir o uso de Alpine.js ou bibliotecas JavaScript via hooks quando necessário
  • Velocidade de desenvolvimento, alto processamento concorrente, possibilidade de escrever quase tudo em uma única linguagem, prevenção antecipada de bugs pelo compilador e arquitetura tolerante a falhas com base em Elixir/Erlang foram os fatores decisivos na escolha final

Por que escolhi o Phoenix LiveView

  • O objetivo de programar é resolver problemas da forma mais ideal possível, e os fatores mais importantes aqui são desempenho da aplicação e eficiência no desenvolvimento
  • Ao usar React ou Next.js com Laravel, ou Inertia.js com Laravel, é preciso manter toda a stack de frontend e backend
  • Como desenvolvedor solo, não havia tempo para gerenciar estado em dois lugares diferentes, então era necessária uma solução monolítica robusta capaz de lidar com tudo junto

  • Comparação de alternativas: Laravel Livewire, Rails Hotwire, Next.js

    • Laravel Livewire e Rails Hotwire são ótimas ferramentas para simplificar o trabalho de frontend sem depender fortemente de JavaScript
    • Foi considerada uma stack totalmente em JavaScript com Next.js, mas não há preferência por usar JavaScript no backend
    • O Rails Hotwire chamou especialmente a atenção por sua capacidade de construir rapidamente um MVP com Rails
    • No entanto, havia necessidade de tarefas em segundo plano, atualizações em tempo real e comunicação bidirecional; isso também é possível em Rails e Laravel, mas exige mais esforço de configuração

  • Vantagens decisivas de Elixir, Phoenix e LiveView

    • Elixir e Phoenix mantêm a elegância do Ruby on Rails, ao mesmo tempo em que entregam desempenho muito mais alto
    • Jobs em segundo plano integrados via Oban, sintaxe familiar e legível, além da comunicação bidirecional em tempo real do LiveView, são pontos fortes
    • O LiveView encontra um equilíbrio ideal entre renderização no servidor e frameworks pesados de frontend
    • São possíveis atualizações em tempo real via WebSocket e integração com bibliotecas JavaScript (por exemplo, Alpine.js)
    • Com o Oban integrado ao Phoenix, fica fácil declarar jobs em segundo plano e fazer recuperação automática

  • Vantagens de Elixir/Erlang

    • Elixir é uma linguagem compilada construída sobre Erlang, base de sistemas de alta concorrência em larga escala como WhatsApp e Discord
    • Oferece alta concorrência, tolerância a falhas e recuperação automática diante de falhas

Motivos da escolha final

  • Desenvolvimento rápido e alto suporte à concorrência
  • Uma única linguagem para implementar quase tudo
  • Escrita de código legível
  • O compilador captura a maioria dos bugs antes de chegarem à produção
  • A arquitetura tolerante a falhas faz com que o app quase nunca fique fora do ar, garantindo a estabilidade da aplicação

Conclusão e conselho

  • O Phoenix não é necessariamente superior a Rails, Laravel ou Next.js em todos os casos
  • Todos os frameworks são excelentes, e já houve experiência de uso com cada um deles em diferentes projetos
  • Para a situação específica e o projeto (Hyperzoned.com), o Phoenix foi a escolha mais adequada
  • Se você explorar além do que já conhece, pode encontrar uma forma melhor e mais eficiente de resolver o próximo problema
  • Não pare de aprender

Leituras relacionadas

3 comentários

 
clastneo 2025-10-23

Pelo mesmo motivo do JSP, quando passa de um certo nível parece que não dá mais para usar.
 
GN⁺ 2025-10-18
Comentários no Hacker News

  • Já tive experiência integrando o CKEditor manualmente com Rails, Livewire, Phoenix e React. Entre eles, o Phoenix foi o mais impressionante em termos de experiência de desenvolvimento. O framework é muito bem projetado, então o trabalho de integração foi realmente simples. Não senti esse nível de satisfação nem com Rails nem com React, especialmente com Next.js. No Next.js, o roteador muda com frequência demais, e isso acontece tantas vezes que fica difícil confiar. O Livewire tem uma sensação parecida com a do Phoenix, mas é relativamente menos intuitivo e tem menos recursos. Por exemplo, o Livewire não oferece suporte a slots de componentes, enquanto o Phoenix lida com isso sem problema. Sem slots, a estrutura dos templates vira uma bagunça e o código fica desnecessariamente mais complexo. Se alguém tiver curiosidade, vale ver o repositório ckeditor5-phoenix no GitHub

    • A combinação de PHP (Laravel) com JQuery ainda é bem utilizável em 2025. Mas, pessoalmente, eu não gostaria de usar Livewire. Node.js pode ter produtividade menor, mas serve bem quando você precisa de recursos mais poderosos. Dá suporte a async/await, socket.io e TypeScript. O Next.js é útil quando você precisa tanto de SEO quanto de UI interativa, mas quantos sites realmente precisam de tudo isso ao mesmo tempo? Talvez só serviços como o LinkedIn se encaixem nisso

    • Não acho que o Livewire seja uma cópia do Phoenix. Pelo nome pode até parecer, mas pelo que sei os dois projetos começaram quase ao mesmo tempo, e o Livewire é até mais antigo. O Hotwire foi o último a surgir entre eles. Os dois projetos seguem abordagens diferentes, e PHP e Elixir têm características muito distintas. Também acho o Livewire bem útil. Como não é fácil usar WebSocket com PHP, ele funciona mais em cima de HTTP, e isso já basta na maioria dos casos. Na verdade, o WebSocket do LiveView pode até ser exagero

    • Tenho curiosidade sobre os problemas que você enfrentou com Rails. Queria ouvir mais especificamente o que foi difícil

    • Fiquei curioso sobre quais pontos foram complicados ao usar Rails

    • O Livewire 4 vai trazer suporte a slots de componentes. Mas ainda faltam algumas semanas. Dizem que a nova versão também traz melhorias de desempenho e de ergonomia de desenvolvimento

  • Este texto parece defender o framework escolhido pelo autor e ignorar de propósito recursos de outros frameworks. Tudo que foi citado como vantagem do Phoenix também existe no Rails. Além disso, o texto passa a impressão de que o Rails não oferece suporte à comunicação entre frontend e WebSocket, o que está completamente errado para qualquer pessoa que tenha desenvolvido apps com Rails nos últimos 3 anos. Claro, Phoenix e LiveView também são ótimas ferramentas, mas eu continuo usando Rails por causa do Hotwire Native. Ele me dá uma vantagem enorme de produtividade, porque consigo criar sozinho tanto apps mobile quanto web em pouco tempo

    • Não usei muito Ruby, mas fora a comunidade, tenho curiosidade sobre em que o Ruby on Rails é superior a Elixir & Phoenix. Por causa da plataforma BEAM, com tempo real suave, tolerância a falhas, NIFs, modelo de atores, enorme quantidade de processos leves, concorrência mais fácil de raciocinar, programação funcional, OTP e GC sem pausas, eu sempre achei que o Phoenix fosse teoricamente muito superior. Claro, cada um usa o que prefere, e eu também pretendo testar o Hotwire Native

    • Está claro que o Rails também consegue se comunicar com o frontend via WebSocket. Na prática, eu sou desenvolvedor Rails, mas se precisasse de um grande volume de conexões de socket persistentes, escolheria Phoenix. Com Phoenix dá para cobrir 100 mil conexões de socket de forma muito mais barata e simples em serviços como o Gigalixir. Se você gerenciar a própria infraestrutura, a conversa muda. Mas no Heroku é difícil até sustentar alguns milhares de conexões, e o custo pesa

    • Queria saber onde no texto foi dito que o Rails não oferece suporte à comunicação com o frontend por WebSocket. No original, só diz que "é algo possível tanto em Rails quanto em Laravel, mas exige um pouco mais de tempo de configuração". Isso tem um sentido completamente diferente

    • A combinação Rails + Hotwire também é muito poderosa, e com Hotwire Native fica ainda melhor. O ponto do texto não é que Phoenix e LiveView sejam melhores, e sim que a estrutura do LiveView (estado conduzido pelo servidor, isolamento de processos, canais leves etc.) é adequada em certos cenários. Os dois ecossistemas resolvem problemas parecidos de formas diferentes. O Rails segue pelo caminho da convenção e do aprimoramento progressivo, enquanto o Phoenix aposta na concorrência e na tolerância a falhas do BEAM. No fim, o que importa é qual estrutura se encaixa melhor no produto que você está construindo

    • Já tinha ouvido falar de Hotwire Native antes, mas depois parece que o assunto esfriou. Tenho curiosidade sobre experiência real em apps mobile, suporte, documentação e o nível de maturidade da implementação

  • Eu também tenho uma visão tão positiva sobre Elixir quanto o autor, mas como CTO, depois de 3 anos usando em produção, fui acumulando frustrações conforme a escala aumentava. O BEAM (concorrência, tolerância a falhas) cumpriu muito bem o que promete, e Ecto, Oban, iex remoto e o pool de talentos também foram excelentes. Mas a experiência de desenvolvimento (DX) foi se tornando um gargalo. Em um projeto grande com 300 mil linhas de código, tivemos problemas como:

    • Tempo de compilação: mesmo mudando uma única linha de código, a compilação no ambiente de desenvolvimento levava mais de 10 segundos e quebrava o ritmo
    • Ferramentas: o autocomplete do ElixirLS não era confiável, então eu perdia tempo procurando nomes de funções ou campos de schema
    • LiveView: não servia bem para UIs complexas, então fomos obrigados a adotar um frontend em React, e com isso a complexidade de GraphQL e da separação da stack acabou voltando
      Se você está pensando em uma stack para o longo prazo, talvez valha ler este retrospecto de 3 anos

    • Fiquei bem surpreso com essa parte de levar mais de 10 segundos para uma compilação no ambiente de desenvolvimento com Elixir. Eu sempre ouvi que o Elixir teria ainda mais vantagens que o Rails, então queria saber se casos assim são comuns no uso profissional

    • Tive uma experiência parecida aprendendo Elixir. Gostei da linguagem, mas trabalhando no Windows via WSL, o LSP quebrava com frequência e isso era bem incômodo. Espero que isso melhore bastante quando o LSP oficial for lançado

    • Se o frontend, seja com LiveView ou React, não for bem administrado, o código de um app grande vira bagunça rapidamente. Conforme a equipe cresce, revisão de código e limpeza de lógica desnecessária passam a ser indispensáveis. Acho que isso vale para qualquer framework. Ainda há muito espaço para melhorar

  • O texto afirma que "suporte leve a jobs em background, atualizações em tempo real e comunicação bidirecional é algo que tanto Rails quanto Laravel conseguem fazer com apenas um pouco de configuração extra", mas o Rails já traz suporte nativo com Solid Queue (jobs) e Solid Cable (mensageria em tempo real)

    • Como alguém que migrou recentemente para Rails, posso dizer que o SolidQueue é realmente muito simples de usar logo com a configuração padrão. Se você adicionar o Solid Queue Dashboard, ainda consegue visualizar toda a situação de uma vez só

    • Falando apenas de mensageria em tempo real, sinto que configurar o Solid Cable é mais trabalhoso que o LiveView. O LiveView já cuida até da renderização, então acho que ele está muito à frente do desenvolvimento com SolidCable no Rails

    • Tudo isso também dá para fazer com Rails. É um framework lindo, e com Phoenix fica mais fácil e agradável. Recomendo muito experimentar pelo menos uma vez

    • Falando como alguém que já usou Rails e Elixir em produção, os dois sistemas estão longe de ser equivalentes. O Oban tem um uso claro, e para reprocessar basta atualizar colunas no banco que o supervisor do Oban resolve tudo sozinho. No Solid Queue, não existe um jeito fácil de rerodar jobs bem-sucedidos. Também há tabelas demais, o que dificulta a administração. O Oban simplesmente trabalha com duas tabelas e opera naturalmente dentro do mesmo app, enquanto o Solid Queue exige mexer em configurações consultando vários posts de blog para funcionar direito. A configuração padrão deixa a desejar. Graças às características de Erlang/Elixir, o Oban consegue ser extremamente simples e ainda assim funcionar de forma excelente, o que é uma alegria como desenvolvedor. Acabo usando o Solid Queue por obrigação

  • Depois de muito tempo desenvolvendo com Rails, hoje em dia Phoenix/Elixir virou minha stack padrão. O Rails continua sendo imbatível para criar rapidamente apps CRUD, e nessa parte ele é claramente superior. Mas, conforme a complexidade aumenta e o tempo passa, Phoenix/Elixir acaba sendo a melhor ferramenta no geral

    • Desde a chegada dos LLMs, esse tipo de app simples já pode ser gerado em poucos minutos. Ainda assim, para as partes principais que exigem atenção, Phoenix me passa a sensação de oferecer mais controle

    • Gostaria de ouvir com mais detalhes em que aspectos ele combina mais com você e o que exatamente parece superior

  • Dá para sentir a paixão da pessoa na frase "nós escrevemos código para resolver problemas da melhor forma possível". Eu sou mais do tipo que fica satisfeito se o problema foi resolvido, então acho que faz mais sentido continuar no Rails

    • Dei risada quando li essa frase. Na prática, se você programar pensando só em otimização, o trabalho acaba andando mais devagar. Para mim, programar também é um meio de vida, e às vezes é só diversão mesmo

  • Muita gente diz que a comunidade de Elixir é pequena, mas ela está mirando um nível bem alto com bibliotecas de ponta. Isso me lembrou uma frase de um desenvolvedor antigo: "menos é mais". Também há muito open source bom, como elixir-dbvisor/sql

    • Em contrapartida, o ecossistema JS parece grande demais e isso cansa. Existem 10 bibliotecas diferentes, cada uma isolada, e ninguém segue padrão nenhum. É como escolher num hipermercado americano ou ser forçado a escolher numa rede de restaurantes da Vercel

  • Se você quiser sentir a real força do Elixir, recomendo assistir a todas as palestras do Saša Jurić

    • Saša Jurić é o autor do livro 'Elixir in Action', e o livro também é excelente

  • Este texto está mais focado em Phoenix LiveView do que no framework Phoenix como um todo. Na prática, eu não gosto do fato de que, mesmo tirando o LiveView das opções de geração, ainda sobra código padrão de LV espalhado por todo lado

    • Também concordo que o LiveView é muito opinativo e cheio de boilerplate. Eu gosto da concisão e da expressividade do Elixir, e o LiveView me parece o oposto disso

  • O único motivo de eu não ter escolhido Elixir foi a falta de um verificador de tipos. Gostaria de saber se houve alguma mudança nisso
 
colus001 2025-10-18

É verdade que o Livewire é divertido, mas basta a UI ficar um pouco mais complexa para virar um inferno. A partir desse momento, o Phoenix perde claramente suas vantagens. Como fica mais difícil quanto mais longo é o ciclo, eu não consigo recomendar muito.