Marco Roth

Glamorous Christmas: Bringing Charm to Ruby

2025-12-25T11:00:00+00:00

Today, Ruby 4.0 was released. What an exciting milestone for the language!

This release brings some amazing new features like the experimental Ruby::Box isolation mechanism, the new ZJIT compiler, significant performance improvements for class instantiation, and promotions of Set and Pathname to core classes. It’s incredible to see how Ruby continues to thrive and be pushed forward 30 years after its first release.

To celebrate this release, I’m happy to announce that I’ve been working on porting the Charmbracelet Go terminal libraries to Ruby, and today I’m releasing a first version of them. What better way to make this Ruby 4.0 release a little more glamorous and charming?

I’ve been a huge fan of the Charm terminal libraries for years. I’ve always loved the aesthetics and the look & feel of the Charm libraries. Every time I see a CLI tool built with them, I get a little envious. The attention to detail, the smooth animations, the gorgeous styling, it all just feels right. I’ve spent more time than I’d like to admit just playing around with their demos and admiring how polished everything looks.

For a long time, I wished we had something like this in Ruby. So I finally decided to stop wishing and start building. Spoiler: some of these are pure Ruby ports, while others are bindings to their Go-library counterparts.

What is Charm?

Charmbracelet is an open source project building tools for the terminal. Their tagline is “We make the command line glamorous.”, and they truly deliver on that promise.

The Charm team believes that developer experience is user experience. APIs and CLIs are user interfaces at the end of the day, and they deserve the same care and attention as any visual design. This philosophy has led them to build some of the most beautiful and well-designed terminal libraries in any language.

What sets Charm apart is that their tools make people feel something. When you see a Charm-powered application for the first time, there’s a moment of delight, a “wow, I didn’t know the terminal could look like this.” That’s not an accident. It’s the result of caring deeply about craft and aesthetics in a space where most tools are purely functional.

One of their key insights was separating structure from style, mirroring how the web separates HTML from CSS. Lipgloss handles styling and layout, while Bubble Tea provides the application architecture. This separation makes it easy to build complex UIs without mixing concerns.

The Charm Ecosystem

The Charm libraries are thoughtfully designed with composable pieces that work together beautifully:

Lipgloss provides the styling primitives like colors, borders, padding, and alignment
Bubble Tea gives you the Elm-inspired Model-View-Update architecture for building interactive TUIs
Bubbles offers ready-to-use components built on Bubble Tea
Glamour renders Markdown gorgeously in the terminal
Huh? makes building interactive forms a breeze
Harmonica provides spring-based animations and easing functions
Gum democratizes interactive UIs for shell scripts

Each library solves one problem well, and together they form a complete toolkit for building beautiful terminal applications.

Why Port Charm to Ruby?

Ruby has always been a joy to work with. They say Ruby is a programmer’s best friend, and I think that’s true. For 30 years, the language has embodied a philosophy of making coding more human, intuitive, and enjoyable. Matz built Ruby around the Principle of Least Surprise, valuing craftsmanship and expressive code over hype-driven trends. It’s a language that cares about how things feel.

Charm shares that same DNA. Their tools prioritize developer happiness, expressiveness, and craft. When I discovered Charm, I immediately thought: this belongs in Ruby.

We have great tools for building CLIs, but when it comes to building rich, interactive, beautiful terminal applications, we’ve been missing the kind of cohesive ecosystem that Charm provides for Go.

I wanted to change that. Ruby developers deserve glamorous terminals too. I want Ruby developers to build terminal applications so beautiful that even people who “don’t like CLIs” find themselves captivated.

These ports aim to bring that same level of polish and developer experience to Ruby. Quick script or full-blown TUI app, you should be able to make it look stunning with minimal effort.

A Renaissance in Ruby Developer Experience

This project is part of a broader movement happening in the Ruby community. Over the past few years, we’ve seen an incredible focus on improving the developer experience, and it’s been driven by a key insight: strategic standardization enables innovation.

Just as Rails revolutionized web development by standardizing conventions, the Ruby ecosystem is now applying the same principle to developer tooling. By standardizing foundational layers, we free ourselves to build richer, more powerful tools on top.

This extends beyond individual tools. Protocols like LSP (Language Server Protocol), DAP (Debug Adapter Protocol), and now MCP (Model Context Protocol) provide shared infrastructure that unifies how tools communicate. Instead of every editor implementing language support from scratch, LSP gives us a common language. Instead of every debugger reinventing the wheel, DAP provides a shared foundation. These protocols enable an explosion of interoperable tooling.

And that’s the key insight: when you build strong foundations, the community builds incredible things on top. Give developers the right building blocks, and they’ll create tools you never imagined.

This story extends across the Ruby ecosystem:

Prism, Ruby’s new official parser designed for tooling from the ground up, providing a standard foundation for static analysis
Ruby LSP, a language server and platform for editor intelligence with a growing ecosystem of add-ons
Sorbet, a fast, powerful type checker for Ruby
RBS, Ruby’s type signature language standardizing how we describe types
RBS Inline, inline type annotations directly in Ruby source files
Steep, a gradual type checker built on RBS
debug, Ruby’s modern debugger with IDE integration
IRB and RDoc, core tools receiving renewed attention and improvements
Herb, an HTML-aware ERB parser and ecosystem enabling better tooling for HTML views and rendering

The Ruby ecosystem is investing heavily in making the development experience more polished, more intelligent, and more delightful. From better editor support to faster parsers to type checking, Ruby is leveling up.

Bringing Charm to Ruby fits right into this story. It’s about raising the bar for what Ruby developers can build and how good it can look. The terminal is often where we spend our time as developers, and it deserves the same attention to developer experience as our editors and IDEs.

The Libraries

Lipgloss

CSS-like styling for terminal output. Define colors, borders, padding, margins, and alignment with a clean, chainable API. Includes support for tables, lists, and tree structures.

Example

require "lipgloss"

style = Lipgloss::Style.new
  .bold(true)
  .foreground("#FAFAFA")
  .background("#7D56F4")
  .padding(1, 2)
  .border(:rounded)
  .border_foreground("#874BFD")

puts style.render("Hello, Glamorous Ruby!")

Demo

Bubble Tea

The Elm-inspired TUI framework. Build interactive terminal applications using the Model-View-Update architecture.

Example

require "bubbletea"

class Counter
  include Bubbletea::Model

  def initialize
    @count = 0
  end

  def init
    [self, nil]
  end

  def update(message)
    case message
    when Bubbletea::KeyMessage
      case message.to_s
      when "q", "ctrl+c"
        [self, Bubbletea.quit]
      when "up", "k"
        @count += 1
        [self, nil]
      when "down", "j"
        @count -= 1
        [self, nil]
      else
        [self, nil]
      end
    else
      [self, nil]
    end
  end

  def view
    "Count: #{@count}\n\nPress up/down to change, q to quit"
  end
end

Bubbletea.run(Counter.new)

Demos

Bubbles

Pre-built TUI components for Bubble Tea: spinners, progress bars, text inputs, text areas, viewports, lists, tables, file pickers, and more.

Example

require "bubbles"

Animated spinner

spinner = Bubbles::Spinner.new
spinner.spinner = Bubbles::Spinners::DOT

Progress bar

progress = Bubbles::Progress.new(width: 40)
progress.set_percent(0.5)

Text input

input = Bubbles::TextInput.new
input.placeholder = "Enter your name..."
input.focus

Demos

Glamour

Stylesheet-based Markdown rendering for the terminal. Supports syntax highlighting, multiple themes, and custom styles via a Ruby DSL.

Example

require "glamour"

markdown = <<~MD
  # Hello, World!

  This is **bold** and this is *italic*.

  - Item one
  - Item two
  - Item three
MD

puts Glamour.render(markdown, style: "dark", width: 80)

Demos

Huh?

A simple, powerful library for building interactive forms and prompts. Includes inputs, selects, multi-selects, confirms, spinners, validation, and theming.

Example

require "huh"

form = Huh.form(
  Huh.group(
    Huh.input
      .key("name")
      .title("What's your name?")
      .placeholder("Enter your name..."),

    Huh.select
      .key("color")
      .title("Favorite color?")
      .options(
        Huh.option("Red", "red"),
        Huh.option("Green", "green"),
        Huh.option("Blue", "blue")
      ),

    Huh.confirm
      .key("ready")
      .title("Ready to continue?")
  )
)

form.run

puts "Hello, #{form["name"]}!"

Demos

Harmonica

A simple, physics-based animation library. Damped spring oscillators for smooth, natural motion in your terminal UIs.

Example

require "harmonica"

spring = Harmonica::Spring.new(
  delta_time: Harmonica.fps(60),
  angular_frequency: 6.0,
  damping_ratio: 0.5
)

position = 0.0
velocity = 0.0
target = 100.0

loop do
  position, velocity = spring.update(position, velocity, target)
  break if (position - target).abs < 0.01
end

Demos

Bubblezone

Mouse event zones for TUIs. Mark regions as clickable and easily determine which component was clicked in your Bubble Tea applications.

Example

require "bubblezone"

Mark regions with zone identifiers

ok_button = Bubblezone.mark("confirm", styled_ok_button)
cancel_button = Bubblezone.mark("cancel", styled_cancel_button)

Check if mouse event is in bounds

if Bubblezone.get("confirm").in_bounds?(mouse_message)
  # Handle confirm click
end

Demo

Gum

A tool for glamorous shell scripts. Ruby wrapper for Charm’s gum binary with an idiomatic API for inputs, selects, confirms, spinners, styled output, and more.

Example

require "gum"

Text input

name = Gum.input(placeholder: "Enter your name")

Selection menu

color = Gum.choose("red", "green", "blue")

Confirmation prompt

if Gum.confirm("Continue?")
  Gum.spin("Processing...") { do_work }
end

Styled output

puts Gum.style("Done!", foreground: "212", bold: true, border: :rounded)

ntcharts

Nimble Terminal Charts. Visualize data beautifully with sparklines, bar charts, line charts, time series, heatmaps, and more.

Example

require "ntcharts"

sparkline = Ntcharts::Sparkline.new(10, 5)
sparkline.push_all([7.8, 3.8, 8.4, 2.1, 4.2, 6.8, 2.5, 9.2, 1.3])
sparkline.draw

puts sparkline.view

Demos

Installation

All gems (except huh) are available on RubyGems.org:

gem install lipgloss
gem install bubbletea
gem install bubbles
gem install glamour
gem install harmonica
gem install bubblezone
gem install gum
gem install ntcharts

For huh, add it to your Gemfile from GitHub (we reached out to the current owner of the huh gem and are hoping to be able to publish the gem under the huh name in the future):

gem "huh", github: "marcoroth/huh-ruby"

Source Code

You can find more information at charm-ruby.dev. All libraries are open source and available on GitHub:

Library	Gem	Repository
Lipgloss	`lipgloss`	github.com/marcoroth/lipgloss-ruby
Bubble Tea	`bubbletea`	github.com/marcoroth/bubbletea-ruby
Bubbles	`bubbles`	github.com/marcoroth/bubbles-ruby
Bubblezone	`bubblezone`	github.com/marcoroth/bubblezone-ruby
Glamour	`glamour`	github.com/marcoroth/glamour-ruby
Gum	`gum`	github.com/marcoroth/gum-ruby
Harmonica	`harmonica`	github.com/marcoroth/harmonica-ruby
Huh?	`huh`	github.com/marcoroth/huh-ruby
Nimble Terminal Charts	`ntcharts`	github.com/marcoroth/ntcharts-ruby

What’s Next

This is just the beginning. These are initial releases, and there’s plenty more to do.

The first pass was primarily focused on getting the Go functionality ported to Ruby. Now the real work begins: making these libraries feel more Ruby-like and idiomatic. I want to improve how the libraries work and integrate with each other, add more pre-built components, and make it even easier to get started building beautiful terminal applications.

Some areas I’m focusing on:

Making the APIs more idiomatic and Ruby-like
Improving integration between the libraries
Expanding the component libraries with more ready-to-use pieces
Better documentation and examples
Performance optimizations

These are early releases, and there’s still work to be done. Some of the Go-based gems have quirks when used together due to how Goroutines are initialized. I’m actively working on these, and I’d rather build in public with the community than wait for everything to be perfect.

Let’s Build Together

But here’s what really excites me: imagine what we could build together. Think about all the CLI tools, test runners, generators, installers, and framework scripts we use every day.

What if they were all a little more polished, a little more interactive, a little more glamorous? Rails generators with beautiful progress indicators. Test runners with live, filterable output. Bundler with elegant spinners and styled summaries. Or entirely new applications that weren’t really possible before, but now are. The possibilities are endless!

I couldn’t wait to start exploring, so here are a couple of things I’ve been experimenting with:

Minitest Bubble Tea Runner

A Minitest plugin that uses Bubble Tea to run your tests with a beautiful, interactive interface. Inspired by Vitest’s terminal UI. The UI stays open after the run completes, letting you re-run the failed tests, filter to focus on specific tests, and enjoy a clean collapsible view that tucks away individual test cases when a file passes. (This is an extension of the static standalone Bubble Tea test runner demo in the Bubble Tea demos above.)

Herb TUI Playground

A terminal rebuild of the Herb Playground, built entirely with these libraries. Type HTML+ERB code and switch between tabs to explore the parsed AST, tokens, extracted Ruby, extracted HTML, and any parser errors, all in a beautiful split-pane terminal UI.

Thank You

A special thank you to Anton Sozontov for transferring the gum gem name on RubyGems.org, and to Tomas Valent for transferring the bubbles gem name.

The terminal has been around for decades, but that doesn’t mean it has to feel dated. With the right tools, you can build software that genuinely delights.

I hope these libraries inspire you to craft something that makes people stop and say “wow.”

But more than anything, I want to encourage you to build with these libraries. Build new tools. Upgrade your existing CLI applications to make them shinier, more glamorous, more beautiful. Add some color, some polish, some fun.

The terminal doesn’t have to be boring. Let’s make it glamorous.

I’d love to hear your feedback and see what you create! You can find all the libraries at charm-ruby.dev and browse the full collection on my GitHub list.

Happy Ruby 4.0 release day! Let’s make the Ruby command line glamorous.

— Marco

Giving Back to the Rails Community

2025-12-18T14:30:00+00:00

I’m deeply grateful and truly honored to be named a Rails Luminary this year. Thank you to everyone who supported me, my work, and took the time to nominate me. Recognition like this only exists because of a community that cares about long-term contribution, and I don’t take that lightly.

Rails has given me a lot over the years.

Not just technically, but professionally and personally. Rails gave me a way to build things that matter, a community that values craft, and an environment where curiosity and care are encouraged. A community where people build, ship, and want to be productive. It helped me grow in ways I didn’t expect, including getting started with public speaking, and then getting more comfortable standing on a stage sharing knowledge and the work I’ve been doing.

In such a supportive and welcoming environment, giving back stopped feeling like a choice and started feeling like the natural thing to do. That’s how Rails became what it is today: people showing up, doing the work because it needed doing, smoothing out rough edges, building tools, and helping others ship. It’s part of the culture. Being part of that feels right, and being part of this community is an honor and a privilege.

The way I try to give back is by building things I need myself and sharing them openly, as honest attempts to solve real problems. I genuinely love open source, and I especially enjoy solving tricky problems: tooling, parsers, developer experience, and the infrastructure that quietly supports everything else.

Projects like Herb, ReActionView, Hotwire-related tooling (Stimulus LSP, …), the Hotwire Weekly Newsletter, and RubyEvents.org all grew out of that mindset. They started as personal needs and became shared efforts because others showed up with feedback, issues, reviews, and ideas.

This year was particularly humbling. I had the privilege of traveling and speaking at conferences around the world: 18 talks across 15 countries and four continents. Being able to share my work, exchange ideas, and meet Ruby friends in so many places reminded me how global, generous, and thoughtful this community really is. I’m incredibly thankful for every conversation, question, and moment of encouragement along the way. Being able to connect with the Ruby community face to face is something very special.

I also want to explicitly thank Xavier Noria, Amanda Perino, and the entire Renuo team for putting on the event and for the care they bring to creating spaces like this. It shows, and it matters.

None of this work happens in isolation. I’m grateful to everyone who tested early versions, filed issues, challenged assumptions, shared encouragement, or quietly helped in ways that never make it into release notes or commit messages. And I’m especially thankful to those who nominated me, that trust means a lot.

I don’t see this award as a finish line. If anything, it’s encouragement to keep going. I plan to continue doing the work I care about, pushing on the parts of the ecosystem that can be better, and sharing what I build along the way, openly and with care.

Looking ahead to 2026, I’ll keep pushing on the Herb tooling, the Herb::Engine, and improving ReActionView as we work our way through the 6 adoption levels I outlined earlier this year. There’s still a lot to explore, build and iterate on.

I’m also planning to write a full 2025 Year-in-Review post soon. If you’re curious about what’s next, feel free to follow along.

Thank you for the support, and for making Rails a place worth caring deeply about.

Marco

Introducing ReActionView: A new ActionView-Compatible ERB Engine and initiative for the Rails view layer

2025-09-11T12:00:00+00:00

Rails World 2025 just wrapped up in Amsterdam last week. This blog post is a recap of my talk titled “Introducing ReActionView: A new ActionView-Compatible ERB Engine” and summarizes my talk, the new releases, and where my view-layer work is headed next.

This talk is the conclusion of a journey I’ve been sharing throughout 2025. At RubyKaigi, I introduced Herb: a new HTML-aware ERB parser and tooling ecosystem. At RailsConf, I released developer tools built on Herb, including a formatter, linter, and language server, alongside a vision for modernizing and improving the Rails view layer.

At Rails World, I started to deliver on the vision I shared at RailsConf. I publicly introduced ReActionView, an initiative to explore what’s possible in the Rails view layer, plus a significant update to Herb with v0.7 and Herb::Engine.

Herb::Engine is a new ERB engine built on the Herb Parser, fully compatible with .html.erb but with HTML validation, better error feedback, reactive updates (soon), and built-in tooling.

This is tying together everything from the past talks and the work I have done so far in 2025 to show the full potential of Herb, ReActionView, and where the Rails view layer could be headed.

Slides: Speaker Deck
Projects: ReActionView • Herb • Stimulus Lint
Recording: (coming soon)

What we announced

ReActionView initiative: a pragmatic, ActionView-compatible path forward for the view layer.
Herb v0.7: updates across the Linter, Formatter, Language Server, and VS Code extension.
Herb::Engine: an HTML-aware, framework-independent ERB rendering engine.
Dev Tools for the browser: view/partial/component outlines with jump-to-source, ERB output hover, and dismissable validation overlays during development.
New linter rules: +18 rules (9 accessibility focused), bringing the total to 32.
Stimulus Lint The extracted diagnostics from Stimulus LSP (powered by Herb).
Tailwind class rewriter (coming soon).
Early experiments toward Phoenix LiveView-style reactivity for ERB.

Herb Linter updates since RailsConf

18 new rules (including 9 accessibility), for a total 32 linter rules.
CLI supports --github flag for annotating pull requests.
More advanced control flow analysis

Your browser does not support the video tag.

Herb Linter Control Flow Analysis

Herb Formatter updates since RailsConf

The Herb Formatter got a lot of improvements in terms of stability and predictability. We are getting really close to enabling the formatter by default in the Herb Language Server, so it formats HTML+ERB files on save.

Another thing we have been working on is a rewriter system for the formatter, so we can rewrite part of the document before and/or after formatting.

One of the most requested features is to be able to format the Tailwind CSS classes inside the class attribute. Tailwind has an official recommended way for ordering classes but it’s tied to the Prettier ecosystem and doesn’t really work well with HTML+ERB documents.

So we extracted the algorithm into a new package @herb-tools/tailwind-class-sorter that the algorithm can be used independently of the prettier plugin.

The Herb Formatter is going to have an option to integrate this package so we automatically sort the Tailwind classes when saving the document.

Your browser does not support the video tag.

Since the Herb Parser understands both HTML, ERB, and Ruby it’s also going to work when you use Action View Tag Helpers like tag.div, content_tag, link_to, and more.

Stimulus Lint

The Stimulus LSP has had a lot of diagnostics that help you catch errors when working with Stimulus. But these diagnostics where exclusive and locked into the Language Server implementation, so you couldn’t use them independently.

We now started to work on extracting these diagnostics into a new Stimulus Lint package, which is powered by the Herb Linter infrastructure, so it’s going to work on both HTML and HTML+ERB documents.

Stimulus Lint uses the Stimulus Parser project to statically analyze your project to figure out which controllers, targets, values, classes, etc. are available, so it can tell it when you are using undefined or unknown controllers.

The other benefit is that you can run the linter independently from the language server, which makes it ideal to run in CI or locally in a pre-commit hook.

Since we are building on top of the Herb Linter architecture we also get the nice CLI and beautiful error pinpointing with syntax highlighting right in the terminal.

Turbo Lint

We now have the power to better understand HTML+ERB and the Ruby inside the ERB tags, which now also allows us to build more useful tooling and a linter for Turbo.

We are going to do some research to see how useful this really is. If it makes sense, we are also going to publish a Turbo Lint package, specifically tailored for how you use Turbo in HTML+ERB files.

Stimulus LSP Update

With Herb being available now and having the Stimulus Lint extracted as it’s own package, we are going to ship an update the to Stimulus LSP to integrate these advancements.

This will also significantly simplify the Stimulus Language Server implementation, since most of the logic is going to live in Herb and Stimulus Lint.

Since we are using the Herb Parser, and the Herb Parser is able to understand Action View Tag Helpers, we are also going to get these diagnostics on Action View Tag Helpers which are very common in Rails applications.

With the power of Herb, we could also introduce more advanced diagnostics, like find controller/target usages, find unused controllers, refactoring tools (like renaming), and more!

The Rails View Layer

ActionView was introduced at the very start of Rails in July 2004, as part of the Rails 0.5.0 release. Action View was thus the “V” in Rails’ MVC, responsible for template rendering. Back then, it was packaged within Action Pack, not as a separate gem. Even back then, it shipped with ERB (Embedded Ruby), which is still what it’s using today.

At RailsConf, I shared my vision for the Rails view layer using multiple adoption levels. Action View uses Erubi by default today, which is an ERB implementation that operates as a String Template Engine. We want to take it from being a String Template Engine to be a HTML Templating Engine. An engine that cannot produce invalid HTML and an engine that can also tell you what’s wrong about the syntax.

The idea is, if you give the template engine invalid HTML markup or invalid ERB syntax, it shouldn’t compile. And if you still do, it should tell you a) what is wrong, and b) where, within your template, the error is. We want to get more actionable feedback.

So we want to see, how we can reimagine ActionView for 2025 and beyond. We want to see how we can reengineer some of the parts of ActionView to make them more performant, easier to use, and make them more maintainable. And, we want to see if we can make ActionView reactive, so that you even need less JavaScript to build more ambitious web UIs.

So this is the initiative of ReActionView. An initiative to explore what’s possible in the Rails view layer in 2025 and beyond.

The design goals are to keep .html.erb templates backwards-compatible (as long as you already have valid HTML markup), improve the developer experience, embrace modern web standards and new native browser features.

See if we can more tightly integrate modern Frontend Frameworks, and finally, to see how far we can push things in general and what we could achieve with a new wave of ideas, tooling, and libraries.

Over the last few years browsers really got a lot of new great features. In HTML+CSS we got Import Maps, Web Components/Custom Elements, Declarative Shadow DOM, Progressive Web Apps (PWA), and so much more.

In CSS, we got CSS Grids, CSS Nesting, Container Queries, CSS @function’s, CSS Custom @property, @layer, and a lot more.

We also got a wave of new Web APIs, including the View Transitions API, Popover and Invoker Commands API, and new upcoming Speculation Rules API, which could be very interesting for the upcoming Turbo offline mode.

Comparing traditional Rails apps, like server-side rendering (SRR) using one of the popular HTML-over-wire frameworks, it’s quite far away from the client-side rendering (CSR) approach where you use a Rails API and one of the popular client-side frameworks to build a full Single Page Application (SPA).

But sadly, more and more teams are opting to use the latter because they find that HTML-over-the-wire and it’s frameworks are limiting. Teams want to build High Fidelity UIs, want to use existing Components/Libraries, might already have a lot of React Developers on staff, or have split Backend- and Frontend-Teams.

Hotwire is great, simple, and gets the job done in most of cases. But when you need more than what Hotwire provides you today, it’s not as easy to transition from Hotwire to a Frontend Framework. The process is not gradual. There is no onramp or migration path. You either migrate all or nothing.

And this is part of the reason why some teams opt to use SPAs from the beginning. Which, in my opinion, is giving away most of what makes Rails so great and productive. Let’s try to close the gap, so less and less teams actually need actually to abandon Action View. I want to see what’s possible and how far we can go. That’s why I’ve been investing in Herb to help see what we can do.

Herb v0.7.0 and `Herb::Engine`

I’m happy to announce the release of Herb v0.7.0.

Herb v0.7.0 also ships with a first version of the Herb::Engine. The Herb::Engine is a new, HTML-aware ERB Rendering Engine, that’s delivering on the vision I shared at RailsConf.

Herb::Engine is designed to be Erubi::Engine API-compatible and is meant to be a drop-in replacement for when dealing with .html.erb files.

How `Erubi::Engine` works

As I shared earlier, Erubi::Engine could be categorized as a String Template Engine. Which means that it doesn’t really care what code is around the <% and %> tags. Erubi::Engine uses a Regex to take your template and split it up into static parts and Ruby parts when it’s trying to compile the ERB template.

After splitting up the template into the individual pieces, it’s calling add_text(), add_expression(), and add_code() to produce the compiled template.

The add_text() is being used for appending the static text parts to the compiled template, add_expression() for appending the String-result of the Ruby code, and add_code() for any other Ruby code that might be used for control flow or other logic.

In our simple example here, we get the following output.

We are using a String as a buffer to shuffle content into the buffer. At the very end we call .to_s to make sure we return the evaluated and rendered template as a string.

`Herb::Engine` compared to `Erubi::Engine`

In contrast, the Herb::Engine is using the Herb Parser to first parse the template.

In our simple example, this produces the following Syntax Tree. If we now strategically visit each of these nodes in the syntax tree we can try to compile the template by visiting all nodes.

Since we are using Herb, we can leverage the Herb::Visitor which allows us to implement visit_* methods to strategically visit each of the node in our syntax tree.

Let’s start by implementing the HTMLOpenTagNode. The HTMLOpenTagNode has a tag_opening, tag_name, and tag_closing properties. If we call add_text() for each of these parts we can add them to the static output of our compiled template.

The HTMLTextNode is quite straightforward too. Since it only contains static text, we can also call add_text() for the content.

The ERBContentNode is a bit more complex, since it represents any ERB tag, like <% or <%=. It can check the tag_opening if it is a <%=, and if it is, call add_expression() and otherwise call add_code().

This will call the following methods in the following order as part of visiting each node in the syntax tree.

If we now compare this to Erubi::Engine you can see that this uses more method calls.

But since we are controlling the engine implementation we can slightly change the implementation of add_text, add_expression, and add_code to collect tokens, instead of directly outputting them as part of final compiled template.

After visiting each node in the tree, we can look at what we generated and try to compact the tokens. So if we see multiple consecutive text tokens we rewrite and combine them into a single text token.

Your browser does not support the video tag.

If we now call add_text, add_expression, and add_code for each of the tokens in the array, we get the same method calls Erubi::Engine produced.

And if we compare the compiled templates you can also see that the output are identical.

The difference is, that Herb::Engine gives as all the guarantees the Herb Parser gives us. Which means we get helpful error messages and exact locations for where something went wrong in our template.

Use `Herb::Engine` in Rails

Now, let’s try to use our new ERB rendering engine in Rails. Luckily for us, ActionView::Template and ActionView::Template::Handlers makes this very easy for us to plug in our new rendering engine.

We can implement a new Herb ERB implementation within ActionView::Template::Handlers::ERB. Since we designed Herb::Engine to be API-compatible with Erubi::Engine we can pretty much copy the Erubi ERB implementation within Action View.

Within the ActionView::Template::Handlers::ERB handler, we can autoload the Herb implementation and default the erb_implemenation to use our new Herb implementation.

We can now point our app to use our Rails fork and boot our app using bin/dev.

And tada, it renders our application using the Herb::Engine implementation!

Improved Error Pages/Overlays

Since we now have the Herb::Engine implementation and can start to improve other things as well. Let’s start with the error page when we see a syntax error in an HTML+ERB template.

Currently Rails renders an error page which includes the whole template in the exception message, unformatted.

We can improve it, because the Herb Parser already exactly knows where something is wrong in the template. We already make use of this in the Herb Linter in the terminal output:

So let’s bring this detail to the error page in the browser, as well:

This makes it so much more actionable and easier to understand what’s wrong in your template. And the beautiful thing is that you get immediate and accurate feedback in your editor, since the same parser is now responsible for powering the editor tooling and rendering the ERB in your app.

Dismissable Validation Overlays

Since we are already dealing with HTML, we can also try to add validations and report these issues. In this case we can report if you have invalid HTML, in this case nested <p> tags.

We can also report if the template is trying to unsafely interpolate ERB:

Your browser does not support the video tag.

Since these issues are not strictly “breaking” the template rendering, we report these violations as issue and make them dismissable.

Debug View Annotations in Development

Having control over the rendering engine means we can also do more cool things. I’ve been really enjoying the config.annotate_rendered_view_with_filenames setting in Rails to annotate the view file names as HTML comments.

The issue with HTML comments is that you can’t really visually style them on the rendered page in the browser.

But, our compiler already knows how to render HTML elements and attributes.

So, what if we inject additional HTML attributes, directly on the HTML elements themselves, instead of adding HTML comments with the filenames in development?

If we render these additional debug Data Attributes and add some CSS styles:

We get really nice visual view outlines, right in the browser!

If we also add another attribute for the “view type”, we can give the different types of view files different colors. So we can say views are blue, partials are green, and components are orange:

If we also add, the relative project path and the full path to the attributes:

We can reveal the full project path when hovering the outline labels:

Your browser does not support the video tag.

Another thing we can do, since we have the full path, is the open the file in the editor when clicking the outline label:

Your browser does not support the video tag.

Since we are using CSS outline and HTML attributes we don’t interrupt the natural flow of the content on the page.

So the outlines just add the visual appearance and provide immensely helpful visual debugging. And the jump-to-source when clicking on the outline label is super helpful when you are trying to find the right file to update.

Debug ERB Output Tags in Development

The next logical question is: “Can we also do this for ERB Output tags?”. And the obvious answer is, YES!

The Herb Debug menu has a “Show ERB Output Outlines” option.

When enabled, it shows you all the dynamic parts on the current page you are on, which were rendered using a <%= tag, which is super cool!

Your browser does not support the video tag.

We also have an option for enabling “Reveal ERB Output tag on hover”.

When enabled, it shows the exact ERB code that was used to produce the content that is rendered on the page.

Your browser does not support the video tag.

And the logical next step is to also implement the jump-to-source when clicking on the ERB output tags. In this case, it will open the right view file, on the right line and the right column, since the Herb Parser exactly knows where these tags were located in the original template file. Super useful!

Your browser does not support the video tag.

Roadmap: ReActionView Adoption Levels

So, what’s next? ReActionView is not a replacement for Action View. It’s a set of ideas and tools that remain Rails-y, aim for backwards-compatibility, and adopt modern web standards. The goal is to raise the floor of DX while keeping the on-ramp low.

In the original vision at RailsConf, I showed 6 Adoption Levels of how far we can take ReActionView. With this implementation we have today we reached and implemented Level 2 of that vision.

Level 1 and 2: Try it locally, today!

You can try these features today in your Rails app. Add reactionview to your Gemfile and run the installer.

bundle add reactionview

rails generate reactionview:install

This will generate the following config/initializer/reactionview.rb initializer:

You can choose to intercept all .html.erb files to be rendered and proccessed by Herb::Engine by setting config.intercept_erb = true:

By doing so, you will get the Herb Dev Tools overlay in your Rails app:

Please give it a shot in your app, even if it’s just locally in your development environment and report any unexpected behavior you might encounter.

Level 3 - Action View Optimizations

Since we have so much introspection of these HTML+ERB files, there might be some opportunities to implement more Action View Optimizations, like inlining Partial render calls, inlining Action View Tag Helpers, minifying insignificant whitespace, and probably more.

Level 4 - Reactive ERB Views

With rendering and structural awareness in place, Herb could diff templates and re-render only what changed. In this case, we would consider all instance variables, passed from the controller to the view, as part of the “view state”.

If you update the state, the engine would know which part in the template is going to be affected by this state change, and would be able to only re-render the relevant part of the template, without the need to re-render the whole view.

Your browser does not support the video tag.

Reactive ERB templates

Think of this as Phoenix LiveView HEEx-like updates, but still keeping it Rails-y by using the existing .html.erb view files.

If you are not familiar with Phoenix LiveView, you can also think of this as the ERB engine emitting a set of <turbo-stream> update actions to reflect the changes in the DOM, but without the user having to explicitly tell the engine what to render and what to target using an element/ID in the DOM.

This would also allow for a lot of applications to be simplified and could reduce the need for Turbo Frames, Turbo Streams or Turbo Morphing in the future, since the engine itself is fully aware of the state and how it has to reflect the updates in the DOM.

For this to be viable we would need to find a way to serialize the state, detect state changes and then be able to broadcast these updates to the browser.

Level 5 - Client-side templates

Another interesting thing to explore is similar to what React did with React Server Components (RSC). React allows certain React components to be both client-side and server-side rendered, as long as they only use a subset of the full React API.

We could do something similar, where we could bring certain HTML+ERB templates/partials from the server-side to the client-side and allow them to be (re-)rendered on either the server or the client as long as they only use a limited subset of ERB, essentially “ERB client components”.

In that case, templates would be compiled or transpiled for client-side hydration, which could allow for use cases like enabling optimistic UI updates, improved offline support, or limited interactivity without full server round-trips.

Ideally, the partials/components would only take in value objects using primitive types that we would be able to support in both Ruby and JavaScript. Full-blown object like ActiveRecord instances or collections wouldn’t be supported.

But, this is something we could detect at runtime in development and guide users on how to architect their partials/components to be fully compatible so that these templates could be used server- and client-side.

Level 6 - External Components

And finally, we explore the ability to mount external UI components (like React, Vue, Svelte, …) directly within *.html.herb templates. This gives users the flexibility to use the rich ecosystem of already available components in the JavaScript ecosystem without having to abandon the Rails view layer.

The idea is to have a initializer file, similar to how importmap-rails does:

In that file (like config/initializers/reactionview.rb) you would be able to register existing components from NPM packages, or tell it to import components from a certain directory within your app:

With the components registered, they will be automatically available within the context of *.html.herb files:

This approach is less invasive compared to Inertia.js Rails which requires you to render a whole page with Inertia.

With this approach users are still able to use ERB next to their components in the same view template, without having to give up anything.

The engine would know which components are client-side and would know how to render them server-side so that can be mounted/hydrated on the client-side.

This approach is very similar to Turbo Mount, with the difference that this is built right into the engine, is tightly integrated, has built-in editor tooling, requires no setup and just works out of the box.

More Ideas to Explore

One-off Stimulus Controllers

I heared a lot of people are somewhat frustrated with “one-off” Stimulus Controllers in their application. One-off Stimulus Controllers that are only really ever used in one place within the app. A lot of people have been recommending Alpine.js for that use case.

I like a lot of the ideas and advancements Alpine.js brings to the table the over Stimulus, but the idea of writing raw JavaScript inside HTML attributes somehow feels really wrong to me.

There might be some more opportunities to create some kind of “Inline Stimulus” version too. I really like the way Svelte handles this.

Instead of having the Stimulus Controller in it’s own *_controller.js file, we could think of way to have a <script> tag within the file that’s only being transformed/applied to the current file you are in. So you could write some custom one-off JavaScript that’s only being used and available/accessible in this one file you are writing the code in.

View File Scoped CSS

We could do something very similar to CSS and <style> tags as well. This is largely inspired by Vue.js, that allows you to use a special <style scoped> tag, that gets transformed when the template gets compiled.

The idea is that you can write a <style scoped> tag, and all of the CSS rules you are declaring are being scoped to that single file.

In this case, the <style scoped> gets transformed to a regular <style> tag and gets scoped with a special selector that gets inserted at compile time.

In this case, it’s adding a new data-* attribute to both all CSS rules within the <style> tag, and the data attribute to the HTML element itself that’s being used to scope the style. With that, we make sure that none of these styles are leaking to other parts of the application, which is quite clever.

Selective Rendering

And the final idea is “Selective Rendering”. This might come in super handy when paired with concepts like Turbo Frames. Let’s say you have the following view file:

Instead of rendering the whole view, we can pass the partial an argument to look for a certain selector.

Since Herb knows about the structure, hierarchy, the HTML elements and it’s attributes we could filter by a certain selector you pass it, and precompile a subsection of that template.

In the case of the Turbo Frame and the #reviews selector we could prepare and precompile only the following subset of of the bigger template.

This would allow to optimize render performance, since you only ever render what you actually need, which in the case of Turbo Frames is usually only the Turbo Frame itself.

The good thing is that we could also tell that a certain selector wouldn’t match anything in the given template, since we can statically analyze and search for these selectors within the template you are trying to precompile and render.

Why this direction

Action View and ERB are here to stay. Rails remains a full-stack framework built around server-rendered HTML. If we want that story to continue to scale, we need first-class HTML tooling and a clear on-ramp to richer UIs when needed, without forcing apps to abandon ERB.

The idea is to bring more of these modern frontend features to Rails so that there is less of a need to abandon the Rails way. Rails shouldn’t discourage the use of (modern) JavaScript. Rails should embrace it. Rails should also embrace modern web standards and the exciting new APIs and features browsers ship with today.

Rails should provide good defaults and built-in options/migration paths when you need more. This is what Rails was always known for. I believe that the view layer needs to scale in the same way as everything else in the Rails framework does.

But it’s important to me to say that this is a vision. If we, as a framework and community, want to stay relevant we need to explore what’s possible. New innovations require exploration.

Even if none of this is viable in production it’s still worth exploring. The Herb tooling that came out of this is so valuable already, and I also believe that there’s more to achieve with the ReActionView initiative.

Conclusion

Prism had a big effect on Ruby internals and the tooling landscape in general. Prism now ships with Ruby 3.4+ as the default parser. And I believe Herb already had a similar effect for HTML Templating and Tooling.

Herb started as a Parser and is now an ecosystem of valuable tools that Rails developers are using on a daily basis. Meanwhile, ReActionView started as a vision to address some of the shortcomings in the Rails View Layer. Today it might be just an alternative ERB Rendering engine, but I believe that this already shows what could be possible.

We can push more boundaries and bring the whole Rails Framework forward so that it can hold up with the current JavaScript stacks. Also so that teams don’t have to abandon the beauty of Action View.

The community has built incredible tooling for Ruby itself. Now it’s time to bring that same care to the view layer. With Herb and ReActionView, I believe, we have a path to level up the view layer and make Rails’ story awesome for the frontend.

Rails has a unique position as a full stack framework and I want to keep it that way. I want to keep Rails as attractive and competitive as possible for both people that are new and people that have been using Rails for a long time.

Thanks & links

I’m incredibly grateful for all the support, feedback, encouragement, and motivation I got over the span of 2025.

Thank you to everyone who came to my talk, shared ideas/feedback, or took the time to chat in Amsterdam. ❤️

If you try the tools and hit issue, please feel free to open an issue. The feedback loop is what makes this really useful.

I’m super excited about the future of the Rails view layer, and would love to see how far we can take it!

Thank you!

— Marco

Slides: Speaker Deck
ReActionView: https://github.com/marcoroth/reactionview
Herb: https://github.com/marcoroth/herb
GitHub Sponsors: https://github.com/sponsors/marcoroth

Introducing the Herb Linter, Formatter, and a Vision for the Future of Rails Views

2025-07-17T09:00:00+00:00

The final RailsConf just wrapped up in Philadelphia last week. Here’s a recap of my talk, what we launched, and where we’re going next.

RailsConf this year was special for me, not just because it was an honor to be part of the final edition of such an important event in the Ruby community, but also because I got to share a new release and vision for the framework I’ve used most of my career.

This blog post is a summary and recap of my RailsConf 2025 talk titled “The Modern View Layer Rails Deserves: A Vision for 2025 and Beyond”.

Herb v0.4.0: Linter, Formatter (Preview), and a Big Step Forward

The first headline from the talk is the release of Herb v0.4.0, and with it, the first versions of the Herb Linter and a first preview version of the Herb Formatter.

The most notable things in the release are:

Herb Linter
Herb Formatter (Preview)
Improved Language Server
Improved Visual Studio Code Extension
Parser Bug Fixes and compatibility improvements

You can check the full Herb v0.4.0 changelog on GitHub.

These new tools are all built on top of the Herb Parser, a new fault-tolerant, HTML-aware ERB parser written in C, which I introduced at RubyKaigi earlier this year. These tools aim to bring the modern developer experience we expect to *.html.erb files.

But more importantly, they’re fully integrated into the Herb Language Server and the improved Visual Studio Code extension, which now:

supports linting and auto-formatting directly in the editor
offers whole-project analysis
includes a new sidebar panel for diagnostics and the analysis results

You can use the linter and formatter via the CLI or in-editor.

Herb Linter

The Ruby Style Guide provides recommendations and best practices for Ruby code. Linters like RuboCop and Standard make this actionable by implementing and enforcing these guidelines.

But for view files, we haven’t had many resources or style guides on writing good views. The Herb Linter helps guide developers towards best practices and avoid common mistakes in HTML+ERB files.

CLI

You can run the linter using the CLI and get nicely annotated and syntax highlighted snippets for the offenses the linter found right in the console.

At the end of the run, you’ll get a summary of the most violated rules:

For lots of offenses, use the --simple flag for more compact output:

Language Server Integration

While a good CLI is important, catching offenses directly in your editor provides an even tighter feedback loop:

Your browser does not support the video tag.

Herb Linter Language Server Integration

All the Linter rule offenses have a clickable Rule ID in their diagnostic popup you can click on to learn why this rule exists and why it’s important:

Clicking on a rule ID will open the documentation for that specific linter rule:

At the end of each linter rule documentation page you will find a few examples of how good and bad code looks like according to the rule:

We also run the Linter over all code blocks in the documentation and annotate the examples using Shiki and Twoslash.

This really helps to understand what’s wrong about the given examples. I hope that this makes the rules easier to understand, easier to reason about, and more actionable since you can see exactly where the violation is and can see the actual linter message right in the example.

More Linter Rules and Feedback

You can check out the full list of already implemented linter rules in the documentation. There are also a lot more rules to be implemented if you are looking for a way to contribute to the project.

Please open an issue if you can think of any rule the Herb Linter should support. I would also be very thankful if you could report any false-positives the Linter found in your code.

You can use the quick fix action to report an error, it will open a new GitHub issue and pre-fill some of the metadata automatically for you.

Herb Formatter (Preview)

Alongside the linter I also wanted to release a preview version of the Herb Formatter so people can try it themselves on their own templates, with the hope that we can catch bugs and edge cases the formatter doesn’t handle well yet.

Please, feel free to report any case the formatter formats the document in a weird or unpredictable way.

Format on Save

The Herb Formatter is also fully integrated into the Herb Language Server but is disabled by default for the time being.

You can enable the Formatter in Visual Studio Code in the settings, but please make sure to only run it over documents you can revert/restore:

Once enabled it will format your files on save as long as there is no error present in the document:

Your browser does not support the video tag.

Visual Studio Code Herb Format on Save

Seeing the formatter coming to life is a very satisfying feeling, as this has been something I wanted to have for the longest time. Now this dream is slowly turning into reality and I’m super excited to see it evolve!

If you see the formatter behaving in an unexpected way or tripping over something, please open an issue! I’d love to get this right so that we can settle on a good default for the community.

A Vision For The Rails View Layer

Context

Action View has been part of Rails since it initially released in July 2004 with Rails 0.5.0.

Rails is an open source web-application framework for Ruby. It ships with an answer for every letter in MVC: Action Pack for the Controller and View, Active Record for the Model. From the original announcement

ERB (Embedded Ruby) has been the default since the first release and still is today.

Here are some of the big changes in Action View over the last 20 years:

2005 – Rails 1.0 – Layouts + Partials
2007 – Rails 2.0 – *.html.erb (show.html.erb instead of show.rhtml)
2007 – Rails 2.3 – render_component deprecated
2010 – Rails 3.0 – Automatic HTML escaping

Auto-Escaping and SafeBuffer: One of the biggest conceptual changes in Rails 3 was the introduction of automatic HTML escaping by default in templates. Prior to Rails 3, developers had to explicitly call the h helper to escape user-provided content.
2010 – Rails 3.0 – ActionView::Template

The Rails-Merb merge brought some internal improvements to ActionView. Templates were now handled by an ActionView::Template abstraction with a unified interface for different handlers like ERB, Builder, etc.
2013 – Rails 4.0 – Russian Doll Caching

Tracks template dependencies with digest keys
2014 – Rails 4.1 – Action View Variants

actionview is extracted as it’s own gem
2017 – Rails 5.1 – form_with
2020 – Rails 6.1 (Beta) – ActionView::Component

While ActionView::Component didn’t make it into Rails 6.1 but eventually became ViewComponent.
2020 – Rails 6.1 – render_in(context)

Even though ActionView::Component didn’t make it into Rails we got the new render_in API that allows pretty much any Ruby object to be rendered by the Rails render method as long as it implements the render_in interface.
2021 – Rails 7.0 – Hotwire by default
2023 – Rails 7.1 – Partial Strict Locals

Even though Action View has seen a lot of improvements and optimizations over the years, I think it’s fair to say that the public API of Action View hasn’t really changed a lot over all these years.

Most of the features/changes were additive and not disruptive, which is great, since that makes the API really stable and easy to rely/build on.

Even though we have seen a lot of tools, approaches, templating engines and syntaxes come and go over these years, Action View and ERB are still going strong and aren’t going anywhere. They are also going to remain the default in Rails for the foreseeable future.

Rails always has been about server-side rendered HTML and is going to stay with that too. In the end, Action View is really what makes Rails a true full-stack framework. But this also means that advanced HTML tooling is only getting more important if we want to keep up with the developer tooling in the greater web ecosystem.

But this server-side rendered approach doesn’t come without its issues:

Some of these problems are solved with tools like ViewComponent, nice_partials or other similar tools, but there’s still a lot left to be solved, especially in the developer tooling space.

But what if we could solve these problems at a deeper level? What if we could improve not just the tooling, but the rendering engine itself?

A new ERB Rendering Engine

The Herb project started with a simple goal: build better HTML+ERB tooling (formatters, linters, language servers). There was no plan to build a new ERB rendering engine.

But the more and more I worked on fulfilling the tooling vision I started to realize that there also may be an opportunity to improve the way we render HTML+ERB templates.

Currently all ERB rendering engines treat the non-Ruby code as Strings, making them a String Templating Language. But what we want, ideally, is an HTML Templating Language: an engine that cannot produce invalid HTML, because the engine is aware of the HTML structure around the ERB tags in the template.

And that’s when I started to think about this a bit more, and what I came up with is a vision for an ActionView-compatible framework for Rails, code-named “ReActionView”:

ReActionView

I structured the ReActionView vision into 6 adoption levels, the more we implement, the more advanced it gets. And we certainly don’t have to implement all levels for this to be useful.

It’s important for me to note that this is a vision and that new advancements require exploration. Even if none of this is viable in production it’s still worth exploring to see how far we can go, how far we can push things, or discover other patterns by taking some ideas to an extreme, even if they are not viable.

But with that out of the way, let me walk you through the six adoption levels.

Level 1: Better Feedback and Developer Experience

One of the nice features I always liked in Rails is the interactive exception screen, that would show you all sorts of helpful context like backtraces, environment variables, the failing line and surrounding lines, and most importantly the interactive debugging console.

This works great if the exception happens in an .rb file. Sadly it doesn’t work as nicely if you have syntax errors in *.html.erb files.

And I think that’s something Herb can help with and improve. A lot of the Herb tooling is inspired by Vite and it’s great ecosystem and of tools around it.

In Vite, if you introduce an HTML error, it will instantly show you this error message on the screen, even without having to reload the page.

Since Herb can already tell if something is wrong/incorrect about a HTML+ERB template we can improve the exception screen to show what and where something is wrong in the template.

On this level Herb acts as a parser and analyzer. It catches common issues in real time.

Level 2: HTML-aware ERB rendering Engine

On this level, we would take the ERB rendering engine from being a String Template Engine to an actual HTML Template Engine. The idea is to keep everything backwards compatible, as long as the current *.html.erb view files already contain and render valid HTML.

Instead of using ERB’s default engine, templates could be rendered using a new Herb rendering engine.

Part of the inspiration of ReActionView and the actual project name “Herb” comes from Elixir and their way of approaching templating languages.

Elixir has an ERB equivalent called EEx, which is very similar and has almost identical syntax. The interesting piece is that Phoenix LiveView/Elixir also has a more specific version of EEx which combines EEx with HTML, called HEEx.

Looking at this, we don’t really have an equivalent in the Ruby ecosystem that combines HTML with ERB in a rendering engine. And this is where the name Herb comes from, the H from HTML and the ERB, following the naming scheme of HEEx.

Let’s look at an example how a String Template Engine would compare to a HTML Template Engine. Given the following ERB template (which has a missing </h1> closing tag):

<h1>Hello, <%= name %>!

and ask Action View to compile it using:

template = ActionView::Template.new(
  "<h1>Hello, <%= name %>!",
  "test.html.erb",
  ActionView::Template::Handlers::ERB,
  locals: [:name]
)

compiled = template.handler.call(
  template,
  template.source
)

it will happily compile the template. Action View is only concerned about turning the given template into compiled Ruby code that concatenates strings:

Whereas, if we would build a new .herb HTML+ERB (Herb) engine, that would care about the surrounding HTML in an ERB template and we tried to compile it using Action View, it would not compile and tell you what’s wrong with the given template.

This way, we can guarantee that the rendering engine cannot even produce invalid HTML and would just raise if Action View tried to compile an invalid template.

Plus we get the benefit of the rendering engine directly telling us what and where something is wrong about the template we tried to compile, which makes the whole developer experience a lot nicer and more predictable, instead of it silently failing.

Level 3: Action View Optimizations

Given that we have much more introspection and structural awareness of HTML+ERB files now, there might be more opportunities to do lower-level optimizations for when Action View is trying to compile a template.

John Hawthorn did some similar work on actionview_precompiler (and dynamic_locals) that is very interesting and might be something we could use as a starting point or improve upon.

Another possible optimization: inlining <%= render partial: "post" %> calls. This would eliminate runtime partial lookups by directly embedding the partial content into the compiled view.

Instead of compiling to @output_buffer.append=( render partial: 'post' );, we would read and inline the partial at compile time.

This requires confidence in identifying the right partial, which is why our linter rules encourage explicit render arguments. Worst case: we fall back to current behavior. Best case: we eliminate runtime lookups.

I have to be 100% honest here, I haven’t really looked into how feasible these kind of ideas/optimizations are in practice, but it’s hard to imagine that we wouldn’t be able to get something out of this.

If you have any ideas or insights here, please reach out and let me know! I’d love to chat and hear what we could do or how we could approach this.

Level 4: Reactive ERB Templates

Your browser does not support the video tag.

Reactive ERB templates

Think of this as Phoenix LiveView HEEx-like updates, but still keeping it Rails-y by using the existing .html.erb view files.

This would also allow for a lot of applications to be simplified and could soften the need for Turbo Frames, Turbo Streams or Turbo Morphing in the future, since the engine itself is fully aware of the state and how it has to reflect the updates in the DOM.

For this to be viable we would need to find a way to serialize the state, detect state changes and then be able to broadcast these updates to the browser.

Opt-In Syntax and Strict Mode

While we could make these reactive ERB templates work with regular *.html.erb files, there is also an opportunity to introduce a new *.html.herb file-ending that would have this behavior turned on by default.

This opt-in approach allows users to gradually adopt this new style of writing views, while keeping existing view files compatible. For views that don’t require any advanced interaction you would just keep the file-ending as *.html.erb. You would only use and rename existing views to *.html.herb where it’s needed and makes sense.

The philosophy of progressive enhancement is really valuable here and doesn’t require you to follow an “All or nothing” approach when migrating/adopting this new approach.

Adopting a new file-ending would technically also allow for new syntax to be introduced. I’m not saying we need to introduce new syntax, but being able to render (view) components using a capitalized first character (similar to Rux/JSX) could prove to become very handy.

class NameComponent < ApplicationComponent
  def initialize(first_name:, last_name:)
    @first_name = first_name
    @last_name = last_name
  end
end

and render it using:

<NameComponent first-name="Rails" last-name="Conf" />

Another thing we could enforce using a new file-ending with stricter rules would be things like:

Check for invalid syntax
Check for valid HTML5 (via Nokogiri)
Accessibility/A11y Checks (i.e. missing alt attributes on <img> tags)
Cross-site scripting/XSS Checks (i.e no unsafe ERB interpolation)
Only one element with the same ID
…

These checks could fail the compilation step, making sure that the templates adhere to a certain level of quality, safety, semantic correctness, and compliance with modern web standards and best practices before they ever reach production.

Level 5: Universal client-side Templates

Level 6: External Components

The idea is to have a initializer file, similar to how importmap-rails does:

With the components registered, they will be automatically available within the context of *.html.herb files:

This approach is less invasive compared to Inertia.js Rails which requires you to render a whole page with Inertia.

With this approach users are still able to use ERB next to their components in the same view template, without having to give up anything.

The engine would know which components are client-side and would know how to render them server-side so that can be mounted/hydrated on the client-side.

How It All Fits Together

Today’s tools (the linter and formatter) make .html.erb safer and easier to work with. But they’re also building blocks for tomorrow’s ReActionView.

The progression is natural:

Parser understands HTML+ERB structure
Linter/Formatter enforces best practices and consistency
HTML-aware rendering prevents invalid markup at compile time
Reactive templates efficiently update only what changes
Universal templates work on both server and client

It’s a roadmap designed for gradual, non-disruptive adoption that can be progressively enhanced where needed that feels Rails-like.

Help Improve the Herb Parser

While Herb already handles a wide range of real-world ERB templates, there’s always room to improve. You can help make Herb even better by running it on your own projects and reporting any issues it finds.

Simply run these commands in your project:

cd your_project/

gem install herb

herb analyze .               # analyze all *.html.erb in the current directory
herb analyze app/views       # or just inside a specific directory

This will analyze your HTML+ERB files and highlight any edge cases or parser errors. If it breaks on your files, that’s great! Every edge case helps improve the parser and improve Herb for everyone.

If you have any failing files it’s either because you actually have a legit error in your view file or because the parser timed out while trying to parse your file. You will see that it generates a .log file which will have more details on why and how it failed.

If you are able to, I would appreciate if you could open an issue with the template content. If you can’t share the content of the view files directly, it would mean a lot if you could try to isolate/replicate the error.

Conclusion

Back in April, Herb initially only released with the parser, but now it’s become a more complete toolkit for HTML+ERB files.

With the release of v0.4.0, we finally have the foundation for better developer experience in the Rails view layer: linting, formatting, diagnostics, and instant feedback. But more importantly, we have a clear path forward.

What HEEx is for Phoenix LiveView, Herb could be for Rails ReactionView. Rails revolutionized web development and continues to evolve, but its view layer has remained largely unchanged while frontend needs have evolved dramatically.

ReActionView isn’t meant to replace ActionView or ERB. It’s a chance to evolve it. Carefully, incrementally, and in a way that feels true to what makes Rails great. I’m planning on releasing a first prototype version of ReActionView at my EuRuKo 2025 talk in September in Portugal.

The Prism parser had a big effect on Ruby internals and the Ruby tooling landscape. Now it’s time to bring that same care to the view layer.

With Herb, I believe we have a path to level up the view layer and think that Herb could have a similar effect for HTML Templating, tooling, and maybe even a new rendering engine.

If you missed the talk, you can find the slides on Speakerdeck. In the meantime, I’d love for you to try the tools, file issues, and join the conversation.

Thanks to everyone who came to the talk in-person, asked questions, shared their excitement, and encouraged the project over the past year. This is just the beginning.

Thank you!

- Marco

Herb Language Server and Visual Studio Code Extension

2025-06-20T18:00:00+00:00

Back in April, I introduced Herb, a new HTML-aware ERB parser. Herb was designed from the ground up to deeply understand .html.erb files, preserving both HTML and embedded Ruby structure without losing any details.

It laid the technical foundation for a modern, robust developer experience around HTML+ERB. But at the time, Herb was mostly “infrastructure”, useful for tool builders, but not something most developers could immediately plug into their daily workflow and make use of.

Today, that changes.

I’m excited to announce the release of the Herb Language Server and the Visual Studio Code Extension.

Bringing Herb to Your Editor

With the new Herb Language Server and Visual Studio Code Extension, Herb is now directly usable in your everyday development environment.

Diagnostics: Catch unclosed tags, mismatched elements, invalid nesting, and ERB syntax issues
Instant Feedback: See errors and warnings as you type, not after you reload your app or run a linter
Whitespace-Aware Formatting (soon): Because Herb preserves exact structure and can fully understand every detail about your view files, it will be able to quickly auto-format HTML+ERB files on save.

Unlike many existing tools, Herb tries to treat HTML+ERB templates as they are: a mix of markup and Ruby code. This makes it possible to provide feedback that’s a bit more aware of how HTML+ERB views are usually written.

Right now, we only provide a pre-packaged Visual Studio Code extension. But since the language server follows the standard Language Server Protocol (LSP), it can be integrated into any editor that supports LSP, including Vim, Neovim, Zed, RubyMine, and many others.

If you’re interested in helping build or improve integrations for other editors, I’d be happy to collaborate.

Why This Matters

Ruby and Rails developers write a lot of HTML+ERB. Especially now with all the popularity around Hotwire, Turbo, Stimulus, HTMX and similar tools.

And yet, for years, ERB tooling has lagged behind nearly every other part of the modern development stack. No great formatter. Limited linting. Barely any language-server support. And definitely no structural understanding of how HTML and Ruby interleave.

Herb changes that. With this release, we’re one step closer to giving Ruby developers the kind of real-time, context-aware feedback that frontend developers have come to expect from their TypeScript, JSX, React or Vue tooling.

Easy to Install, Easy to Use

The Visual Studio Code Extension is available now on the Visual Studio Code Marketplace.

Search for “Herb LSP - HTML+ERB Language Tools” in VS Code extensions
Install and open any .html.erb file
The extension activates automatically

The language server is fully open source, built directly on top of Herb’s C-powered parser with the JavaScript/Node.js and WebAssembly bindings.

A Foundation for More

This is just the beginning. With Herb’s parser and language server in place, future additions are already on the roadmap:

Auto-formatting with safe whitespace-preserving transformations
Better inline go-to-definition and symbol navigation for embedded Ruby
Cross-file component and partial analysis
Turbo and Stimulus LSP integration
Rails-aware template diagnostics
and a lot more!

The long-term goal remains the same: make .html.erb files as productive, reliable, and enjoyable to work with as any modern frontend framework.

A Step Toward Broader Integration

This release is just the first step in making Herb more widely available. The goal is to get it into the hands of developers so it can be tested, battle-hardened, and refined against real-world HTML+ERB code.

Long-term, I hope Herb won’t stay as a standalone language server forever. My goal is to collaborate with other tool developers and see Herb’s parser integrated wherever it makes sense, inside formatters, linters, Rails developer tools, and ideally directly into existing tools like the Ruby LSP.

In the best case, one day this standalone Herb Language Server won’t even need to exist because its capabilities will have been folded into the standard Ruby tooling experience, no extra installs, no configuration, just better HTML+ERB support by default.

Help Improve the Herb Parser

In the meantime, while Herb already handles a wide range of real-world ERB templates, there’s always room to improve. You can help make Herb even better by running it on your own projects and reporting any issues it finds.

Simply run these commands in your project:

cd your_project/

gem install herb

herb analyze .               # analyze all *.html.erb in the current directory
herb analyze app/views       # or just inside a specific directory

This will analyze your HTML+ERB files and highlight any edge cases or parser errors. If it breaks on your files, that’s great! Every edge case helps improve the parser and strengthen Herb for everyone.

Try It Today

If you write HTML+ERB views, I encourage you to try it out.

Visual Studio Code Extension: Herb LSP - HTML+ERB Language Tools
Herb Language Server: GitHub repo

As always, feedback is welcome and appreciated. This is a community effort, and the more real-world projects Herb sees, the better the tools will become.

Podcast Appearance: Talking about Herb

If you’re curious to hear a bit more of the background story behind Herb, I recently joined Jared Norman on his podcast Dead Code to talk about the project, developer tooling, and parsing in general.

You can listen to the episode here: Herbicide with Marco Roth.

Thanks to everyone who supported the initial Herb parser launch. With the Language Server and Visual Studio Code extension, we’re finally turning that low-level parser into something you can see and feel, every day, inside your editor.

Marco

Introducing Herb: A new HTML-Aware ERB Parser for smarter developer tooling

2025-04-16T05:00:00+00:00

Announced on April 16 at RubyKaigi 2025 in Matsuyama, Japan.

Today at RubyKaigi 2025, I’m excited to introduce a project I’ve been heavily focusing over the last few months:

🌿 Herb — a fast, modern, and HTML-aware ERB parser, designed from the ground up for developer tooling.

Why Herb?

As web development in Ruby evolves - especially with the rise of Hotwire and HTML-over-the-wire patterns - it’s become clear that traditional ERB tooling hasn’t kept up.

Rails has always been a joy to work with and always stood out in it’s developer experience and always had a strong view layer, centered around ERB templates.

With the introduction of Hotwire and HTML-over-the-wire becoming the default in Rails 7+, we’re writing more HTML+ERB than ever

Herb is designed to bridge that gap. It brings real-time, editor-friendly parsing capabilities to ERB, enabling a wave of new tools like formatters, linters, and language server integrations (LSPs).

Herb is fast, fault-tolerant, and deeply aware of the HTML structure. It’s built for developers and tooling developers who want precise, reliable tooling without compromise.

Even as Ruby developer tools have improved — thanks to projects like Shopify’s Ruby LSP and Prism — view files have largely been left behind. HTML embedded in .html.erb files remains a black box:

No (or limited) jump-to-definition for view helpers
No way of understanding the HTML semantics in view files.
No syntax-aware formatting or linting
No way to understand what ActionView’s form_with, link_to, or render will output
No editor support for HTML-aware ERB analysis or transformation

In the 2024 Rails Developer Survey Stimulus climbed to the number one spot in the JavaScript frameworks sections.

This is especially limiting for modern Rails apps, where Stimulus, Turbo, and Hotwire all rely heavily on writing rich HTML on the server.

A Parser Built for Tooling

That’s where Herb comes in.

Herb is a new parser written in C, purpose-built to understand interleaved HTML and ERB. It gives tools the ability to reason about HTML structures even when they’re dynamically generated with Ruby helpers and nested in ERB tags.

Herb is:

HTML-aware, with a purpose-built lexer and parser
ERB-aware, with integration points to Ruby’s official Prism parser
Error-tolerant, to support real-world code and in-editor feedback
Whitespace- and structure-preserving, critical for formatters and linters
Built for speed, enabling real-time updates in developer tools
Designed to be embeddable, with bindings for Ruby, JavaScript, and more

Herb produces a full AST representing the structure of HTML + ERB templates, making it ideal for:

Building ERB-aware formatters and linters
Writing intelligent LSP features (e.g. autocomplete inside ERB)
Performing static analysis on server-rendered markup
Refactoring or transforming views at scale
Highlighting issues with tag mismatches or invalid nesting

Why Not Nokogiri?

You might ask: why not just use Nokogiri?

Nokogiri is great for working with HTML — but it’s an HTML-compliant parser. That means it fixes your mistakes (autocloses tags, moves nodes around) and doesn’t preserve exactly what’s written in your .html.erb files. That’s how it’s intended to work and what you would expected from a HTML5 parser.

Don’t get me wrong, Nokogiri is an awesome tool and is perfect when trying to parse HTML as browsers would, but it sadly doesn’t work great for developer tooling.

With Herb, what you parse is exactly what you wrote. No assumptions. No transformations. Just the raw, structured syntax tree of your view template — including whitespace, comments, and malformed fragments.

This allows us to exactly see what you’ve written in your view files and allows us analyze the source as it it is. This also allows use to write tools like formatters and linters to annotate the view files with diagnostics to help you find syntax or semantic errors.

What’s Next

Today is just the beginning as with the release of the parser we now have the foundation to build more advanced tools.

For now, Herb focused on empowering developer tools: LSPs, linters, formatters, analyzers, refactoring tools — the kind of tools we’ve long had in other ecosystems, but that Ruby, and HTML+ERB specifically, has lacked in the view layer.

Now with this parser released, we are looking to improve existing tools in our ecosystem, including:

and possibly more!

Getting Started

Ruby

Herb is bundled and packaged up as a precompiled RubyGem and available to be installed from RubyGems.org.

Add gem "herb" to your Gemfile and call Herb.parse_file() to get started.

require "herb"

Herb.parse_file("path/to/view.html.erb")

Check out the Ruby bindings documentation to learn more.

JavaScript

We are also shipping two NPM packages for the use in Node.js and a WebAssembly build for the use in the browser. You can install the @herb-tools/browser or @herb-tools/node package from NPM respectively.

Check out the JavaScript bindings documentation to learn more.

Playground

We also have an interactive browser-based parser playground to explore how the parser works.

The playground uses the @herb-tools/browser and WebAssembly build to run the parser fully in the browser.

Check out the interactive playground to play with the parser output yourself.

Summary

For my RubyKaigi talk I prepared a summary slide. Here is the most important information from this talk on one slide:

A Gateway to Better Tooling

Herb isn’t just a parser - it’s a foundation for better HTML Templating Tooling. A better HTML+ERB Syntax Tree, better HTML+ERB editor support, and meant to level up the developer experience across the board.

Whether you’re building modern Rails apps or maintaining legacy templates, Herb will bring clarity, structure, and modern ergonomics to your HTML+ERB views.

I’m excited to share this with the Ruby community today and look forward to seeing how you use it.

→ View the documentation
→ Try the playground
→ GitHub repo

I’m planning to write more about Herb in the next few weeks to touch on the technical details, architecture, design-decisions, differences and more!

Let’s build the tooling the modern Rails view layer deserves. 🌿

— Marco

Introducing RubyEvents.org: RubyConferences.org and RubyVideo.dev Join Forces to Build the Ruby Events Platform

2025-04-03T15:00:00+00:00

Over the years, RubyConferences.org has been a trusted source for discovering upcoming Ruby conferences worldwide. Meanwhile, RubyVideo.dev has grown into an extensive archive of Ruby conference talks and events, aiming to preserve and share the knowledge shared on stage by the community.

Today, we’re excited to announce the next chapter: RubyConferences.org and RubyVideo.dev are merging into a new, unified platform - RubyEvents.org.

RubyEvents.org is built to be the central platform for all things Ruby events - not just conferences, but also meetups, workshops, hackathons, CFPs, and more. Whether you’re a speaker, attendee, organizer, or sponsor, RubyEvents.org is designed to serve your needs.

Why Merge?

RubyConferences.org started with listing Ruby conferences and Call For Papers, and has been the go-to resource over the past decade. In 2024 we also added the support to keep track of Ruby meetups around the world.

Adrien Poly started RubyVideo.dev in 2023 with the ambition to aggregate all Ruby-related videos in one place with searching capabilities to facilitate discovery, all while showcasing some of the new Rails technology.

Over the last two years these sites became closer and closer and created some duplicate effort to keep both sides up-to-date. By bringing them together, we can:

Offer a single place to discover and explore Ruby events
Archive slides, photos, and recordings alongside each event’s details
Create public speaker profiles with talk histories
Help meetup organizers find speakers and promote their events
Provide conference organizers with tools to run CFPs, attract sponsors, and build visibility
Give sponsors a way to showcase their community involvement across multiple events

A New Home for the Ruby Community’s Event History

Many historical Ruby conference websites have disappeared over time and aren’t accessible anymore, making it challenging to access important information about these events. Details such as speaker lineups, dates, venues, and other valuable context are often lost to the digital void, erasing pieces of our community’s history.

With RubyEvents.org, past events aren’t lost to time - quite the opposite. The platform preserves and expands upon the comprehensive event archive from RubyConferences.org while integrating the rich talk data from RubyVideo.dev. This creates not just an accurate historical record, but a vibrant archive that maintains the unique identity of each event through their original assets, including event logos, banners, branding, and more!

Each event gets a dedicated page, and over time we’ll be adding recordings, speaker information, and more. If you’ve spoken at or organized a Ruby event in the past, your contributions now have a way of being archived and preserved in the RubyEvents.org archive. If they aren’t on RubyEvents.org yet, feel free to open an issue or even better, contribute it to RubyEvents.org.

What’s Next?

This is just the beginning.

We’re actively collaborating with conference and meetup organizers to evolve RubyEvents.org into a comprehensive platform that supports the entire lifecycle of Ruby events. From managing Call for Papers and publishing announcements, to displaying event schedules, archiving talk recordings, and sharing post-event updates - our goal is to create a seamless experience for everyone involved in the Ruby community’s events ecosystem.

If you’re running a meetup or event, we’d love to help you list it. If you’ve given a talk, we want to index it. If you’re a company that’s supporting Ruby events, we want to help you get the recognition you deserve for supporting our awesome Ruby community.

We’re also excited to share that we have been building a Hotwire Native RubyEvents.org iOS app that’s completely open-source. It serves not just as a companion app, but as a reference application for building modern, real-world Rails apps and leveraging Hotwire Native to create powerful mobile experiences.

👉 Read more about the iOS app

Our goal is to make this app a learning resource for anyone interested in seeing how the latest tools in the Rails ecosystem can come together in a production-quality application. We also want to create opportunities for early-career developers to contribute to a real-world app that people actually use. If you’re interested in contributing, check out the GitHub repo and/or visit the Contributions Page on RubyEvents.org.

Please reach out if you don’t know where to start or need any guidance, I would be more than happy to help you get your first contribution to RubyEvents.org!

Thank you to everyone who’s supported RubyConferences.org and RubyVideo.dev over the years. We’re excited to take this next step together, and we hope RubyEvents.org becomes a valuable home for the whole Ruby community.

Special thanks to Jon Allured and Cameron Daigle for creating, maintaining, and stewarding RubyConferences.org over the years and to Adrien Poly for starting RubyVideo.dev in the first place. This project wouldn’t exist without their foundational work.

If you have feedback, ideas, or want to get involved, feel free to reach out.

You can reach us on Bluesky, Twitter/X, Mastodon, or LinkedIn.

Thank you!

Introducing the RubyEvents.org iOS App

2025-04-03T15:00:00+00:00

As announced in “Introducing RubyEvents.org: RubyConferences.org and RubyVideo.dev Join Forces” — we are in the process of merging two long-standing community efforts into a single home for all things Ruby events.

To mark this new beginning, we’re excited to share another major milestone:

Say hello to the RubyEvents.org iOS App, built with Hotwire Native.

Ruby is Back — And So Are the Meetups

We’re seeing the reboot and rise of Ruby meetups around the world, and for the first time since 2015, we’re breaking records again.

With all this momentum, we wanted a better way to keep up with what’s happening — whether it’s a meetup, conference, workshop, or hackathon. The RubyEvents.org app brings it right to your phone.

A Native Experience, Powered by Rails

This app is also meant as a public resource and a reference project for how to build modern mobile apps using Rails.

This architecture gives you the best of both worlds: server-rendered HTML for fast iteration and low complexity, plus native UI when and where you want it. Having more open-source Hotwire Native apps is going to be value for the community.

Built for the Community

This app is meant to celebrate the launch of RubyEvents.org and kick off a new era of Ruby community infrastructure. But it’s only the beginning.

RubyEvents.org is an open platform, and so is the app. We welcome contributions, ideas, and improvements — whether you’re a designer, organizer, mobile dev, or just someone excited about Ruby’s future.

We’re also working on an Android version of the app and would love help bringing it to life. If you’re familiar with Android or just interested in learning, this could be a great way to get involved too.

Get Involved

The RubyEvents.org app isn’t just for finding events — it’s about supporting the people behind them.

We hope it becomes a tool to connect speakers with meetups, organizers with sponsors, and attendees with the vibrant Ruby community near them (or around the world).

If you want to contribute, suggest a feature, or just follow along, check out the GitHub organization to place feature request, share feedback or contribute.

The RubyEvents.org iOS app is now available on the App Store.
Start exploring Ruby events near you — and around the world.

➡️ Download the app on the App Store

This is just the start. Please get in touch if you have any questions or want to help out.

You can reach us on Bluesky, Twitter/X, Mastodon, or LinkedIn.

Let’s build the future of Ruby events — together.

– The RubyEvents.org Team

2024 Year-in-Review

2025-01-23T15:00:00+00:00

As 2024 recently wrapped up, I wanted to take a moment to reflect on the year.

Personally, I’m not a big believer in strict New Year’s resolutions. However, I see value in setting long-term goals and taking time to reflect on what I’ve accomplished, learned, and where there’s room for improvement.

2024 has been a year to remember — packed with travel, projects, and a lot of contributions to the community.

Highlights of the Year

Conferences

In 2024, I attended 14 conferences across several countries and continents.

What stood out to me was the openness and energy of the Ruby community. Every event felt like a mini-reunion with old friends which lead to a lot of new memories. But it also lead to awesome conversations with new friends, that I’m happy to come back to in 2025.

Each conference offered something unique. From technical deep dives in talks to interesting discussions in the hallway track. I learned how much energy and inspiration I gain from the in-person aspect of these events. For me it’s a feeling that virtual events or working remotely can’t quite replicate — which in turn is why I’m attending so many conferences.

Looking back, I couldn’t have asked for a better year of conferences. 2024 set an incredibly high bar, and while it’ll be tough to match in 2025, I’m excited to see what’s coming in 2025.

Talks

I’ve written two new technical talks in 2024, both focused on Hotwire-related topics. These talks reflected my passion for shaping the developer experience within the Rails and Hotwire ecosystems:

Revisiting the Hotwire Landscape after Turbo 8
This talk reflected on how far Hotwire has come, how StimulusReflex and CableReady might have shaped the state of Hotwire today, where I think the Hotwire-approach is headed, and what I would love to see for the frameworks — both in terms of governance and features, but also in terms of vision.

I think that Hotwire is a gift for the Ruby, Rails, and even the wider web development communities. In a way I still think that Hotwire is what makes Ruby on Rails relevant as a Full-Stack framework today. But I also think that there is so much potential to level up the frameworks even more. I will give my best to help shape the future of Hotwire in 2025.
Leveling Up Developer Tooling For The Modern Rails & Hotwire Era
This was a more technical talk where I explained the story behind building the Stimulus Language Server. I wanted to share the story and timeline behind it, wanted to explain how LSPs work in general, how you can build a simple language server yourself. I also touched on how I think we can improve developer tooling to enhance the overall experience for Rails and Hotwire developers.

Delivering these talks wasn’t just about sharing technical knowledge. A large part was about pushing myself outside my comfort zone to get more comfortable giving talks on stage in front of people after my talk debut in 2023.

Getting to give 13 talks (of which 8 were at conferences) in a single year is a huge privilege I’m super thankful for!

I am grateful for all the incredible opportunities to speak at these amazing events around the world. I’m also super thankful for all the event organizers who trusted me with their stages.

A huge thanks to everyone for sharing your thoughts, feedback, and impressions, in-person and online. I’ve grown significantly as a speaker and learned to embrace sharing ideas on a stage. It’s something I’ve come to enjoy and look forward to continuing improving and leveling up in 2025.

Travel

Traveling was a major highlight of 2024 for me. A lot of the travel was motivated by attending conferences and meetups.

Beyond the events themselves, I enjoy combining my travel plans with these events and stay a few days longer because it allows me to explore new places, work remotely, meet like-minded individuals, attend music events, and make new friends along the way.

My 2024 travling in numbers:

31 flights
15 countries visited
7 new countries explored
117 days traveling away from home

It’s going to be hard to match (or even beat) this in 2025, but that’s not the goal here. I’m already looking forward to travel, explore more countries, and attend conferences while doing so. I hope to you see you at a conference in 2025!

Travel has become my favorite way to combine professional and personal growth, and I’m already looking forward to more exploration in 2025.

Open Source

Open Source has always been central to my work in the last few years, and 2024 was no exception.

Open Source Time Management

I never felt the need to track my time working on Open Source projects. For me, it’s something I enjoy, and tracking it would make it feel more like a chore than a hobby — exactly what I’m trying to avoid.

That changed when I discovered Timing App, which automatically tracks how you spend time on your computer by analyzing the currently active window and open files and storing the data in a SQLite database.

In mid-2023, I decided to give it a try and started tracking all my work. The experience has been surprisingly transparent and reliable.

You can create projects and let the app automatically assign it to a project based on custom rules you define. It’s an awesome tool and I learned to love it.

My main motivation was curiosity: I wanted to see where my time was going and how much I was spending on different activities. Especially Open Source, since I wasn’t tracking it previously.

Without this tool, I wouldn’t have a good idea of how much time I dedicate to Open Source.

2024 was my first full year of tracking 100% of my time, and it has revealed some interesting patterns — including the fact that I probably spend way too much time on Open Source 🙈.

Here a few stats:

2,667 contributions
opened 467 pull requests
opened 153 issues
contributed to repos in 30 different organizations
authored 1,368 commits on GitHub
spent over 1,000 hours on Open Source

It’s interesting to see how my Open Source work naturally comes in waves. A lot of this comes from doing non-Open Source work, but a lot of these gaps also line up with my travels.

It really shows how motivated and excited I get to work on Open Source after returning home from events, which is part of what makes it a perfect balance for me.

My goal was to spend 50% of my work time in 2024 on Open Source, which checks out by looking at these stats!

I certainly had a lot of fun working on Open Source in 2025 and I’m looking forward to keep up my contributions in 2025!

Hotwire Weekly

Starting with 1,097 subscribers, the newsletter grew to 1,888 subscribers by the end of 2024. It’s been a successful year for Hotwire Weekly. I was able to stick to the weekly cadence and published a total of 52 newsletter editions in 2024.

Starting (and running) a newsletter without any prior experience has been one of the most challenging yet rewarding experiences I’ve had.

Curating content, staying consistent, and engaging with subscribers have pushed me to grow and helped me connect with a broader audience in general.

I’m glad I took the leap, even when it felt uncomfortable at times, but that’s a sign of learning and progress — let’s embrace it.

A huge thank you to everyone who’s supported this journey! In 2025, I plan to continue refining and expanding Hotwire Weekly.

RubyVideo.dev

RubyVideo.dev was a major focus for me in the second half of 2024. I’m proud of the progress we made.

It’s been super motivating to work on the website, which is why I have spent a lot of time fine-tuning design/details, creating event assets, building new features and lastly, adding events and talks to the website. Here are some interesting stats:

Added 208 conferences
Added 16 meetup organizations
Added 5,014 talks
Added 2,270 speaker profiles
Designed 13 new pages and feature mockups
Designed 862 assets for 172 events (hero sections, profile banners, avatars, cards, and social previews)

Moreover, we added a bunch of new features that makes RubyVideo.dev as awesome as it is today. Here are some of the exciting features I worked on:

Added an Events Page
Added an Event Detail Page
Introduced Talk Topics
Introduced Talk Languages
Introduced Talk Slides
Introduced Talk Summaries
Richer Speaker Profiles
New Design
Redesigned Home Page (including the new hero sections)
More Social Media Providers
New video providers (MP4 and Vimeo)
Richer Conference Metadata
Conference Artwork (hero sections, profile banners, avatars, cards, and social previews)
Introduced Conference Schedule Page
Introduced Conference Speaker Page
Introduced Contributions Page
Introduced Lightning Talks as first-class citizens
Added Lightning Talk thumbnails
Added Lightning Talk cues
Added Scheduled Talks

But, the website came a long way. Here are some before/after comparisons. Looking at this now makes me realize how far the website came!

RubyVideo.dev is becoming the go-to resource for Ruby events content, and I’m excited to keep growing it in 2025. If you want to help out, there’s a Contributions Page to see where and how you can help. I’m more than happy to help you get started and involved, reach out!

RubyConferences.org

As mentioned above, 2024 has been an incredible year for conferences. Not just for myself, but for the Ruby Community as a whole!

We tracked and added 38 Ruby Conferences on RubyConferences.org in 2024. I also introduced a new meetups section to RubyConferences.org in 2024, in which we tracked over 500 Ruby meetups.

2024 quite literally has been the best year for Ruby events ever. It’s the first time we beat the previous all-time record from 2015 in terms of talks given at Ruby events in 2024!

We’ve been working hard on something in this space that I’m hoping to be able to reveal more about soon. Stay tuned! Exiting times ahead.

All this makes me really proud to be a Rubyist! ❤️

Other Open Source Highlights

Released StimulusReflex 3.5 (after a 3-year journey, involving 30+ contributors and 168 pull requests)
Released Stimulus LSP 1.0, with a lot of new features and improvements.

Extracted and released Stimulus Parser (written from the ground up with a focus on accuracy to reduced false-positives).
Started extracting Stimulus Lint, a CLI tool to run the Stimulus LSP diagnostics independently.
Released an initial version of Turbo LSP.
Started working on my HTML-aware ERB Parser, built with developer tooling in mind. It should help improve the HTML+ERB tooling in LSPs and Ruby applications.
Released the qr_code_scanner and swiss_qr_bill gems.

Happiness & Wellbeing

2024 was a year of personal growth. Balancing professional achievements with time for rest, travel, reflection, and relationships has been key.

I’m proud I found a balance that works for me. Not from work, but from the connections, experiences, and new friends I made along the way.

Looking Ahead to 2025

As I look into 2025, my aim is to build on the progress and growth of the past few years. I want to stay thoughtful, focused, and reflective in my efforts. Here are a few key areas I plan to concentrate on:

Writing & Blogging

In 2025, I want to focus more on writing long-form technical content. While Hotwire Weekly has been a great start, blogging feels like an opportunity and great challenge to dive deeper into topics and communicate ideas more clearly and effectively.

I plan to use my blog to document:

Patterns, techniques, and tools from my day-to-day work.
Insights and lessons learned from my Open Source work.
Reflections on the Ruby and Rails communities, including ideas for improving developer tooling, framework governance, and community-driven efforts.

The goal is to share content in a more structured and thoughtful way, beyond quick social media posts.

I hope that these posts will contribute to the community while improving my ability to explain complex concepts. I want to step out of my comfort zone once again. Blogging is also something I’m not super comfortable with yet, which is why I want to start working on it.

Talks & Public Speaking

2024 was a turning point for me in public speaking, and while I’ve grown more comfortable with it, I know there’s a lot to improve. In 2025, I want to reflect on my previous talks and try to learn from them. It’s something I’ve been avoiding for a long time. But now I want to start tackling that.

I will be submitting proposals to conferences in 2025. I also want to give talks about the non-Hotwire topics I’ve been focusing on.

These events have been an incredible experience and an awesome opportunity for me which inspires me to keep going. They’ve become a significant part of my life and I want to keep that energy going in 2025.

Open Source

Open Source will remain an important piece of my work in 2025. A few priorities include:

Maintaining Core Projects: Continuing to contribute to core libraries like Stimulus, Stimulus Use, StimulusReflex, CableReady, and other libraries in the Hotwire ecosystem. Ensuring they remain robust, relevant, and maintained.
Improving Tooling: Building on the groundwork laid in 2024 with Stimulus LSP, Turbo LSP and the Hotwire Dev Tools browser extension. I want to explore how we can improve the developer experience for Rails and Hotwire developers even more.

This includes finishing and releasing my work-in-progress HTML-Aware ERB Parser, which can level up the developer experience even further in the above mentioned tools and beyond. The idea is to make writing, maintaining, and refactoring HTML+ERB code cleaner, more intuitive and more powerful — while benefiting the broader Ruby ecosystem.
RubyVideo & RubyConferences: These community-driven projects have been incredibly rewarding, and I want to keep refining and growing them. I’m excited to see how they evolve in 2025.

At the same time, I’ll be mindful of my own capacity and the importance of avoiding burnout. Open Source can sometimes feel like a cycle of constant expectations, especially if you do a lot of this Open Source work out of passion and as a “hobby”. I want to ensure I’m pacing myself while staying focused on the projects and ideas I truly care about.

Community Engagement

Being part of the Ruby and Rails communities has been one of the most fulfilling aspects of my career so far, and I’m committed to remaining an active voice in 2025.

I want to help the community thrive and make Ruby as appealing and accessible as possible. Because in the end Ruby is the language we all know and love.

Personal Growth

Lastly, 2025 will be about continuing to grow as a person, not just as a developer.

This past year has shown me that growth often comes from stepping outside my comfort zone. I plan to keep pushing myself in ways that feel meaningful, even if they’re sometimes uncomfortable.

Conclusion

To be blunt, 2024 has honestly been the best year of my life so far. I’ve never felt as happy, motivated, or fulfilled as I do now. I’m looking forward to carrying this momentum into 2025.

I’m particularly looking forward to improving my writing, continuing my work in Open Source, and staying open to new opportunities and collaborations. It’s exciting to think about the ways I can grow, both personally and technically.

GitHub Sponsors

Lastly, I wanted to give a huge thanks to all the people and organizations that supported me as a GitHub Sponsor, thank you so much for supporting my ideas and my vision by being a GitHub Sponsor!

Thank you for reading, I hope you enjoyed this post!

Supercharge your Stimulus controllers with Custom APIs

2023-07-27T03:00:00+00:00

Since its initial release in 2017, Stimulus has undergone minimal breaking changes and has been known for its stability. Even a Stimulus controller written for version 1.0.0 still works flawlessly with the latest 3.2.1 release, using the same syntax.

Considering the fast-paced world of JavaScript, this stability might seem unexpected. While Stimulus has added new features over the years, its primary strength lies in the various APIs introduced with each new release.

Stimulus 1.0.0: Targets API
Stimulus 2.0.0: Values API and the CSS classes API
Stimulus 3.2.0: Outlets API

While also other features were added in these releases, it’s the Stimulus APIs that truly make Stimulus and the releases special.

In this article, we will explore the process of creating a new Stimulus API that can be used in any Stimulus Controller.

The Stimulus Elements API

Most Stimulus controllers should ideally be designed to be used on multiple DOM elements. However, there are also cases where we need to reference elements outside of the controller’s scope or cases where you design a controller which is meant to control a specific element on the page.

The use of the Targets and/or Outlets API also might seem logical for these cases, but the Elements API might better suited if …

… you either can’t control the elements you want to reference and/or can’t define them as targets
… they are outside of the controller scope and you don’t need them to be full-blown outlets
… or the controller specifically needs to control a special element on the page, independent from it’s own controller element and it’s children

A common pattern emerges in such situations: defining a get function on the controller with names like [name]Element or [name]Elements. These functions return a single element or a set of elements using document.querySelector(...) or document.querySelectorAll(...) respectively.

import { Controller } from "@hotwired/stimulus"
import tippy from "tippy.js"

export default class extends Controller {
  connect() {
    this.backdropElement.classList.remove("hidden")
    this.itemElements.forEach(element => ...)
    this.tippyElements.forEach(element => tippy(element))
  }

  // ...

  get backdropElement() { // [tl! highlight:start]
    return document.querySelector("#backdrop")
  }

  get itemElements() {
    return document.querySelectorAll(".item")
  }

  get tippyElements() {
    return document.querySelectorAll("[data-tippy]")
  } // [tl! highlight:end]
}

To avoid repetition and improve code readability, we will build an API that abstracts this pattern into a Stimulus API, similar to the Targets or Outlets API.

Creating the Elements API

Stimulus internally uses so-called Blessings, which enhance the Controller class with new functionality. Each API is a separate Blessing, maintaining a modular design.

The Stimulus Controller class has a static blessings Array which holds all of the Blessings the controller should be blessed with.

In Stimulus 3.2, the blessings array contains:

// @hotwired/stimulus - src/core/controller.ts

export class Controller {
  static blessings = [ // [tl! highlight:start]
    ClassPropertiesBlessing,
    TargetPropertiesBlessing,
    ValuePropertiesBlessing,
    OutletPropertiesBlessing,
  ] // [tl! highlight:end]

  // ...
}

With that knowledge we can create our own ElementPropertiesBlessing and extend Stimulus with our Elements API by adding it to the blessings array.

Proposed API

Inspired by other Stimulus APIs, we’ll declare a static property called elements, defining the elements we want to reference along with their CSS selectors.

import { Controller } from "@hotwired/stimulus"
import tippy from "tippy.js"

export default class extends Controller {
  static elements = { // [tl! focus:start]
    backdrop: "#backdrop",
    item: ".item",
    tippy: "[data-tippy]"
  } // [tl! focus:end]

  connect() {
    this.backdropElement.classList.remove("hidden")
    this.itemElements.forEach(element => ...)
    this.tippyElements.forEach(element => tippy(element))
  }

  // ...
}

By calling [name]Element or [name]Elements, the API will determine whether to use document.querySelector(...) or document.querySelectorAll(...), streamlining the process.

Implementing the `ElementPropertiesBlessing`

Let’s dive into creating the ElementPropertiesBlessing function that will power our Elements API. We’ll create a new file called element_properties.js exporting the ElementPropertiesBlessing constant:

// app/javascript/element_properties.js

export function ElementPropertiesBlessing(constructor) {
  const properties = {}

  return properties
}

The ElementPropertiesBlessing function takes the constructor (controller) as an argument. Inside this function, we initialize an empty properties object to store the properties which should get added to the constructor.

In context of our Elements API we want properties to contain the functions for our [name]Element and [name]Elements getters, which should look something like in the end:

{
  'backdropElement': {
    get() {
      return document.querySelector(...)
    }
  },
  'backdropElements': {
    get() {
      return document.querySelectorAll(...)
    }
  },
  'itemElement':   { get() { /* ... */ } },
  'itemElements':  { get() { /* ... */ } },
  'tippyElement':  { get() { /* ... */ ) },
  'tippyElements': { get() { /* ... */ } }
}

In order to construct that object we want to read the static elements property of the controller.

Stimulus (privately) exposes two functions we can use for this. Depending on the structure of the definition we can either use readInheritableStaticArrayValues() for an Array structure (like the Targets API) or readInheritableStaticObjectPairs() for an Object structure (like the Values API).

Using privately exposed Stimulus functions

The next version of Stimulus makes it easier to access parts of the private API thanks to my pull request.

If you want to make use of that today, you can install the latest dev-build using:

yarn add @hotwired/stimulus@https://github.com/hotwired/dev-builds/archive/@hotwired/stimulus/7b810ec.tar.gz

Otherwise, you need to wait for the upcoming Stimulus 3.3 release.

Since our Elements API uses an object to define the elements and selectors we want to use the readInheritableStaticObjectPairs() function.

import { readInheritableStaticObjectPairs } from "@hotwired/stimulus/dist/core/inheritable_statics" // [tl! focus]

export function ElementPropertiesBlessing(constructor) {
  const properties = {}
  const definitions = readInheritableStaticObjectPairs(constructor, "elements") // [tl! focus]

  return properties
}

The definitions variable now holds an array of definitions, which looks like this:

[
  ["backdrop", "#backdrop"],
  ["item", ".item"],
  ["tippy", "[data-tippy]"]
]

Let’s define a propertiesForElementDefinition() function, which generates the corresponding properties for each element definition.

import { readInheritableStaticObjectPairs } from "@hotwired/stimulus/dist/core/inheritable_statics"
import { namespaceCamelize } from "@hotwired/stimulus/dist/core/string_helpers" // [tl! foucs]

export function ElementPropertiesBlessing(constructor) {
  const properties = {}
  const definitions = readInheritableStaticObjectPairs(constructor, "elements")

  return properties
}

// [tl! focus:start]
function propertiesForElementDefinition(definition) {
  const [name, selector] = definition
  const camelizedName = namespaceCamelize(name)

  return {
    [`${camelizedName}Element`]: {
      get() {
        return document.querySelector(selector)
      }
    },

    [`${camelizedName}Elements`]: {
      get() {
        return document.querySelectorAll(selector)
      }
    }
  }
}
// [tl! focus:end]

In this function, we extract the name and selector from the definition array. Then, using namespaceCamelize(), we create camel-cased versions of the element names.

The propertiesForElementDefinition() function returns an object containing two properties for each element definition: [name]Element and [name]Elements. The former returns a single element using document.querySelector(...), while the latter returns a NodeList using document.querySelectorAll(...).

For each element definition in the definitions array, we want to call the propertiesForElementDefinition() function to create the corresponding properties and merge them into the properties object using Object.assign(). Finally, we return the properties object containing all the element properties for the given controller.

export function ElementPropertiesBlessing(constructor) {
  const properties = {}
  const definitions = readInheritableStaticObjectPairs(constructor, "elements")
  // [tl! focus:start]
  definitions.forEach(definition => {
    Object.assign(properties, propertiesForElementDefinition(definition))
  })
  // [tl! focus:end]
  return properties
}

By implementing the ElementPropertiesBlessing, we have constructed the backbone of our Elements API. This blessing will dynamically add the necessary properties to each controller instance, enabling easy access to the referenced DOM elements defined in the static elements property.

Installing the API

To apply our new API, we need to tell Stimulus about it when starting the application. In Rails apps this is typically done in app/javascript/controllers/application.js.

We want to add our ElementPropertiesBlessing to the blessings array on the Controller class. By importing both Controller and ElementPropertiesBlessing we can push the function into the blessings array and Stimulus will add the properties to each new controller instance.

// app/javascript/controllers/application.js

import { Application } from "@hotwired/stimulus"
import { Controller } from "@hotwired/stimulus" // [tl! focus:start]
import { ElementPropertiesBlessing } from "../element_properties"

Controller.blessings.push(ElementPropertiesBlessing) // [tl! focus:end]

const application = Application.start()

// Configure Stimulus development experience
application.warnings = true
application.debug = false
window.Stimulus = application

export { application }

With this, the Elements API is now available in every Stimulus controller within our application.

More ideas

We could extend the API even more and define a has[Name]Element property which would check if an element exists for a given selector, similar to the Targets and Outlets API.

We could also think about extending the API to accept the selectors for the elements on the controller element using data attributes in the format of data-[identifier]-[element]-element. This would allow to override the selectors for the elements defined in the elements object:

<div
  data-controller="test"
  data-test-backdrop-element=".backdrop"
  data-test-item-element=".item:not([data-disabled])"
  data-test-tippy-element="span.tippy"
></div>

Conclusion

We successfully built a new Stimulus “Elements API,” abstracting the pattern of referencing elements in controllers using CSS selectors. By leveraging Stimulus’ modular architecture and the concept of Blessings, we extended the Controller class with our own API.

The Elements API enhances code readability by encapsulating the element lookup logic and reducing the need for repetitive code in controllers. It improves productivity, making it more elegant and efficient to work with DOM elements in various use cases.

Part of the reason for this post was to demonstrate that not every new API needs to ship with Stimulus itself to be useful in applications. Shipping custom APIs as application-specific code allows us build APIs to our specific needs without polluting the upstream framework with APIs not everyone might benefit from.

With that being said, I could also see a future where we ship ready-made Blessings and the Elements API could become an optional part of Stimulus itself or part of a package like stimulus-use. These APIs wouldn’t be enabled by default, but you could opt-in to enable the APIs you like to use in your application.

Feel free to experiment with my Elements API or potential new APIs you come up with and let me know your thoughts on Twitter or Mastodon.

I would love to see what you come up with.

Happy coding!

Marco Roth

Glamorous Christmas: Bringing Charm to Ruby

What is Charm?

The Charm Ecosystem

Why Port Charm to Ruby?

A Renaissance in Ruby Developer Experience

The Libraries

Example

Demo

Example

Demos

Example

Demos

Example

Demos

Example

Demos

Example

Demos

Example

Demo

Example

Example

Demos

Installation

Source Code

What’s Next

Let’s Build Together

Minitest Bubble Tea Runner

Herb TUI Playground

Thank You

Giving Back to the Rails Community

Introducing ReActionView: A new ActionView-Compatible ERB Engine and initiative for the Rails view layer

What we announced

Herb Linter updates since RailsConf

Herb Formatter updates since RailsConf

Stimulus Lint

Turbo Lint

Stimulus LSP Update

The Rails View Layer

Herb v0.7.0 and Herb::Engine

How Erubi::Engine works

Herb::Engine compared to Erubi::Engine

Use Herb::Engine in Rails

Improved Error Pages/Overlays

Dismissable Validation Overlays

Debug View Annotations in Development

Debug ERB Output Tags in Development

Roadmap: ReActionView Adoption Levels

Level 1 and 2: Try it locally, today!

Level 3 - Action View Optimizations

Level 4 - Reactive ERB Views

Level 5 - Client-side templates

Level 6 - External Components

More Ideas to Explore

One-off Stimulus Controllers

View File Scoped CSS

Selective Rendering

Why this direction

Conclusion

Thanks & links

Introducing the Herb Linter, Formatter, and a Vision for the Future of Rails Views

Herb v0.4.0: Linter, Formatter (Preview), and a Big Step Forward

Herb Linter

CLI

Language Server Integration

More Linter Rules and Feedback

Herb Formatter (Preview)

Format on Save

A Vision For The Rails View Layer

Context

A new ERB Rendering Engine

ReActionView

Level 1: Better Feedback and Developer Experience

Level 2: HTML-aware ERB rendering Engine

Level 3: Action View Optimizations

Level 4: Reactive ERB Templates

Opt-In Syntax and Strict Mode

Level 5: Universal client-side Templates

Level 6: External Components

Herb v0.7.0 and `Herb::Engine`

How `Erubi::Engine` works

`Herb::Engine` compared to `Erubi::Engine`

Use `Herb::Engine` in Rails

Implementing the `ElementPropertiesBlessing`