Marco Roth's Herb parser set to unify HTML and ERB parsing in Rails 8.2

Marco Roth, an independent consultant and creator of the Herb parser and the ReActionView project, was the guest on the most recent episode of the On Rails podcast, published on November 13, 2026 on the official Ruby on Rails blog and hosted by Robby Russell at the invitation of the Rails Foundation. The 90-minute conversation centers on a problem that anyone who has ever maintained an ERB view in production knows well: Rails understands Ruby, understands HTML, but has never understood both at the same time.

ERB's blind spot

The standard ERB compiler doesn't see any HTML tags at all. It scans the file looking for <% %> and <%= %>, turns whatever is between those markers into Ruby code, and treats everything else as plain literal text. That works for generating the final HTML, but it means Rails never knew, at parse time, whether tags opened inside an if closed correctly outside it.

To illustrate the kind of bug this lets through, consider a template like this:

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

If current_user.admin? is true, the HTML comes out correct. If it's false, the <div> is never opened, but the </div> is still rendered, and the browser silently patches up the mess without throwing any error. No test breaks, no log flags anything: the page just ends up, little by little, with a DOM structure different from what the team thinks it wrote.

What Herb does differently

According to Marco Roth, Herb solves this by building a single syntax tree that understands HTML and ERB at the same time, instead of treating one as opaque text inside the other. In practice, this gives the parser visibility into which tag is being opened or closed inside each branch of an if, unless, or each, something that today depends on tools like erb_lint, which rely on heuristics and regular expressions, with all the false leads and false negatives that regex tends to bring to structural analysis.

That shifts the category of the problem: from "a bug that only shows up when someone visually notices it on the page" to "a parse error the tool flags before deploy." It's the same logic behind a JSX linter or a compiler that rejects malformed HTML, just applied to ERB, which historically never had this kind of check built into Rails itself.

Path to Rails 8.2

According to what Roth said on the episode, Herb is on track to become part of Rails 8.2, which would move this check from an optional gem, maintained externally, into the framework itself. The Rails Foundation blog didn't nail down a release date, and it's worth treating this as a plan in progress, not as a feature already available: the project is still maintained independently by Roth.

For developers, the practical difference is where the error shows up. Today, without Herb, a template with a badly closed tag only reveals itself in a system test, in manual review of the generated HTML, or worse, in production. With a unified parser running as part of Rails itself, this kind of failure becomes a candidate to surface at application boot or in the CI pipeline, the same way a Ruby syntax error already does today.

The usual caveat applies: if the team already works with ViewComponent, Phlex, or any abstraction that generates HTML via plain Ruby instead of .erb files, the problem Herb targets simply doesn't exist in the same way, because the structure is already validated by Ruby itself. Herb solves a problem specific to those who still write raw ERB, which is most Rails applications in production today, but it's not a universal substitute for those who have already migrated to a different approach.

ReActionView: reactivity without rewriting the view

The other project of Roth's discussed on the episode is ReActionView, which, according to him, makes Rails views reactive without requiring a rewrite. It's a middle-ground proposal relative to two already-known paths: sticking with Hotwire using Turbo and Stimulus, which already solves much of the reactivity without leaving ERB, or migrating the front end to React or Vue, replacing the entire view layer with a separate JavaScript stack.

The podcast doesn't detail ReActionView's technical implementation beyond stating this goal, so it's fitting to treat the tool as a project in development worth following, not as a ready-made solution to evaluate today. Even so, the framing matters: teams that already have hundreds of ERB views and don't want (or need) a full rewrite to get interactivity are exactly the audience this kind of tool targets.

The case for AI writing templates

One of the points raised in the conversation is that tools like Herb matter even more when AI agents are writing the templates. That makes sense: ERB code generated by a language model tends to be syntactically plausible but structurally wrong in subtle ways, like opening a tag inside a conditional and closing it outside of it, exactly the pattern in the example above.

A type checker catches this kind of error in static code; a parser like Herb would play the equivalent role for HTML structure inside ERB. In that sense, the tool functions less as a "productivity feature" and more as a structural guardrail, the kind of automated check that becomes more valuable the less a human reviews the template line by line before committing.

Where to listen

The full 90-minute episode is available on the On Rails podcast feed, maintained by the Rails Foundation. Roth is also the creator of RubyEvents.org, mentioned in the conversation as his side project in the Ruby community, but the blog doesn't detail what's discussed about that project beyond mentioning it.