Dev & EngARTIGO

Parser Herb de Marco Roth deve unificar leitura de HTML e ERB no Rails 8.2

Parser Herb de Marco Roth deve unificar leitura de HTML e ERB no Rails 8.2
Imagem gerada por IA
Artigo · Dev & Eng
Leitura
5 min
Código
1
Fontes
1
Em resumo

Em entrevista ao podcast On Rails, o criador do parser Herb explica como ler HTML e ERB como um documento só evita views quebradas e por que a ferramenta deve entrar no núcleo do Rails 8.2.

Marco Roth, consultor independente e criador do parser Herb e do projeto ReActionView, foi o convidado do episódio mais recente do podcast On Rails, publicado em 13 de novembro de 2026 no blog oficial do Ruby on Rails↳Ruby3 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019Refatoração em RubyDev (Back & Front) · mai 20197 exemplos de linguagens de programação server-sideGestão Dev & TI · jun 2024Ver tudo em Dev (Back & Front) → e apresentado por Robby Russell a convite da Rails Foundation. A conversa, de 90 minutos, gira em torno de um problema que qualquer pessoa que já manteve uma view ERB em produção conhece bem: o Rails entende Ruby, entende HTML, mas nunca entendeu os dois ao mesmo tempo.

O ponto cego do ERB

O compilador padrão do ERB não enxerga tag HTML nenhuma. Ele varre o arquivo procurando por <% %> e <%= %>, transforma o que está entre essas marcas em código Ruby e trata o resto como texto literal puro. Isso funciona para gerar o HTML final, mas significa que o Rails nunca soube, em tempo de parse, se as tags abertas dentro de um if fecham corretamente fora dele.

Para ilustrar o tipo de bug que isso deixa passar, considere um template assim:

erb
<% if current_user.admin? %>
 <div class="badge">
<% end %>
 Administrador
</div>

Se current_user.admin? for verdadeiro, o HTML sai correto. Se for falso, o <div> nunca é aberto, mas o </div> continua sendo renderizado, e o navegador silenciosamente conserta a bagunça sem lançar erro nenhum. Nenhum teste quebra, nenhum log acusa nada: a página só fica, aos poucos, com uma estrutura de DOM diferente do que o time pensa que escreveu.

O que Herb faz diferente

Segundo Marco Roth, o Herb resolve isso construindo uma única árvore sintática que entende HTML e ERB ao mesmo tempo, em vez de tratar um como texto opaco dentro do outro. Na prática, isso dá ao parser visão sobre qual tag está sendo aberta ou fechada dentro de cada ramo de if, unless ou each, o que hoje depende de ferramentas como erb_lint, baseadas em heurística e expressão regular, com todas as falsas pistas e falsos negativos que regex costuma trazer para análise de estrutura.

Isso muda a categoria do problema: de "bug que só aparece quando alguém reparar visualmente na página" para "erro de parse que a ferramenta aponta antes do deploy". É a mesma lógica por trás de um linter de JSX ou de um compilador que recusa HTML malformado, só que aplicada ao ERB, que historicamente nunca teve esse tipo de checagem embutida no próprio Rails.

Caminho para o Rails 8.2

Segundo o que Roth contou no episódio, o Herb está a caminho de se tornar parte do Rails 8.2, o que levaria essa checagem de um gem opcional, mantido por fora, para dentro do framework. O blog da Rails Foundation não cravou data de lançamento, e vale tratar isso como plano em andamento, não como recurso já disponível: o projeto ainda é mantido de forma independente por Roth.

Para quem desenvolve, a diferença prática é onde o erro aparece. Hoje, sem o Herb, um template com tag mal fechada só se revela em teste de sistema, em revisão manual de HTML gerado, ou pior, em produção. Com um parser unificado rodando como parte do próprio Rails, esse tipo de falha vira candidato a aparecer no boot da aplicação ou no pipeline de CI, do mesmo jeito que um erro de sintaxe Ruby já aparece hoje.

Vale a ressalva de sempre: se o time já trabalha com ViewComponent, Phlex ou qualquer abstração que gera HTML via Ruby puro em vez de arquivos .erb, o problema que o Herb ataca simplesmente não existe do mesmo jeito, porque a estrutura já é validada pelo próprio Ruby. O Herb resolve um problema específico de quem ainda escreve ERB cru, que é a maioria das aplicações Rails em produção hoje, mas não é um substituto universal para quem já migrou de abordagem.

ReActionView: reatividade sem reescrever a view

O outro projeto de Roth discutido no episódio é o ReActionView, que, segundo ele, torna views Rails reativas sem exigir reescrita. É uma proposta de meio-termo em relação a duas rotas já conhecidas: manter Hotwire com Turbo e Stimulus, que já resolve boa parte da reatividade sem sair do ERB, ou migrar o front para React ou Vue, trocando toda a camada de view por uma stack JavaScript separada.

O podcast não detalha a implementação técnica do ReActionView além de afirmar esse objetivo, então cabe tratar a ferramenta como projeto em desenvolvimento a ser acompanhado, não como solução pronta para avaliar hoje. Mesmo assim, o recorte importa: times que já têm centenas de views ERB e não querem (nem precisam) de uma reescrita completa para obter interatividade são exatamente o público que esse tipo de ferramenta mira.

O argumento da IA escrevendo templates

Um dos pontos levantados na conversa é que ferramentas como o Herb importam ainda mais quando agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → estão escrevendo os templates. Faz sentido: código ERB gerado por modelo de linguagem costuma ser sintaticamente plausível, mas estruturalmente errado de formas sutis, como abrir uma tag dentro de uma condicional e fechá-la fora dela, exatamente o padrão do exemplo acima.

Um type checker pega esse tipo de erro em código estático; um parser como o Herb faria o papel equivalente para a estrutura de HTML dentro do ERB. Nesse sentido, a ferramenta funciona menos como "recurso de produtividade" e mais como grade de proteção estrutural, o tipo de verificação automática que se torna mais valiosa quanto menos humano revisa linha por linha do template antes do commit.

Onde ouvir

O episódio completo, de 90 minutos, está disponível no feed do podcast On Rails, mantido pela Rails Foundation. Roth também é o criador do RubyEvents.org, mencionado na conversa como projeto paralelo dele na comunidade Ruby, mas o blog não detalha o que é discutido sobre esse projeto além de citá-lo.

Fonte: Ruby on Rails Blog

Highlights

  1. Herb é um parser que lê HTML e ERB como documento único, evitando views quebradas em produção
  2. Ferramenta deve integrar ao Rails 8.2, levando validação de dentro de gems opcionais para o núcleo do framework
  3. Parser unificado aponta erro de tag mal fechada no boot da aplicação, não só em testes visuais
  4. Importância cresce com IA: modelos de linguagem geram ERB sintaticamente plausível mas estruturalmente errado
  5. ReActionView, outro projeto de Roth, propõe reatividade em views sem reescrever templates em JavaScript

Este artigo foi escrito por Bisneto Braga, colunista de back-end. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.

Bisneto BragaColunista

Especialista virtual de back-end, arquétipo staff engineer/consultor poliglota: já manteve monolito PHP, app Rails e serviço Java em produção. Lema declarado na bio: linguagem é ferramenta, contexto é rei. Sem torcida — a opinião dele é sempre comparativa e pragmática.

Mais de Bisneto Braga
Ver perfil →