[00:00:05.00] - Robby
Welcome to On Rails. This is the podcast where we dig into the technical decisions behind building and maintaining production Ruby on Rails apps. And I'm your host, Robby Russell. And I run Planet Argon, and for over 21 years, we've helped teams maintain and evolve their long-lived Rails apps. So I tend to approach these conversations through that lens. In this episode, I'm joined by Marco Roth. Marco is the creator of Herb, a parser and a set of tools that understands HTML and ERB together. He also created ReActionView, which helps build on Herb to make Rails views more reactive. He's a longtime contributor to the Hotwire ecosystem. He was also named the 2025 Rails Luminary, and he maintains RubyEvents.org with several number of people on the team. We're going to dig into how Herb works and how it became part of Rails. It's gonna be part of the default in 8.2. We'll talk about what that means for your existing Rails apps, and we're gonna explore how Marco makes time in his schedule for this type of work. And what he's working on next. Marco joins us from Basel, Switzerland. All right, check for your belongings. All aboard.

[00:01:04.18] - Robby
Marco Roth, welcome to On Rails.

[00:01:07.23] - Marco
Thank you for having me, Robby.

[00:01:09.10] - Robby
So Marco, let's start with this. What keeps you on Rails?

[00:01:14.05] - Marco
Yeah, that's a good question. There's a lot of things that keep me on Rails. A lot of things have to do with the community and the people in the community that have been super helpful over the last few years. I myself started as I was learning programming as well. And there was a lot of people that helped me get started, helped me get good with it. And in a way, it's for me to just give back to these people that helped me get into this. So for me, it's a way to kind of appreciate these people and also try to help get more people on Rails so we can have a more vibrant community.

[00:01:49.23] - Robby
Do you just think of yourself as a Rails developer? first and foremost, or versus like, I'm a web developer, software developer?

[00:01:58.19] - Marco
Yeah, I would say so. I think I would consider myself a full-stack Rails engineer that in the last few years has been more focused on the more foundational developer experience side of things. So I try to get more, or try to get more into the lower level things, more foundational pieces like the frameworks. And now with Herb, also some more of developer experience and with other tools for editor tooling. linters, formatters, that kind of stuff. So I just try to build the experience I want to see myself as a full-stack engineer working on Rails.

[00:02:31.02] - Robby
Sure. You know, I was doing a little bit of digging up and at least browsing your LinkedIn. And I saw that you had had maybe a brief stint, or I think it was maybe more than a year of being a— were you a teacher at one of the coding schools?

[00:02:45.17] - Marco
Yeah, I was. Exactly. I was working at Le Wagon for— working as a coach there for a few courses, mainly because they were big on Rails. Maybe they still are today, I'm not quite sure, but they were big on Rails. They helped a lot of people get into Rails. And one of the last curriculums, they also added the whole Hotwire stack and Stimulus to it. And they had a branch here in Switzerland, in Zurich, and I knew some of the people working there. And they asked me if I wanted to come on to teach some of these classes that were concerned with the JavaScript side of things. I was lucky and happy to teach some people the Hotwire stack to new engineers.

[00:03:26.14] - Robby
Did you have much of a background in coaching or teaching prior to that?

[00:03:31.15] - Marco
I mean, not formally. I was in school myself, so I kind of saw some of the things there. I was helping out with some of the classes to help people get up to speed and help them with exercises. And I have been that person in my kind of class for my classmates sometimes too. So I kind of got that angle. And that feels, I feel like a bit more personal than it is from this teacher perspective, kind of talking down to people. It's more that you sit together and have this pair programming experience, which I think is more helpful. And also how I got taught to program and to learn Rails.

[00:04:05.23] - Robby
I've done a lot of pair programming with employees and interns over the years at my company. But now I think back to like my first job as a software developer, I was sitting there next to a senior developer and they were like walking me through things like, well, here's how we make changes. Here's how this stuff works. Here's how we call SQL. This was way before I was using Ruby or Ruby on Rails. But I always think, you know, like that's how I learned too, was like working with other people and like looking at reading stuff online. And I'm kind of curious about your role and we'll talk about, there's a bunch of topics I want to get into with you today, but I think there's an interesting connection there to like, Do you feel like because you've had that experience of learning to program that way and then being able to help coach and mentor other people in a similar way, that gravitates to you, like seeing how other people will use and interact with things that you want to make things easier for them? That tends to be a trend that shows up in some of the projects they're working on.

[00:04:59.14] - Robby
As you think a lot about developer experience, because you're watching other people interact with it versus like, if it was just you having to like brute force figure out how to make things work, that kind of shines a light on like, oh, I want to make things better for other people, because you see it in other people.

[00:05:15.08] - Marco
It's a super great observation. It's also some of the experiences that I saw working in these kinds of setups and situations that I was like, this is frustrating. This is actually not great. This is something we could improve and kind of make it easier for these people to get started. And if you create a new Rails app today, and you have to think about what bundler do I use, what kind of JavaScript framework and stack should I use, In Rails, there are even like 10 different options to use today. And none of them are the solution for everything. You have to kind of know already what you want to build. There are good defaults, which Rails is known for. But sometimes this is even not great with the whole npm side of things. If you want to install a package, if you want to install anything, right? It's not always the best experience. And that's— I think part of the motivation too, to help steer the direction of these projects to make it easier for people to just get started and get going. And that's what Rails kind of is great for, right? So you can just go and build your thing and focus on the business aspect and don't have to worry about the technology side of things.

[00:06:22.16] - Robby
Out of curiosity, approximately how many years have you been working with Rails?

[00:06:26.13] - Marco
I started working in Rails in 2013. Okay.

[00:06:30.17] - Robby
So good.

[00:06:31.01] - Marco
This is like Rails 4-ish era?

[00:06:33.19] - Robby
Okay.

[00:06:34.04] - Marco
Yeah. And I used Ruby before that a little bit for my— there was like an exercise when I was applying for my apprenticeship. And they used Shoes, or Hackety Hack back then. Oh, yeah, yeah, yeah.

[00:06:46.22] - Robby
Back then.

[00:06:47.05] - Marco
And then there were some exercises to kind of draw things on the screen and kind of try to have little exercises and little snippets of Ruby that you had to write to get these things drawn. And that was my first introduction into Ruby in like 2012.

[00:06:59.13] - Robby
Oh, well, that's awesome. I'll include a link to Shoes, see if we can look some of that stuff up for our listeners and folks watching the show. Rails 4, do you remember what the state of the frontend, like the latest technology was around back then? Do you recall?

[00:07:14.21] - Marco
Yeah, it was, I think it was mostly CoffeeScript was the default for most of the files. And it was right before Webpacker. Sprockets was still kind of the default for most of the assets. And there was also this one service, I don't know exactly what it was called, it was like assets.railsplugins.com or something. I don't know exactly anymore. But you could put something in your Gemfile. And you could kind of declare all the npm packages you want to have. And there was a service that was kind of shipping all these npm resources as gems so you can include them in your asset pipeline. Oh, I remember. And that kind of was my first kind of frustration back then. And At least for me, Webpacker made it so much more easier. We could just use npm or Yarn to install all the packages, and then it would just be available. But there were other problems with Webpacker that I guess we shouldn't be talking about too much today. But this whole kind of transition period was kind of interesting. Yeah.

[00:08:16.05] - Robby
Yeah, some loose memories having been around the community for such a long time. There's all these different weird errors and— I feel like you need to have like a forensic lens on that, or I'm sure there's probably some really good timelines that people put together, but my company will typically help companies that have older Rails apps. They'll come in. And so then we have to kind of like still make those systems work where they're at, because you can't just like immediately just upgrade them and use the latest greatest. You have to kind of work with the tooling that was at the time. And the thing I always try to tell people when they're, they're having to weigh up like, well, we, we, we, we need to migrate to whatever the newest thing is because that's what everybody else says is new. As if the existing stuff sucked or something in a way. And like, no, that's not necessarily the case. There's problems with it. There's like weird trade-offs, but it was at the time the greatest tools that we had available. And, uh, you can make that stuff still work for a while and then incrementally, uh, work your way towards upgrading to or migrating to something else.

[00:09:09.22] - Robby
But, but anyways, we don't need to go down that path, but I have fond memories of those eras. Not just like, I try to look at the positives because whatever we're doing now will probably look antiquated in another 5 years as well. Yeah.

[00:09:21.11] - Marco
Yeah, the thing was, they are mostly disruptive kind of changes. And I think that's kind of what the problem was back then, because you had to rewrite the whole thing from scratch pretty much and kind of rethink how the whole thing worked. And I think with recent version of Rails just got a lot better. It's more incremental, more kind of subtle changes that help you just get up to the latest version more easily. And that's been kind of my theme trying to get back to these problems to just be more mindful of these backwards compatibilities. So you don't have these frustrating big moments of migration. Yeah. And having to switch systems. Yeah.

[00:09:57.13] - Robby
Well, I appreciate that you've done a lot of work in that area for our developer community. So even before Herb, you were working with like doing work with Stimulus and Hotwire. So maybe you could tell— talk a little bit about what that transition looked like to like how you came about the idea of working on Herb in particular. What sort of limitations were you encountering back then?

[00:10:16.23] - Marco
So initially, this whole kind of journey started with me working on an application for my company that I was working for. It was me independent working for a, actually gardening company trying to build this appointment system for them, kind of schedule software that had to integrate with all the Swiss kind of local registries and tax and stuff. So we tried to make this kind of work for them. And I was looking for a library to build more interactive UIs, more interactive pages that you don't have to refresh the whole page every time. And that's where I found StimulusReflex back then, which was itself inspired by the Phoenix LiveView framework. But the idea was that you can build these rich interactive UIs pretty much with the Rails tooling you already kind of knew and loved. which meant that you were using Turbolinks, you were using Stimulus, you were using all these existing tools that you might have already used for your modern UIs in Rails. But they kind of took this a step further and made it so interactive, so you can click on something and it would reach back to the server, the server would render something and it would respond back and it would redraw the UI the way you expect it to.

[00:11:27.04] - Marco
Discovering that, I, and working on this in my application, I noticed some things that were not great. weren't working. So I started to contribute to StimulusReflex and its underlying library called CableReady.

[00:11:37.22] - Robby
Hmm.

[00:11:38.15] - Marco
And that's kind of where I got into this whole open source community, kind of being dragged into that. And I was so happy to help out with it because I had so many ideas of how we can improve things and how we can push things forward. And then a few years into it, I got asked if I wanted to help maintain Stimulus. And I have been doing so much with Stimulus. Thanks to the work on StimulusReflex, which was built on it, if you want to help maintain Stimulus. And that's how I got into this more underlying Stimulus, Hotwire, Turbo kind of territory. And we wanted to evolve StimulusReflex into this bigger thing that is kind of the default, how you could make things work in Rails. But at the same time, Hotwire came out. So this package or this rebranding of Turbolinks into Turbo, which included newly these frames and these streams that came out. We kind of thought somehow it's conflicting, like it's not exactly covering the same kind of aspects of it, but— Interesting. The idea is that we want to build more interactive UIs. So we thought if we can kind of rethink our StimulusReflex libraries, if we can build them on the modern new Turbo stuff, but this kind of stuff all fell apart.

[00:12:53.10] - Marco
because we couldn't really collaborate or find a way to make this seamless somehow. And that's where I pivoted into more making the developer experience things of things work better. So I was frustrated with Stimulus, that it wouldn't tell you when something is wrong about it. It wouldn't warn you, it wouldn't tell you any errors, it wouldn't show you that something is wrong about it, it would just not react at all. So I was kind of set out this mission to help build developer tooling for it. So you had autocompletes, you had warnings in your editor, or even in the actual browser. So you can see, I clicked something, but it didn't do anything, but it would show you why it didn't work. And that kind of led me to build more developer tools. And then quickly, I realized, well, we're dealing with HTML here. But if you have all our ERB views, it wouldn't work for those. So I had to find a way to make this all work for ERB files, or when you're using Ruby in ERB files, that it would also understand how these things worked. And it was only kind of halfway because it only worked on the HTML side of things, but not on the Ruby side of things.

[00:13:57.22] - Marco
And then for years, I didn't really thought I was capable of achieving this or building out this library that I would need to make this work. And then a few years later, Kevin Newton was working on Prism and released that to the public.

[00:14:10.22] - Robby
Mm.

[00:14:11.15] - Marco
Then I realized, okay, hold on. Now that you have all these new foundational pieces like this new Ruby parser, that is now shipping with Ruby itself in Ruby 3.4, I think. I have this foundation now to actually build out this project that I always wanted to have, what came to be Herb, that helps with parsing these files, but then also providing more useful tooling around your files. And that's kind of where this whole path came to be of now working on all these developer toolings and Herb.

[00:14:43.19] - Robby
Out of curiosity, how, how long ago did you start contributing to the, was it Stimulus? Was it—

[00:14:51.08] - Marco
StimulusReflex.

[00:14:52.03] - Robby
Reflex. How many years ago was that?

[00:14:53.20] - Marco
This was 2019.

[00:14:55.12] - Robby
Okay. So 7 years or give or take or so. Yeah. Um, all right. I was always just trying to get a sense of how long you've been kind of contributing with open source to, to this point, just for some context for listeners. And, uh, my first introduction to Herb, I think I saw, maybe it was at SF Ruby last year, you did a talk. And you were kind of showing some stuff.

[00:15:14.04] - Marco
Yeah, last year, SF Ruby.

[00:15:15.09] - Robby
Yeah. So that was like 2025. And I think that the next SF Ruby is coming up maybe in a week or two. Will you be there again this year?

[00:15:23.07] - Marco
I will be at SF Ruby again in November.

[00:15:26.15] - Robby
Unfortunately, I will not be there, which is a bummer. But so let's say like, I know Herb is going to be kind of a default thing in Rails 8.2, correct? That's right. I don't know if we have a release date on that yet. And I don't know if you know by chance, but I haven't heard anything.

[00:15:41.04] - Marco
I don't know any official datings, but it's probably not this year, I guess. Okay.

[00:15:45.20] - Robby
But in the meantime, this is something that people can install and use on older versions of Ruby on Rails. Or is there a minimum version of Rails that someone would need to be able to have to use this that you're aware of?

[00:15:58.03] - Marco
No, there isn't really. The good thing about this, and this is also kind of part of the architecture around some of the Herb things, is that it's not written in Ruby itself, which is also needed for most of the developer tooling side of things. Most of the stuff is written in TypeScript.

[00:16:13.19] - Robby
Okay.

[00:16:14.14] - Marco
The parser itself is written in C for kind of maximum compatibility and portability. It's following pretty much all design principles that Prism kind of set out. It's also written in C. So whenever you write something in C, you can bring it pretty much anywhere, which means you can use it from Ruby, we can use it from JavaScript, we can use it in the browser via WebAssembly. We can use it pretty much everywhere. And that was the idea then also to bring the whole language server and stuff and write this in JavaScript or TypeScript. So you don't need to install it as part of your Ruby package. So you can install the language tooling independent from your application's Gemfiles. And if your editor has it built in, you can just install it and it doesn't kind of conflict with any of your— Right. local Ruby gems and versions. You can even use it in projects that don't even use Ruby technically, if you have ERB files or HTML files in there. So that's kind of the idea there. So this shouldn't mean that you have any minimum version that you— or Rails version, Ruby version for you to use.

[00:17:19.12] - Marco
But if you want to use this, then more advanced, I guess, ReActionView things on top of it, there is a minimum version. I think it's 7, Rails 7 something. Okay.

[00:17:28.17] - Robby
We'll talk about ReActionView in a little bit, but I'm, you know, I'm just thinking it's like a really basic thing. If you have an existing Rails app or Ruby app in particular, I guess you could use other frameworks within the Ruby ecosystem that use ERB. Are you aware of, are there other programming languages, frameworks that use ERB type templating?

[00:17:48.06] - Marco
Yeah. I mean, Bridgetown uses them too. By default, I think now even Hanami uses them. You can use them in Sinatra. We have presets for these frameworks too. But right now, they just don't offer the Rails features. They don't have anything special to them built in. It's just a compatibility layer that you don't get Rails suggestions in your Hanami apps and stuff. Yeah.

[00:18:11.02] - Robby
So just the kind of the specific part of the ERB library itself. And okay, and then it's got some extra Rails-related things that you can do. Just kind of walk me through this. And for context for listeners, I'm more of like traditionally say backend developers. So I tend to focus more on like the data architecture side of things. And I don't often get to do a lot of stuff on the frontend too much outside of making a few changes. So I could see this being valuable in the sense of like, okay, I add it and then I'm opening up, let's say I'm in VS Code or one of my editors and it's noticing and highlighting when things are syntactically wrong, there's maybe error messages that are able to show up and things like that. And reformatting things looks like it can help you with that as well. What other sorts of things would you get just on the ERB level? And is this also a good argument for anyone that's kind of like a holdout for— what's your take on HAML, Marco?

[00:19:04.19] - Marco
I mean, personally, I don't like it just because of the syntax things. It's, it's for me, and I've kind of worked in web applications, I think in terms of HTML, I see tags in my head when I kind of think about HTML. And whenever I see something that's not HTML ERB, I have to double translate. What am I reading here? And what do I want to update or write here? So I always struggle with it. Or I guess I struggle with the difference between what's dynamic and what's static in a HAML template. I don't really know, is this markup? Is this Ruby? Is this an attribute? What is this kind of corresponding to? But that's just opinion. I mean, you get used to—

[00:19:42.17] - Robby
It's the right one, Marco. It's the right opinion. We can say that. I'm okay. It's a safe space. Um, uh, I'm, I'm, I'm a friend with the person that created HAML and I'm, uh, but it's always been one of those things. I'm like, I just, I don't get it. I feel like it was like a thing that developers were trying to not have to write HTML. And I'm like, well, this is the thing that HTML is really easy for. I feel like HTML is a really inviting way for people to come in and get to work on Rails apps. They understand the HTML, but then you're like, you gotta learn this weird thing that generates HTML. And it kind of just felt like kind of awkward to me, but my perspective.

[00:20:13.10] - Marco
It feels more native to the platform and native to the web to me. That's kind of what HTML would be, why I kind of prefer it that way. But I can totally see anybody else using Auto, even Slim as well.

[00:20:23.19] - Robby
Yeah, yeah. Also, we didn't have tools like Herb back then, whereas one of the arguments for things like HAML was that it would generate and kind of force you to have HTML syntax appropriate. You know, it would generate the right thing for you and kind of blow up if you didn't do it right. But it felt very finicky.

[00:20:40.08] - Marco
Yeah, I think that's kind of the issue why, like, for a long time, it felt like ERB is not a great choice, because there wasn't— there was barely any tooling for it. And it wasn't really fun to work in editors. If you come from a modern JavaScript stack, and you come back to an ERB project, and you're like, where's my autocomplete? Where's my tooling? I cannot work with— or I struggle to see what's happening if I don't have my tooling. And that's how I felt a little bit too, when I was working a little bit in React. Yeah. came back to Ruby, I was like, yeah, there's something definitely missing. And I think that part is also something that I've been trying to focus on is look what other frameworks do well, and try to get inspired by them and see what they are doing good. And bring these ideas back to Ruby and back to Rails and kind of have these modern takes of things, how they work. You see this today with even programming languages. If you have any of the newer ones, let's say Go or Zig or even Rust, they all come with a linter, a formatter, pretty much built in and preconfigured.

[00:21:41.08] - Marco
And you don't even have to think about it. It's just like part of the whole toolchain. And that kind of aspect is what's surprising to me is that we don't really have this in Rails as much. Maybe there is like a community default-ish that people tend to use. But it's something you have to discover and notice the need for and then have to include it. That's been the design idea behind kind of Herb as well, that you get this whole package, the whole like runtime, but also the whole toolchain side of things. Have this all kind of be there by default and you can use as much as you want from it, or you can disable the things you don't really care about. And then it just works seamlessly from front to back, pretty much. That's the idea there.

[00:22:21.21] - Robby
Help explain this to me. Like what happens between, let's say that your template file And the response, like, how does that, what's happening there? What's the magic?

[00:22:32.20] - Marco
Talking about the response in like a web server, um, context.

[00:22:35.15] - Robby
Yeah. So like, if you, so I got my ERB template and it renders HTML. What's happening in this process? Is it just that it's like, is it running like a, you're running, it's like a RoboCop type thing where it's like, it's going to go through and like, is it happening all the time or is it just getting run?

[00:22:53.08] - Marco
Mm-hmm.

[00:22:53.18] - Robby
On save, and then it checks things like, what's that response look like? And then let's talk a little bit about ReactiveView as well, or ReActionView.

[00:23:00.18] - Marco
I think the whole kind of thing that you have to understand is that you can adopt Herb in stages. You don't have to run the whole thing. And in the most basic way, what you can do is you can just run the analyze check on your codebase and see if the parser can understand all the things you have in your applications. There's no linting, no formatting, no compilation, no rendering at all. It's just trying to make sure it can understand what your templates include. So this is more like a syntax level check that it does to see if it can understand your application.

[00:23:34.08] - Robby
I see.

[00:23:35.02] - Marco
If you want to go a step further, you can say, I want to enable the linter, which might surface some common— you can think of it as like a RuboCop, right?

[00:23:43.14] - Robby
Yeah.

[00:23:43.21] - Marco
So it kind of catches some of the common issues or problems or stuff that's not compatible. It tries to make sure that it you have the right helpers, the right compatibility stuff. So it's really a wide range of lint rules, like over 150 at this point, to make sure that you have more idiomatic templates as Rails kind of intends them to have them. Interesting. So this is all still something you can run in CI or in your editor that helps you just write, I guess, better quality templates, even also secure. So there's also some security aspects to it that you don't interpolate things that aren't secure or could lead to some vulnerabilities or cross-site scripting attacks or that kind of stuff. So it helps with these aspects from a static analysis point of view. And then you can go a step further and say, I want to have the Herb engine. So this is the replacement for Erubi engine. This is what Rails used before, to have Herb parse and then compile your templates. So Ruby can render your HTML at runtime. Herb checks your templates, it parses them, and then there is a compiler built in, builds this out to a Ruby string.

[00:24:52.12] - Marco
So you can think of this as kind of when you have source code and in other languages you have to compile the code to have, to be able to run them. So it generates the binaries or the machine code out of it. And this is a similar step, but just that the compilation output is a Ruby script that you can run in your, in your Ruby application. So. Yeah. ActionView has like a hook that says, please compile this template for me, and gives the path to the templates. And then the Herb engine can take it and compile it, and it has to return a Ruby string. And ActionView internally then defines a method, which is used to render whenever you want to render this template.

[00:25:28.12] - Robby
I see.

[00:25:29.13] - Marco
So it's pretty much an HTML ERB to Ruby compiler. Ruby can, or ActionView then can run your code and then also render out a template as you need it for returning it in your web server as a response for an HTML request.

[00:25:46.05] - Robby
Let's take an example like a template file or your ERB file. And it's, let's say you have an instance variable there. And if your instance variable, is it checking that you've defined that instance variable in your controller somewhere at that level? Or is that just like falling back on normal Rails errors at that point? Or is it catching that stuff? ahead of time before— does it know about things like that?

[00:26:09.05] - Marco
Yeah. So right now, it doesn't really do any of these checks in the engine itself, in the compiler. But it's something I think I want to look into how we can push more things into that level so that it can complain or even kind of refuse to compile something if it's not defined or not safe or not ready or whatever you have. But we have linter rules that kind of try to help you steer Like the way, the right way, you have to have good templates, that you shouldn't be using instance variables and partials, that you should be passing them explicitly, use strict locals, kind of that kind of stuff. So you have, right now, the linter kind of steering you in this direction that we can have more safe templates, have templates that are easy to follow through and kind of have a compiler understand everything that's happening. But this is not necessarily backwards compatible to the fullest, right? Because you might have to be more strict about things. If you don't know what something is, you have to raise. And that's not backwards compatible in that sense. So—

[00:27:09.02] - Robby
I see.

[00:27:10.00] - Marco
In my mind, I want to kind of steer people in this way with the linter first. And then if this is kind of an adopted practice, and people have been using the Herb Linter and have been following these rules, then you can kind of enable some checks more to tell the compiler, please refuse all these things we don't know about, that they have to be more strict. So more like a strict mode for your views.

[00:27:34.00] - Robby
Right, right. You know, so we still end up with Ruby method that renders the page, it sounds like, right? How is this different than like what Erubi, was it, however you pronounce it, Erubi? Erubi, yeah. Yep.

[00:27:46.17] - Marco
So the difference is that's Erubi itself is a regex. So what it does is it tries to parse out all the Ruby pieces that you have. And it doesn't really look at the HTML, the content at all, right? So it just sees this is an Erubi opening tag and a closing tag. And it knows how to interpolate and switch back and forth between them. But it doesn't care about what you are rendering, which is also why it doesn't give you any errors when you have closing— missing closing tags, or if you have—

[00:28:16.04] - Robby
Right.

[00:28:16.22] - Marco
Ruby syntax errors or any of that kind of stuff. But the good thing is, it's super fast because of it, because it doesn't have to do any checks. It's just like, pretty much translating it in one go. And that's why you also don't have any of these failure modes. But also, it works for any kind of thing you want to interpolate. You could use it for emails, you could use it for SQL, you could use it for YAML. It doesn't really matter in the end, because it's just strings that it's kind of Concatenating. So Herb is trying to be more specialized in that sense that it's mostly focused on HTML ERB. And that's why it tries to understand that all your HTML is also sound and cannot produce invalid HTML in the end.

[00:28:59.17] - Robby
I see. As a result, does this take a little longer to compile than those templates? Yeah.

[00:29:06.09] - Marco
So as of the last version, it's up to like 20 times slower to kind of compile a template. The good thing is that you only have to do the compilation once, because you have to compile it once. And then at runtime, it's equal or sometimes even faster, because we can do some optimizations, because we know what it's doing inside the template. But we are trying to work right now in Rails itself to make it so you can precompile all your views. So the compilation step happens—

[00:29:37.13] - Robby
Interesting.

[00:29:37.20] - Marco
Like either at deploy time, Or at boot time of your application, so that you don't have to do it on the fly when you try to render this template for the first time. That's kind of how it works today. Rails tells us, or ActionView tells us, you want to render this template, and it has to compile it the first time it wants to render this template. And if you have now this 20 times slower, it could kind of in production cause some slowdowns technically for the first time or for the cold requests. So that's why we tried to move this more back in the stack or back in the deployment kind of pipeline. Because you can do this all upfront. It doesn't have to be at runtime. You can do this statically upfront.

[00:30:18.17] - Robby
Does this change the rendering time at all? Is there anything like, how does that get impacted from once it's compiled? Is it just—

[00:30:27.14] - Marco
Yeah, once it's compiled, it's the same runtime speed, or in some cases even faster because you can optimize some of the calls. Or what we can do now as well is we can sometimes even compile away some of the helpers, some of the ActionView helpers.

[00:30:44.14] - Robby
Hmm.

[00:30:45.00] - Marco
So if you use link_to or image_tag or any of these kind of helpers, we can pretty much compile away that method call from Ruby to be static HTML and do it like a static evaluation of that helper. So you can technically start to see more speedups. Yeah.

[00:31:02.20] - Robby
That's interesting. Yeah. Cause there's definitely times we've, uh, seen projects that we've needed to kind of work around some of the Rails helpers just to try to find some ways to speed up some rendering and things like that. But yeah, that, that's interesting. I'm curious about like, you got this template, you're precompiling it. Are there other things that Herb can check without running the template? And I'm also kind of curious, like, can you think of an example of where Something that would compile with ERB, but fails with Herb?

[00:31:31.10] - Marco
Yeah. So for the second question, what compiles with ERB and doesn't compile with Herb, it's if you have invalid Ruby syntax. So if you think about, if you have an if opening tag that you put in a separate ERB tag, so you have open ERB tag, an if condition, then you have something in the body of that if, and at the end, you are supposed to close it with an opening tag end. Close tag. And if you don't add this end tag, it's going to be invalid Ruby at runtime, right? So if you don't add the end, it's not going to compile. And ERB doesn't care. It doesn't really look at the Ruby you're writing inside your ERB tags. And that's something that Herb can catch now, is that it can look at your Ruby inside the ERB tags and then tell you, you are missing an end here at this position. And technically it could insert it for you if, like, if it knows this is missing. But this would almost be a bit too far. So I think this is more than a development tool that it can tell you, I see you're missing an end tag, do you want to autocomplete or fix it to insert it?

[00:32:33.02] - Marco
This shouldn't be something the compiler automatically fixes up for you at compile time. But that's the thing that we can do now, because we have a full understanding of your ERB view, that we can give you some more diagnostics on what was wrong about your templates.

[00:32:49.11] - Robby
Such as?

[00:32:51.17] - Marco
Missing closing tags, missing ends, missing if, invalid Ruby syntax altogether. Yeah, that kind of stuff. Whatever Prism is kind of returning as a syntax error, Herb will surface too, because it's built on Prism.

[00:33:05.23] - Robby
For those listening, I think the distinction there, it's, you can get that information, that feedback, potentially, like almost immediately, right? Is that kind of what you're conveying? Rather than like, Going to your browser, reloading the page, or letting your test suite find like, oh, you forgot a missing. So that's the, the speed benefit you get there as a developer that it's like, hey, you have, you've just opened up an if conditional. You haven't closed that yet. This is a problem. Does that mean it's also showing an error immediately before you've written the end tag as well?

[00:33:40.05] - Marco
Or it does like as you're writing it, it will show you that something is incomplete. that it's missing an end. And I think that's usually what you want. If you are in the middle of writing a template, you want to have feedback if I'm ready, if the compiler accepts this, or if it's invalid. And the good thing, again, of having this in C is I can use the same parser and the same engine across all my tools, right? So whatever's running in your editor is the same that's running in your linter, which is the same that's running in your— Compiler. compiler, which is the same that's running in production in the end. So you pretty much have this shared knowledge and understanding across the whole stack. Before that, in the worst case, you would figure out that something is wrong about your Ruby code in production when it crashes the first time, because there was nothing holding you up shipping a broken view before.

[00:34:29.09] - Robby
Right. This is an important message from the Rails Developer Fire Prevention Council. Every year, thousands of applications are put at risk by excessive lint buildup. When was the last time you cleaned your linters? Unchecked warnings, unused variables, and years of ignored RuboCop offenses— all highly flammable. And remember, just because your CI is green doesn't mean your app is safe. Experts recommend inspecting your linters at least twice a year. And never, under any circumstances, disable your smoke detector. With RuboCop, disable all. That's how tragedies happen. This message was brought to you by the Rails Developer Fire Prevention Council. Keep your linters clean and your production environment smoke-free. The council is not a real organization. No applications were harmed in the making of this announcement.

[00:35:18.07] - Robby
If your production server is actually on fire, please contact your local fire department.

[00:35:22.18] - Robby
You know, you mentioned earlier, you were talking about a scenario where you were working on a project that was like a gardening app for a client. It sounded like, it sounds like you do a lot of consulting work. Uh, it's not obvious to me as somebody else in the Ruby on Rails ecosystem, like how does Marco make money as a career? Is like, is he making most of, are you able to get by off of open source contributions, sponsorships? Are you primarily working in a consulting capacity? What's, what's the day-to-day life of workday life like for Marco?

[00:35:54.07] - Marco
I initially started working as a consultant so I could support or enable this kind of, I guess, lifestyle that I have right now that I can contribute to open source as much as I'm doing, because I'm flexible enough with scheduling the work I want to do whenever I can, right? And most of the times I have been lucky to have been working with clients that are working in the same space. So they wanted to have help with JavaScript or Hotwire in their Rails applications and build some more advanced UIs that they couldn't really be doing themselves, or they didn't even know how to start and where to look for these tools. And that's how I've been able to make this work somewhat. But as of more recent years, I have been doing a lot more conference talks and a lot more of the actual preparation for these talks to be able to ship all these features.

[00:36:47.09] - Robby
Yeah.

[00:36:48.05] - Marco
And I always jokingly said, this is TDD, it's talk-driven development. So I kind of have these talks I want to deliver. And that's where I have my deadline for them. And with those, it got more and more difficult to schedule the client work and have them be flexible enough for them to adjust to my schedule with talks and travel and that kind of thing. So as of recent, it's not been, I guess, the best for consulting work. But I was able to focus more in that downtime, and I didn't have any work for clients that I could put back into open source and make things better there. I do have a GitHub Sponsors program that I got a lot of support for. But I guess even with that, it's still not enough to have an actual full-time salary for any of that work. So I still have some consulting work. But it's also something I need to figure out going forward, how I can sustain this kind of work with my regular day schedule for work-work. And that's still something I'm trying to figure out. Yeah, I spend a lot of time in open source, and I really enjoy that kind of work.

[00:37:52.18] - Marco
But it's something I need to look into how I can maybe even involve companies or involve other parts of the ecosystem that wants to have this kind of work being done. And that I either can work with them or have them help out with some of the tools that I've been working on. that they kind of take over some of the ownership and some of the maintenance and that kind of stuff. So I just don't know exactly how this looks like.

[00:38:16.10] - Robby
No, I appreciate you sharing a little bit of that. I think it's always one of those things that's like, attending conferences is a big thing in and of itself. But to be— I don't think there's probably too many people in the Ruby ecosystem that are— that I see traveling as much as you to go speak at conferences. And so knowing that how much work it goes just to put the talk together, Let alone you, as you're saying, doing talk-driven development. Like, I want to be able to present this at the next conference. And like, and that kind of like probably gets some energy to like, I'm going to put this thing together. This is my ideal approach of like the new features or the release we're going to be doing. And that kind of helps probably drive up some motivation to work on these projects. So on behalf of the community, thank you for that. It takes a lot of energy, time, and money and, and time away from doing other billable client work as a consultant, because I work in the consulting space as well, or run a software consultancy. And so I'm always thinking, trying to balance that, like, like what's the trade-off of this?

[00:39:15.10] - Robby
And so I'll definitely include links to your sponsor stuff in the show notes for people as well. But it's an interesting time, I think too, for being a consultant in 2026 in AI. I'm assuming that's not—

[00:39:27.05] - Marco
Yeah, I think also AI kind of took some of the work I've been doing the last few years that clients just can do themselves now because they have all these LLMs available to them. But I guess there's still some value in these kind of foundational tools to exist that agents can drive and thrive in these environments and have a way to verify their work or have a tool tell them to improve something or don't write it in a certain way. And I think that's where these foundational tools and linters and formatters and that kind of stuff are really kind of important in today's day and age. And That's why I think this is still kind of important work regardless. But it's something we have to figure out, I guess, as a whole industry, I guess, how we're gonna work with these tools and agents.

[00:40:13.23] - Robby
Well, we might have to circle back around with another conversation in a year to see where these things start to kind of like steer for. I do not know how to tell what 2 or 3 months looks like in the future anymore. It's been a weird year. Exciting, scary, all of the emotions at the same time.

[00:40:30.16] - Marco
All of it.

[00:40:31.03] - Robby
Yeah. I think, yeah, that's, that's an understatement. Let's talk a little bit more about ReActionView. Well, how does that work? Because like, I came up with a couple of like template examples, like ERB examples where I'm like, all right, so let's say I have a backend live dashboard type thing and I can see the number of customer requests that are coming in, um, or sales, maybe orders or something like that. And I render the view, it shows some data. Historically, there's been a lot of different ways to like have it fetch or something push. You use ActionCable. There's lots of different things over the years.

[00:41:11.12] - Marco
Yeah.

[00:41:12.07] - Robby
Do a POST or a GET request to refetch and refresh the data every once in a while on a timer or whatever. So if I have like a count of data, what would you do to have that data get refreshed automatically, I guess, in that sense.

[00:41:26.20] - Marco
Yeah. So the thing is, now that we have Herb available, we have all this tooling, we have all this introspection, we have all the information of what this view is doing in that file. We can employ some more advanced, I guess, tooling techniques on top of it to say, okay, we see you are rendering this part here and you're doing this conditional over here and here doing a loop in the conditional and You iterate over these things and do render out these pieces of that part of the page. And we can do analysis on top of that to figure out what is happening in that view. So what we can do now is we can prepare, or the compiler can prepare, from the same view, different versions of that same view. So you can render it once traditionally, like you have been doing this whole time. And then a second version that's meant for subsequent updates to that page. And you can think of this as like a JSON API that's being generated out of your templates, what you are rendering out. So what you're outputting in the erb_output tag is pretty much Ruby in the end, right?

[00:42:34.17] - Marco
Mm-hmm. So you can think of it that the compiler takes out all of these values, plucks out all of these values, and then says, okay, index number 1, this is the slot format. So you have slot number 1 is this part of the page, slot number 2 is this part of the page, and so on and so forth. And we can also detect, then again, you have conditionals here, and inside this conditional, you're outputting that part of the page. So what we can then generate is a schema that says these slots' numbers map to this and this part of the page. And for any subsequent updates, we can then say, for slot number 5, here's this new value. Okay. And then the client knows, okay, I get a new slot value for number 5. And then it knows exactly where to put it and update it on the— in the DOM, in the browser. And that's kind of the whole magic behind it, is that it can understand what's going on. Give it a slot map so you can address each individual output tag in your view, and then have the server respond with the new slot values so the client can update them accordingly.

[00:43:39.07] - Robby
How are slots then defined? You have to like put those in code somewhere, or is this happening a little magically?

[00:43:46.13] - Marco
That's kind of the whole point. You don't have to change anything about your ERB views. By just you telling or writing an ERB template to say, I want to output something here, that is kind of implicitly a slot definition. So you say, I want to output this value here, user.name or posts.title. By title. And it doesn't really matter to the engine what you are doing there. It just knows at this position, we are outputting some string to the client.

[00:44:16.16] - Robby
I see.

[00:44:17.06] - Marco
And because we can understand and analyze the whole view, we know all the places where you are interpolating data and can then expose them as a slot for the backend to say, I have a new value for slot number 5. And then have the client update the value.

[00:44:34.17] - Robby
Okay. So let me walk through the process here. We, we, we render a dashboard and there's a count of live orders or I don't know, live something, right? There's a, there's a current, like number of live users in the application. Okay. There's, there's 35 people. Someone else signs up for an account. How does that in Rails know to update that to say 36? Is it that you in a controller, it's in another part of the controller in the app, it saves a new user or detects a user? And then what's the callback, that process?

[00:45:10.11] - Marco
So right now it's all driven by you interacting with the page or the browser sending an update command to say, I want to have a refresh.

[00:45:20.06] - Robby
Okay.

[00:45:20.17] - Marco
So right now it's pretty much for you and yourself, for you to have your browser and You tell the browser, I want to interact with it and then have it respond. Currently, we don't have any ways to push down any values, but that's just the nature, I guess, of the way we have been building these things is that we do them incrementally. So we have now the slot format and the whole underlying foundation to make this work, all work now on top of it. So you can then use ActionCable or server-sent events or whatever else you have. kind of push down and say, for this part of the page, I have a new value. What you have been doing maybe now was you have been using Turbo Streams to tell it, I want to have this selector, and here's this new string for this new selector, and then it knows how to update that. Right. But the beautiful thing about this new ReActionView architecture is that you don't need to, A, define any Turbo Frames anymore, because earlier you would have probably wrap this whole card on this dashboard in a Turbo frame. So you could refresh that part of the page independently from the rest of the page.

[00:46:27.01] - Marco
And then you have to have matching IDs to say, let's— when you rerender this page, you have to match this ID again on this exact position. But because now the compiler understands pretty much your whole view and your whole interactivity with it, it knows how to address these output slots. And it offers also a way for it to say, for this new slot, I have a value that you can use now. And then you don't have to expose any IDs or give it a selector to update. You just tell it, for this new slot, I have a new value, and it knows how to reflect the changes.

[00:46:58.00] - Robby
Okay.

[00:46:58.06] - Marco
So this is pretty much trying to take inspiration from the reactive ecosystem that we know from the whole JavaScript community nowadays with React even, or also Solid and Svelte, where you just have You update the state, the UI state, and say this new state has a new value. And the framework itself knows how to reflect these changes. It doesn't— you don't have to tell it at this position, in this element, in this DOM node, I want to have this new value. You just tell it, here's a new state, and the framework itself knows how to update the UI accordingly.

[00:47:36.01] - Robby
I see. Does this result in the server needing to send less data back to the browser, the client?

[00:47:46.04] - Marco
If you kind of consider that you have been doing pretty much full page reloads every time and just have Turbo pick out the values from this full response, then definitely. If you have been doing more of the Turbo stream kind of routes, then it's probably about the same that you are sending. But you don't have to declare it explicitly what you're doing. It will just be all kind of inferred from the markup you wrote in your files. So you don't have to go and tell it, here's slot number 1, and here's a new value for slot number 1, but it will figure this out by itself, by you just writing the erb templates.

[00:48:22.16] - Robby
Let's say like an example of, if we try to think through the whole lifecycle here, again, I'm coming at this from a little bit of a, I'm kind of a dummy about some of this stuff, because I don't particularly do a lot of stuff more on the I'm air quoting the frontend here, but, um, we've always had some version of like respond to, you know, like there's all these like different things where we re-render a partial, um, back in the, like the Rails 1 era, that was like the hot thing with AJAX, right? Uh, actually, out of curiosity, you, you coming into this world in 2013 or so, was AJAX still like a term people use much then, or is that kind of—

[00:48:59.01] - Marco
Yeah, I think in full swing, pretty much. with jQuery and all that stuff. Yeah.

[00:49:04.00] - Robby
Did you know that we had conferences specifically for AJAX back in the day?

[00:49:09.21] - Marco
I don't think I knew about that, no.

[00:49:13.04] - Robby
I gave a talk at one of them. It was a wild thing. So it was kind of a hot new thing back then. It was a whole AJAX world. And they had a special thing for like a Rails subsection where some people spoke at a conference and I think it was in San Jose, California back in, that must've been 2006, I think. Crazy time. Okay. Um, it's such a funny thing though. The story about Rails, part of its success, in my opinion, it was, it was like an early embracer of, of this like AJAX approach yet the front end layering and tooling has been one of the most complex things for us to try to stay up to date on. and navigate and make the default choices and help steer the community for 20 years. Yet it was also the thing that kind of like helped ramp it up. So,

[00:50:03.22] - Marco
yeah.

[00:50:05.00] - Robby
Uh, it's wild how that kind of all works out. But, um, and the other thing would be like something like maybe ActiveRecord or something like that. So are there other parts about Rails that really, that you really, really appreciate, but you don't feel like you actually understand that much yourself? Like myself, not really, maybe understanding like the latest frontend for the last decade.

[00:50:25.06] - Marco
Yeah, I haven't really dug into ActiveStorage much. I haven't really dug into the whole ActionText and mailbox things. I also don't think I have really dug into ActiveRecord too much even. This always just worked and it was always great. And I never had big enough of a scale for it to be ActiveRecord the actual problem. It was always the database itself, right? It never felt that I had to dig into ActiveRecord much, but It's always, I think, the partial framework that is the selling point, in my opinion. Like the, it's, it's, it's great.

[00:50:59.11] - Robby
For all of our listeners, like we, we don't know everything about everything in the Rails ecosystem just because we're, we've been working at this stuff for a long time. So thanks again for sharing. Like there's, there's little, there's gaps in my knowledge, but also I haven't needed to really dig into it. And it's nice that we can talk about it.

[00:51:13.23] - Marco
I mean, that's one of the selling points of Rails. It's like you don't have to dig into it if you don't have to. worry about it. Like, somebody else took care of it and you can build your application. And if you are struggling with something and you want to figure out how something works, then it's the time for you to dig in and try to find out how it works. But otherwise, the framework is doing its job there. It's abstracting something for you so you don't have to know how it works.

[00:51:40.06] - Robby
That's true. You mentioned you were looking at some of the other frameworks. I think you mentioned, like, was it Phoenix, LiveView, and other tooling like that? What sorts of things are you seeing pop up in other frameworks in the last 6 to 12 months that maybe anything related to AI as well that you're kind of like, oh, that's interesting how they're doing that. And maybe from a perspective where like, I kind of, not necessarily I wish existed in Rails, but like there's definitely lessons we can take from that, that you're keeping an eye on.

[00:52:08.08] - Marco
I think the one thing that's been really interesting to see is actually not even as longer, it's like, just the role of components and also component libraries in these JavaScript frameworks and stacks. And I think it's a similar kind of idea we just talked about. Like, you don't have to understand how a button works or what things you have to kind of look out for when you use a button in your app. The design system kind of tries to make sure that you have a good button, a good-looking button, and an accessible button. And you just use it in your application. And And I think even now, with agents, if you just tell it, here are 100 components we have in our application, build them into a UI, it doesn't have to think about the accessibility, about the composition, how things work and look next to each other, because somebody else took care of how they compose. And I think that's kind of the one thing about a framework that's great. It abstracts things for you so you don't have to worry about in the moment of you building in this case, a UI, because design system doesn't even allow you to kind of make it look bad because it's just composed in a way that, or built in a way so you can compose it and it doesn't kind of break.

[00:53:24.14] - Marco
And that's something I don't think we have really seen in the Ruby world too much. There have been a few attempts with ViewComponent and Phlex as well. And kind of the libraries built on top of that. But there was always something coming short in that process, which meant you are missing styles, or you have to think about how your JavaScript behavior gets tied to your actual rendered markup from the component you are looking at. And that kind of just this interaction between client and server isn't something that really transposed too much to these component systems. If you look at React and other frameworks now in the JavaScript world, they have been realizing that server rendering is actually not too bad. Funny enough. And have been pushing more and more things back to the server. And even now with the server-rendered React components, they have a way to, by default, render it on the clients, but also have a way for the server to render the same component on the backend. And I think we already have a really great solution for how things are being rendered in Rails. We really know how to server render things.

[00:54:40.10] - Marco
So for me, I think it's interesting to look at the opposite of that, to say, by default, we server render, and we can try to think what we can push to the clients to be re-rendered on the client or just to be done on the client, but keep most of it close to the server. And I think that's the one benefit we have now as a full-stack framework, or I guess, as mostly a backend framework, is that we can have all this knowledge and this greatness of Rails in the backend, and then push just as little as possible. Yeah, as much as we need, as little as possible to the client to build these richer UIs. And I think that's just this kind of, I guess, pendulum swinging and JavaScript community realizing we need to do more infrastructure work to render stuff on the backend. It's the one benefit I guess we have now that we already have this stuff on the backend and we can go the other way and just bring some of this stuff to the client.

[00:55:33.07] - Robby
Do you have much of a take on things like ViewComponents? I think I've interviewed Joel on my other podcast in the past and I think even he's said like, oh, it's definitely, it's got its, uh, I don't think he said he thinks it was a mistake necessarily. Uh, that's how I'm misquoting him right there. I'll have to go back and remember how. But these are challenging things that I don't fully understand all the complexity behind it.

[00:55:58.19] - Marco
So I have to say, I love ViewComponent. I think they're great. I also think just componentizing your UI is a good thing to do. And I think at the time when Joel was working on view component the first time, there wasn't really a way forward or an answer to how you best organize your views. So I feel like in the context of the time, ViewComponent made perfect sense. But I and Joel were talking about this for a long time at RailsConf before, and we were talking about some of the things we have with Herb now. And he has been a big contributor to the Herb codebase too. Oh, has he?

[00:56:35.22] - Robby
Awesome.

[00:56:36.03] - Marco
Yeah, I have been pushing forward a lot of things to make it also work for GitHub and their kind of use of Herb in their monolith.

[00:56:43.18] - Robby
No, they're using it, right? Yeah, I think at this point.

[00:56:46.08] - Marco
Yes, they, from what I hear, they are running it on CI for every code change. And they're also looking to adopt it for rendering all of the server-rendered views and replacing Erubi going forward. So there is some overlap there. And I think that with this new foundation that Herb kind of gives us now, that we can evolve the idea of what ViewComponents are into this kind of full-stack mindset that we can also client-side render some of the stuff that doesn't need to be done on the server side. And also, not every UI interaction needs to go talk back to the server. If you want to toggle something on the client, it doesn't need the server to respond to you with a full page again to say, okay, here's this one value flipped, and now this thing is being shown. So I think just having the option to build more client-side stuff alongside your server-end application, is the one thing we have been missing for a long time. That's what makes these JavaScript frameworks great. They can do so much nice animations, UIs, interactivity that we have been struggling to even think about. We couldn't even get to think about these problems because we were kind of stuck with other issues.

[00:58:01.13] - Marco
So I think that's what I want to get at, is just to have an option if Turbo is not enough anymore for your UI needs, that you have a way to go forward in a way that's not that you have to rewrite your whole application, but it's like additive. Right. So you can keep using Stimulus, you can keep using Turbo. It's all kind of aware of it. It kind of plays with it nicely and it extends it in some ways. And then if you really want to, you can migrate some of the things over or just build some of the UIs that you couldn't even think about with with Turbo before.

[00:58:37.19] - Robby
Okay. That's, that's cool. Um, shout out to Joel there as well. Uh, I'll definitely include a link over to that other episode I had with Joel maybe about a year ago or so that was on my other podcast, Maintainable. But one of the things I was, I was kind of curious about just to dig into Herb a little bit more. Um, if you're, if you're using fragment caching, how does that, is there, does that impact that at all? Or like the things that you might do in a Rails app, like cache Fragment caching, yeah, exactly, that particular.

[00:59:03.23] - Marco
I'm pretty sure, so I haven't looked into this much yet, because I guess it's not been the most important thing to look at. But what I understand is pretty much all ActionView doing the work there. So ActionView itself has an implementation of how it's handling caching. And that's not really something that the rendering engine so far has been concerned about. Because the whole fragment caching also works for HAML and Slim. So it's not really an ERB-specific problem. I see. And that's kind of why I haven't really looked into it much yet. But I am sure that with all the knowledge that we have now about a view and how it's composed and built, that we can either improve the way ActionView caches things or just simplify the code to achieve the same results with like more actual understanding of what the view is doing.

[00:59:55.02] - Robby
Interesting. Yeah, I'm kind of curious, having not dove into this at that level, but I know that there's been a number of projects over the years where we've definitely needed to lean on some caching just for performance things. I'm just kind of curious how that might—

[01:00:08.15] - Marco
I think, if I'm not mistaken, ViewComponents also shipped some kind of caching support recently. I think they have been pushing this back for a long time. They didn't want to do that. they were like, it's responsibility of the framework to handle this, which has been traditionally the case. But I think I saw there was something about caching even in ViewComponent itself now.

[01:00:28.00] - Robby
You mentioned helpers. Are there other things like if you have a bunch of custom helpers, does that get complicated to navigate it as well? Or should that just work?

[01:00:38.07] - Marco
So it should just work for the rendering aspect, for just rendering views. This is not a issue. Global helpers are more an issue for the static analysis, for us to understand where something is coming from. And that's the one thing that kind of ViewComponents is kind of beautiful for, because it defines a class. The helper is defined in the class itself. So you know exactly, these helpers are scoped and available only in this file and not globally. And that's the one thing that we are kind of struggling a little bit with, like analysis, because we have to do more guesswork to know where something might be coming from. We cannot be 100% sure about it, but we have a good understanding that this could be it. So I feel like that's the one thing I want to look into also more is try to discourage the use of global helpers and maybe provide a better solution for you to write helper methods like that, but they have more scope to where you use them and then have more tooling available or compile or even improvements because we can know what it's doing and maybe inline some of the things or do more logic there to help with both navigating the source in the editor, but also with compilation and performance.

[01:01:54.01] - Robby
Sure. I feel like over the years, sometimes people would, one of their arguments or critiques of the Rails ecosystem is there's a lot of magic, you know, I'm air quoting magic here that happens. So how does, as a developer and you're like, you get the, you're benefiting with these tools and it's dynamically updating things in your, in your browser. How do you, Marco, have confidence that everything's kind of like in your browser and is in sync at any given point? Is it because there's no errors at this point? How would you feel like you would answer that question a couple of years ago versus now?

[01:02:26.06] - Marco
Yeah, I think the tooling aspect helps. So if you know, you hover over something and you know, the compiler understood and sees what you're doing, it gives you some confidence to know that this is doing the thing you expect it to, right? And what we have built is also dev tools for the browser, which you can enable in your Rails app if you have it installed with Herb. So you can toggle these tools and it will show you the outlines of your views and the outlines of where slots are and that kind of stuff, how this all works. And it will also show you when things update and how they update. So it will flash the respective area and show you visually something changed and something happened. And I think visualizing these things help with you gaining trust in this, knowing what it's doing. Yeah. And I think if you don't have this and you have to trust it blindly that it is doing the thing it says it's doing, then I'm not sure I would be as confident about these things a few years ago. But knowing that This is pretty much built from the ground up for this kind of use case, which was also only possible because we have a good foundation with Prism, is kind of what gives me the confidence to say, I trust that this is doing the thing it's supposed to do.

[01:03:43.23] - Robby
That's cool. Actually, I remember that you're— I think you gave a demo of that at SF Ruby last year. I think I remember the UI and seeing all the hovering and stuff like that. I'm like, well, that looks pretty cool. But I can see that could be really helpful for those on my team that are subjected to dealing with the HTML.

[01:03:58.23] - Marco
Yeah, like, just like having the introspection available to you for you to kind of dig in if you need to. Again, like, it's a part of the dev tools, usually the same as if you do, if you do right-click and say inspect source,

[01:04:09.21] - Robby
right?

[01:04:10.05] - Marco
And you can see the whole DOM tree in your dev tools. That kind of level is what you want to have for your tools. And that's kind of what I'm trying to accomplish with these.

[01:04:21.12] - Robby
DevTools. Can you think of like a really wild type of thing that you could see that like someone potentially hypothetically being able to do with these tools that you might not have been able to do even like you might not be able to do now, but like, let's say like jump forward like a year or 2 and like, like, I'm just curious, like, do you think with like observability tools, you could like go back and actually see what the interface looked like for a particular user when they hit an issue and be able to walk through the process because you could fetch data into your environment or something like that, or like, like to really reproduce like what a user was experiencing at the time? Or think of anything wild like that you think people could potentially do with these types of tools?

[01:05:03.08] - Marco
Yeah, I think that's an interesting one I haven't really thought about. I think like, just having a user flow and maybe even signup tracking and conversion, like how people react to your page, maybe you can have some more advanced tracking with these Tools now, but heatmaps

[01:05:19.14] - Robby
and stuff like that. But

[01:05:20.18] - Marco
yeah, but I think that's more than a product question of what you want to build on top of it that you can build with this as an underlying library. What I kind of like to see more is just more animations, more kind of beautiful UIs that you can— that feel nice to use. And having even like an experience, like I I have been building a small demo app, which is like a music player, Spotify kind of, Apple Music kind of application, where you click albums, it will kind of show you skeletons when it's loading, it will kind of have a play button so you can play the tracks, you have like a playing bar at the bottom, and just have this like all this whole rich experience of a dynamic player, it keeps playing when you kind of switch pages. And you have kind of all this kind of interactivity and reactivity kind of built in. And you can just do this seamlessly with Rails. That's kind of what I want to see more, just to have more ambitious UIs where previously teams and companies might have used a full React stack with a Rails API in the past, that they say, well, with all these new tools, we don't need to ditch the Rails stack and use React, but we can do this all in a traditional Rails way of building applications.

[01:06:40.12] - Marco
And that's where I think we can do more as a community, help with offline support, help with, like, offline first. So you kind of have an interactivity. It doesn't have to block the UI and talk to the server and come back in 200 milliseconds, but it can do this instantly in the browser and then in the background, sync the data or— talk to the server and do the updates it needs to. So just you have this more offline local feel to your Rails applications.

[01:07:11.21] - Robby
That offline thing is always, is an interesting one, because like, definitely, we've definitely worked on a number of projects over the years where it's like, well, what are those types of scenarios happen? It's like, like Wi-Fi is not reliable. We've worked on projects where house repair people are going into people's basements, and there's no cell reception, you know, and they need to take pictures of like an issue. and like have that be something that they can sync later, or they go way out in the middle of nowhere where there's no reception anywhere. Yeah. You need to be able to have tools, tooling like that. And it's always been a little bit of an awkward thing to make work well. And sometimes we've gravitated more towards maybe working on some slightly more native apps so that we can then, or like mobile app that could sync data back later or something like that. But, um, cause the tooling always felt a little clunky, but this was, it's probably been a good, 7 years since we've done some of those projects. But—

[01:08:01.05] - Marco
It's interesting because all of the foundational tools already exist in these ecosystems. So there is a good database to sync data back and forth and store offline and sync it back. It's more a matter of you being able to integrate and use your Rails views as part of this kind of solution, right? And with this whole reactivity stuff and this client-side rendering it already offers in ReActionView today, I can see a mode where we compile all your views into a small bundle that you fetch on the first time you open the page. And then you have all the views available on the client. And then you can just navigate pages instantly. You don't have to wait for Turbo Drive to kind of show the spinning progress bar and then swap in the page. You can do this all on the clients more efficiently and more— Yeah.

[01:08:50.23] - Robby
That's great.

[01:08:53.20] - Marco
That's kind of the vision, I guess, where I want to see people, what they should be trying to build with these kinds of tools.

[01:09:00.13] - Robby
What's been the most surprising thing that you've seen somebody do with Herb that you're aware of so far?

[01:09:05.07] - Marco
I have seen not too much yet with like the ReActionView things, because it's been out for a few weeks now. It's not been long. But I've seen a lot of people use lint rules really creatively to migrate from old design systems to new ones, trying to make sure that somebody doesn't introduce the same UI bug again, and that kind of stuff. So it's interesting use cases you can do now that you can enforce and encode in— encode and make sure that it's not being violated on every push.

[01:09:37.01] - Robby
That's cool. One of the other topics I wanted to spend a little bit of time on with you is Ruby events. So you've been working on that for how long? When did that project get started?

[01:09:48.14] - Marco
I think it started in 2023 as Ruby Video. That is like the initial birth of that project. But there was another one called rubyconferences.org, which has been around for over 10 years. And in 2025, these 2 projects merged. And that is what became Ruby Events that we know today.

[01:10:11.10] - Robby
For anyone that's not familiar with it, what is RubyEvents? What do you have on there?

[01:10:15.04] - Marco
So RubyEvents tries to index all the Ruby events that exist. We try to have an index that knows about all the events, all the speakers, all the talks, as like a resource for the existence of our community. So we know somebody gave a talk about this topic, and you have a way to find it and have a beautiful way of watching the recordings. And just see, even like on my profile, if you want to watch any of my talks or Robby's talks, you can go on his profile and see all the talks he's given and find out where it was, what other talks happened at the same event, and just have a nice way to know what happened in the Ruby world.

[01:10:55.16] - Robby
How is all that data collected or managed? Is this something like you scraping things or is this something a little bit more manual?

[01:11:04.23] - Marco
Yeah, it has been manual for the longest time, especially with rubyconferences.org. It was pretty much a big YAML file that people just contributed a new data entry. And that has been the case up until a few months ago, even. Like, it's still today, there's a lot of manual data entry. And we have been trying to just automate more of it, even with AI tools now, because that's what they are great at. Like, you give them some data, unstructured, and have them convert them into some structured format. And turns out it's quite tricky to let LLMs handle some of these automated workflows. So we have been slowly trying to bring them into it, but we have not been having too much success in the past. But now we have been trying to expose more MCP tools so the LLMs can call some of the tools to index events or run Rails generators to generate the right YAML files with the right structure. And Rachael, one of the team members on the team, also has been working on that and gave a talk at Rails World about it this year. So it's more about that we try to expose more of the tooling to agents, but also help humans to use these same tools to help maintain the data.

[01:12:20.06] - Robby
I saw that you're working on building something called Yerba. What's, what's that?

[01:12:25.22] - Marco
So After having had a lot of kind of positive experiences with Herb for HTML ERB, I wanted to have a similar thing for YAML files. And jokingly, we were like, yeah, Y for YAML and ERB, and then you have Yerb. And then I was thinking, actually, there is the Spanish word for Herb, which is yerba. So this is kind of like, I guess, a small inside joke that this is like just for YAML files. Yeah, yeah. But what it is, is pretty much also a YAML parsing library, but it allows you to programmatically edit YAML files. So you can write a Ruby script or dump something, or you can read a YAML file, modify something in Ruby, and then tell it to write it back. And it'll only update the actual field that changed. It doesn't try to reformat the whole file. That's something that's been kind of annoying with the YAML library in Ruby is that you parse it and then you get a Ruby hash back. And then you serialize it, and then it formats it whatever the Ruby standard library thinks it should be formatted as. And so you lose comments, you lose formatting, you lose all of that kind of precious information that we have stored in these YAML files.

[01:13:36.10] - Marco
And with yerba, we try to make this more a foundational toolkit for YAML files, so you can preserve everything that's been there and only try to update what actually changed when you're writing it back.

[01:13:49.08] - Robby
I was just looking at what's your— this was maybe pretty recently. I think it was like Yerba Record.

[01:13:58.20] - Marco
Yes. So—

[01:13:59.15] - Robby
So yeah, it's just like, this looks a little like ActiveRecord vibe here.

[01:14:05.02] - Marco
Yes.

[01:14:05.16] - Robby
What are you doing, Marco?

[01:14:08.06] - Marco
So we used a library called Frozen Record before. This is a I think it was extracted from Shopify and Jean Boussier was maintaining it since. The idea there was that you can give it a YAML file and you get the ActiveRecord interface to query data. So you have a YAML file, tell it— Okay. Here's a model and here's the YAML file. And then it kind of exposes the YAML file as ActiveRecord-style API to you. And then I was like, okay, now I have this Yerba library. So why don't I also create a small layer on top of it called Yerba::Record that lives in Ruby events just now? We haven't extracted it into a gem, but have it like an Active Record interface so you can define all the relations, all the records. So you can say, give me all the talks, give me all the speakers, and it knows how they kind of relate to each other. So when you tell agents now to update a speaker or other talk from a new speaker, it knows how to add the speaker to the existing speaker YAML file. It knows how to kind of update these cross-references.

[01:15:17.21] - Marco
And it just has a good understanding now of YAML files and how they relate to each other. So it's more, again, more tooling, more foundational kind of tooling work that we can try to automate some of these things more.

[01:15:29.20] - Robby
Out of curiosity, does Ruby events get deployed in a, is it a static site that gets generated or what versus like, what's, what's the benefit of doing it this way? Is it because the submissions are currently YAML that people send a PR? They're like, hey, there's a new conference or here's some new details about an upcoming event. And that's how things get submitted. So you want to be able to interact with this data without just having like a web form somewhere that people fill out.

[01:15:59.04] - Marco
It's been interesting because there was an event site from Confreaks that have been recording a lot of the Ruby events. But the website at some point was gone. And there was only the YouTube channel remaining. There was also a site called, I think, Lanyrd before my time that was used for conferences and like signups and stuff. That was bought by, I think, Eventbrite and then shut it down. And it's been kind of this recurring pattern now with meetups.com even, that we get data, it's in some platform, some company buys it and then it's like gone and you have no record anymore of these events. So our idea was more that we keep it in a YAML file on GitHub, open source. So whenever we don't deploy Ruby events anymore, there's at least a record of all the files, of all the events, of all the data that's still out there. Yeah. And in a way, it helps us to help contributors actually contribute their data. Because you just have to review a pull request for them to add their events to the site. And for a lot of people, it's also sometimes even their first open source contribution.

[01:17:07.13] - Marco
So we give some opportunities for people to just play through this whole experience of contributing to a repo in public, forking the repo, creating a pull request for the first time, just playing through this whole kind of process once. I think it just, in a lot of ways, is beneficial for the community in other ways.

[01:17:26.23] - Robby
No, I appreciate— I think that that's, that's an interesting perspective. I think that, that makes sense. And when you've been around the communities long enough, you see things come and go and data gets— just vanishes. And you only kind of somewhat rely on the Internet Archive, Wayback Machine, but it's not perfect. Yeah. And this provides a little bit more transparency of like who, who submitted the thing and when, and as you said, that's a good contribution, first timer contribution to an open source project in that sense, because it's like open source data in that way. But it does introduce some fun complexities when it comes to like, how do you manage all that data and then like render it out usefully when it's humans, you know, probably typing in some YAML file, which is not always, you know, it's better than an XML file, I suppose, but. Yeah. That's interesting. All right. Well, that kind of helps clear that up. Are there types of things like if anyone was interested in helping work on things like Ruby Events that there's types of projects you folks are working on that you could use some additional help with?

[01:18:33.11] - Marco
I mean, Ruby Events is exactly this point. Like if you have been running a community meetup, even a conference sometimes, there's a lot of conferences we don't know anymore because even their own website is not up anymore. And there's no public record of it happening. So if you have been running events, organizing events, a meetup, it would be good to know about them so we can keep a record of them that they happened. And that's one thing. And in a lot of ways, RubyEvents for me personally is a— I want to say playground for all the tools that I have been working on. So it's been great to— have an app that's not really critical of it working 100% of the time. Not that we encourage downtimes or something. It's more that there's not too much trouble if the UI is a little bit funky sometimes, or there's some UI glitches. So it's been more like a test vehicle for me to just try out all these libraries and make sure that there is more than just my demo apps out there to kind of test out these tools.

[01:19:35.17] - Robby
That's great. I do think that having access to a project that, you know, has some valid purposes of being up, I think changes how you experiment with things, I think, at least personally speaking.

[01:19:48.16] - Marco
Definitely, definitely.

[01:19:50.17] - Robby
Versus like—

[01:19:51.05] - Marco
And it's not a small app anymore. It's a decent-sized app. So it's not this demo toy app anymore. And it also gets some traffic. It's not that it's like nothing. So it's a I think a good mid-sized app to run some of these tests on and have it be also an opportunity for even people to see these tools for the first time in practice. So you can check out Ruby Events. It's all open source. It uses these new tools. You can see how they're being used there to build some of these UIs. And I think it's also cool to have an app, if you are working in a day-to-day application at work, that is stuck on an older version of Rails or still using the latest technologies to kind of have an app to see these modern ways being embraced and working in public. So that's the other kind of aspect to it.

[01:20:41.17] - Robby
One more quick topic, because I know it's a really easy topic for everybody to talk about, Marco, but how are you using AI tooling as of early November 2026?

[01:20:53.15] - Marco
I'm still kind of, I would say mixed about it. I have a few use cases where I think they are great. Like I just mentioned with the example of it knowing how to index events, if you give it the right tools and give it enough kind of constraints for it to work in and say, call this tool when there's a new speaker, call this tool to create a new talk, to have them just do the things you tell them to do. So if you give them enough guardrails, if you give them a way to verify their work, I think they are great and help you focus on the real important and hard problems. But I found that at least for the foundational type of work that I've been doing, that they are not the best, or that they create so much code and so complicated code sometimes even that you really have to know what you're dealing with for it to be able to judge the outputs, especially if you try to create experiences that haven't been done before. Especially like in Herb now or in ReActionView, there's not something you say, here's this one test suite, please port this from Ruby to Rust or the other way around, or like where you can just have a fixed set of inputs and outputs you can just have to translate.

[01:22:06.01] - Marco
That's easy enough. That's not really the case, been the case for me at least, because this is more trying to create this experience of how this should look like, how it should feel. And that kind of experience is things that agents don't really do well. They are great with, as I just mentioned, if you give them enough input and output values and tests that have to pass, that they get something working. And for a lot of things, this is all you need, and this is already working great for that. But I found for me that that's more distracting than helping, at least for this kind of foundational type of work.

[01:22:42.09] - Robby
What about, you know, when you're, things like Herb, like how do you think that's going to be helpful for folks that are using AI a lot in their day-to-day development work? Is it like a good timing that this happened to land around the same time?

[01:22:58.21] - Marco
I think so. Especially the linter stuff and the compile-time errors and the diagnostics that you get. So if an agent writes any kind of code, like an ERB file, and it instantly gets told by the LSP running in the harness itself that something is wrong about this template, it can instantly react to it and fix the offenses or fix the errors itself without you having to tell it that something is wrong about it. And I think just giving agents more introspection in what they are working on, that they have a way to verify their work, is helpful for agents. So I think That aspect is still relevant and useful. Maybe not so much the autocomplete, and maybe not so much the editor tooling in the editor that you might also get from Herb today. But it's just one of these things you can build with a toolkit like Herb now, because you have the foundation there. And it's just a matter of how you employ these into your harnesses or CIs or any other workflows.

[01:24:00.13] - Robby
Are there any AI tooling things that you've been like itching to spend some time playing with more, but you just haven't had a good opportunity to do that with yet?

[01:24:12.12] - Marco
I feel like I currently at least have all the tools that I need to be productive with AIs, which is really boring, I guess, for most people. So this is Claude Code Desktop. And that's all I pretty much use. And For me, it has been working great for when I need to use it. But I also don't see any need for more right now. But I guess that will change and time will tell.

[01:24:40.23] - Robby
Yeah, I'm curious to maybe connect with you again at some point to hear how, when you're going into different client engagements and seeing how it's like every client is like at a different point in their adoption or de-adoption, I maybe, I don't know what the word is, like, we're kind of steering away a little bit now. Like, I've seen a lot of different things with different clients we've talked to. And potential clients as well. And I'm just kind of curious, like, what you're seeing and like, oh, like some teams are like, we're not even looking at the code anymore. And other teams are like, yeah, that sounds crazy. And you don't have to have an opinion about that yet. But

[01:25:15.01] - Marco
yeah, I think the most important things or thing to do there is to just write more guardrails for your agents. Have lint rules, employ more RuboCop rules, even use Herb Linter if you are writing ERB. stuff. And have, or even like ArcSpec, as in the interview from Paulino, he kind of built one to kind of make Rails architecture more, or feel more right and enforce it in part of a, as a linter kind of step in CI. And have like, I guess, even things like Packwerk maybe to kind of try to isolate things more into small pieces and bundles. So it doesn't have to explore the whole codebase every time it wants to change something. And have like clear boundaries. I think these kinds of things help. I guess it's just a matter of time that we will know what works great and what is like more distracting or distraction.

[01:26:04.22] - Robby
And what are you excited about in Rails right now as we're heading into 2027?

[01:26:11.05] - Marco
Yeah, I think there's still a lot of opportunity for Rails frontend to shine. And I think that I have some answers to it, but I don't have all the answers for it. And I also know that a lot of people and clients want to use these technologies, but weren't really motivated to kind of look into Turbo and Stimulus and make it work for them. So I feel like just having more people try out these tools and can also share what they need and what they kind of are struggling with in general, not even like the just frontend stuff. I feel like in general, just companies trying even with these AI workflows now? What are your struggles? Like, is it support for worktrees? Like, if you want to have worktrees in your Rails application, and have it be bootstrapped with your seeded database, like, stuff like that, like more, how can Rails help to improve your agentic workflows, I think. And that's, I don't really see talked about much now. I think that's something that I would be excited to see more happening is How can we upgrade Rails to be more friendly to agents as well?

[01:27:20.20] - Marco
Like, I guess we have seen some of the stuff with the Markdown support recently, but it's probably more for like other agents consuming data from your app. But how can we improve the local development workflow for agents to be more ready for that?

[01:27:36.04] - Robby
Yeah, yeah, I think I appreciate that. And I do think we need some more conversations around that. All right. I don't want to keep you too long, Marco. I know you got a really busy schedule ahead of yourselves, but a couple of quick last questions for you, Marco. Is there a software book that you find yourself recommending to peers?

[01:27:57.17] - Marco
I have to say no.

[01:28:01.00] - Robby
Which is a perfectly fine answer.

[01:28:04.09] - Marco
I am the type of person who learns by doing. I haven't really read too many books on software engineering. It's more a learning by doing thing for me. So I can't recommend anything here.

[01:28:18.17] - Robby
That's— I appreciate the honest take on that. Is there a non-software book that you'd like to recommend people? Do you read books, Marco?

[01:28:31.01] - Marco
I don't read books. That's the point.

[01:28:32.20] - Robby
Okay. You read blog posts.

[01:28:37.06] - Marco
Also not too much actually. It's a—

[01:28:39.23] - Robby
well, I—

[01:28:41.10] - Marco
yeah.

[01:28:42.21] - Robby
This is great. This is going well. No, I appreciate it. But you produce really great content and the Herb website looks great. It has a lot of great information and tutorials on there. So thank you for that.

[01:28:55.09] - Marco
Thank you.

[01:28:56.02] - Robby
Are there other examples of other tooling that you're out there, like you look at as like, they do it really well that you aspire to be as good as?

[01:29:04.23] - Marco
I really liked the recent work on Prism. I think, as I mentioned a few times now, that's been excellent. I also really have been enjoying the whole Ruby LSP ecosystem to even bring these kind of tools to Ruby files. And more recently, I think the Rubydex is also a really interesting project from Shopify as well, to kind of have a global indexer for your Ruby codebase, and then you can ask questions about how things relate to each other and how you can produce more accurate tooling on top of it. So that's something I want to look also into for Herb, how Herb can make use of Rubydex and these kinds of tools and how they integrate.

[01:29:46.14] - Robby
Wonderful. I'll definitely include links to all those that I can track down for our listeners. And with that, Marco, thank you so much for stopping by to talk shop with us.

[01:29:54.06] - Marco
Thank you for having me, Robby.

[01:29:57.06] - Robby
That's it for this episode of On Rails. This podcast is produced by the Rails Foundation with support from its core and contributing members. If you enjoyed the ride, leave a quick review on Apple Podcasts, Spotify, or YouTube. It helps more folks find the show. Again, I'm Robby Russell. Thanks for riding along. See you next time.