Episode 57 - Marco Roth

Marco Roth joins us to unveil Herb, his revolutionary toolchain for Rails views that's reshaping how we work with HTML and ERB. Having identified a critical gap in the Rails ecosystem—robust tooling for the view layer—Marco decided to build the solution himself, learning C along the way to create a parser with unparalleled cross-platform compatibility.

Far from just another syntax checker, Herb represents a comprehensive vision for modernizing Rails views. Marco walks us through his layered approach, starting with immediate editor feedback for markup errors and ambitious plans for reactive views inspired by Phoenix LiveView. The most exciting prospect? Allowing developers to write modern, interactive applications without abandoning Ruby for JavaScript frameworks. "I want to bring back some awesome experiences from JavaScript to the Rails ecosystem so we can keep doing Ruby," Marco explains, highlighting how Herb could transform ActionView after two decades of relative stagnation.

We also explore Marco's approach to managing multiple ambitious projects alongside a consulting career, his upcoming conference schedule (including RailsWorld, FrienlyRB, and Euruko), and his work on Ruby Events—a catalog of over 7,000 Ruby talks that serves as an invaluable community resource. Marco shares insights into his development process, the challenges of mapping tag helpers to HTML, and his recent implementation of Tailwind class sorting in the Herb formatter.

Whether you're frustrated with Rails' front-end limitations or simply curious about innovative tools reshaping the Ruby ecosystem, this conversation offers a fascinating glimpse into the future of web development with Rails. Marco's work reminds us that with the right tooling, we can build modern, reactive applications while maintaining the developer happiness that drew us to Ruby in the first place.

Send us some love.

Honeybadger
Honeybadger is an application health monitoring tool built by developers for developers.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you.

Support the show

Episode Transcript

Speaker 1 (00:01):
Hello everyone, Welcome to another episode of
Code and the Coding Coders whoCode it.
I'm your host, Drew Bragg, andI'm joined today by the one and
only Marco Roth.
Marco, for anyone who somehowis not familiar with your work,
would you please do a briefintroduction?

Speaker 2 (00:15):
Yeah, my name is Marco.
I have been doing Rails for thepast decade or so and over the
last few years I've beenfocusing a lot on open source
and now conference talks, andI've been mostly dabbling in the
Hotwire and JavaScriptecosystems and have it be more
to what I like to write myself.
So I don't have to go into thedeep rabbit holes of SPAs and

(00:40):
React and all of these kind ofstacks.
But that's what I want to do.
I want to just bring back someof these awesome experiences
that we have in JavaScript backto the Rails and Ruby ecosystems
so we can keep doing Ruby andRails for the time being.

Speaker 1 (00:54):
Awesome.
So the way this episode isgoing to work for anyone new to
the show is I'm going to askMarco three questions.
I'm going to ask him what he'sworking on, what kind of
blockers he has.
If he doesn't have a currentblocker, he can talk about a
recent one he had, the steps hetook to solve it, etc.
And then, to wrap up the show,we'll ask him what's something
cool, new or interesting thathe's recently learned or

(01:14):
discovered or built.
It doesn't have to becoding-related, but this is Code
Encoder, so it totally can be.
So, margo, you are a busy manwith a lot of things going on,
but when someone asks you whatyou're working on, how do you
answer it?

Speaker 2 (01:29):
Yeah, it's been interesting to kind of hop back
and forth between all theseprojects and it's been super fun
, also a lot of learning doingall of these projects.
But most recently I have beenfocusing on a new project that I
call Herb.
It's on purpose of an H in thebeginning to the, I guess,

(01:50):
american audience, just to kindof avoid the confusion between
ERB and Herb.
That's the whole project.
So that project is tooling forHTML and ERB files and the H
from HTML, the ERB from ERB, sothat's Herb, and the H from HTML
, the ERB from ERB, so that'sHerb.
And it's an ecosystem of toolsthat tries to help you build

(02:11):
better HTML ERB files kind ofhave more tooling, make your day
easier to work with these files.
We have been seeing a lot ofawesome tooling in the Ruby
ecosystem, especially latelywith Ruby LSP, but we haven't
really seen anything major or iftooling at all for the view
layer in Rails especially.
That's kind of what I want totackle.
I want to kind of focus onimproving that, making it easy

(02:33):
to work with and have a greatexperience inspired by the
JavaScript ecosystem mostly andbringing back some of that
experience to Rails.

Speaker 1 (02:42):
And you're talking about it like it's a pipe dream,
but I have the VS Codeextension installed and I'm
running it at work and it'sawesome.
It already does a lot of veryhelpful things making sure the
HTML markup is good.
It's like blurting me if Idon't close a tag properly or if
I messed something up, and Iknow you gave a really awesome

(03:02):
talk at RailsConf.
If anybody hasn't seen thevideo yet, you should definitely
check it out, but it alreadyfeels like it's an incredibly
useful tool.
I don't think it's going to bea useful tool.
I think it already is.
It's one of those tools that,as I'm using it, I'm like how
did we not have this before?
What made you I don't want tosay come up with the idea,

(03:23):
because the idea is like I feellike we all at some point was
like man, I wish my editor wouldjust yell at me if I don't
close a tag or if I screwsomething up in my ERB or
whatever.
But you actually made it happen.
What was the thing that made ithappen for you?

Speaker 2 (03:42):
Yeah, I mean I've been mostly using HTML ERB for
most of the applications I'veworked on throughout the years
and I kind of acknowledged thefact that there is no tooling
and I just kind of worked aroundit and now I'm really good at
formatting the files by myself.
But I was like, yeah, why don'twe have a tool for this?
There hasn't really beenanything that's really solved it

(04:04):
once and forever.
I feel like there have beentools, there have been projects
to kind of tackle this, but mostof them didn't really have this
easy to set up feel or easy tokind of make it work for you use
case and for your application.
There was always some hassle tomake it work and I just wanted
to kind of make it work formyself.

(04:24):
Just for that I have thetooling that I wanted to have
for working with these files.
That's kind of one of the partof the motivation.
The other part was that I havebeen working on dev tooling for
the past few years too.
Most of the stuff was in theHotwire ecosystem as well.
So I've been working onstimulus LSP and triple LSP and
I've been wanting to make astimulus lint plugin for the

(04:46):
longest time too.
But when I was working on those.
I wanted to make them work forERB as well.
Right now, still to this day,they don't work with ERB.
They only work with HTML.
So you can have HTML in yourERB files and it works in those.
You can have HTML in your ERBfiles and it works in those.
But as soon as you go andreference tag helpers or write

(05:08):
Ruby to output HTML, theextension doesn't work anymore.
So I was working on those.
I had some other projects whereI was like it would be cool to
have an ERB parser to just makeit work and make it easy to work
with.
So I had kind of that part ofthe inspiration there and I was
like, yeah, let's just tacklethis from the ground up.
And it's obviously notsomething I have been doing a

(05:31):
lot.
I have been dabbling withcompiles and parsers in the past
, but I haven't really had a bigproject to just work on it that
way.
So it was in a way also kind ofa way of learning new
technology, new tools, newlanguages, program languages,
but also just having like a sideproject to hack on.

(05:52):
I guess at this point it's morethan a side project, but still
it's kind of a side projectbesides my regular day work, so
it's cool to have something towork on.
So the parcel itself is writtenin C and I haven't done any C
before the project, so it was acool way to learn C.

Speaker 1 (06:08):
Cool isa.
Certainly a choice word forworking with C.
Yeah, the thing is, I wasscared to touch C.

Speaker 2 (06:16):
From what I heard, it's one of the worst languages
to work with.
It's super hard to learn, superhard to manage, but I found
that now working with it alittle bit, that it's not
actually that bad.
I think it gets a bad rap forwhat it is, even though it
actually is not that bad.
If you kind of sit down andlook for what you need and how
it works and then it is such asimple language it doesn't

(06:38):
change at all.
It has been the same for thelast decades at this point.
So it just is super easy tolearn and super easy to pick up
in that sense because it is justa super simple language you can
do things with and in my case Iwas looking at C because it is
A fast if you kind of want towrite a parser.

(06:58):
But that wasn't the mainmotivation.
The main motivation was morethat it's more compatible with
other tools and also portable.
So if you have been lookingaround in Ruby ecosystem, we
also got this new Prism parserfor Ruby, which is also written
in C and it has also a C API andit has a bunch of backends to

(07:19):
make it work for JavaScript.
It makes it work for Java.
It makes it work for Rust.
It's all because it's supersimple in C.
Not simple, but it's the mostlow-level language you can think
of, which isn't a high-levellanguage but it's still portable
, so you can use it from allthese other languages.
So I was looking to write thisparser in Ruby first, because
that's what we know and do everyday.

(07:40):
But then I realized all theseother tools I work with are
written in JavaScript or in theweb or are somewhere else.
So I don't really have a way ofusing the parser if it's
written in Ruby.
But if I go down a level andsay I write in C, I can write
Ruby bindings, use it from Ruby.
I can write JavaScript bindings, use it from Nodejs.

(08:02):
And now we can also use WebAssembly to compile to Web
Assembly and then use it fromprettyjs.
And now we can also useWebAssembly to compile to
WebAssembly and then use it frompretty much anywhere.
And thanks to C, now I can useit in the browser, I can use it
in JavaScript, I can use it inNodejs, I can use it in Ruby and
it just works in that sense.
So that was the main motivationand as a side effect, it is
fast as well, which makes itideal to build dev tooling to

(08:23):
build editor integrations andhave it pretty much run on every
keystroke even though itdoesn't have to, but it can run
on every keystroke and it's fastenough to give you fast and
valuable feedback in the editor.

Speaker 1 (08:35):
Yeah, I was going to ask about the language choice
because when you pull up theHerb repo, it's not a single
language.
I mean, most of it is actuallyTypeScript.
But you have TypeScript, youhave C, you have Ruby, c++,
regular old run-of-the-millJavaScript, like there's a lot
going on.
You're what is it calledpolygot when you write in
multiple languages?
Like I can write JavaScriptbecause I have to, but if I had

(08:58):
to build a tool in JavaScript,that's out of my normal
wheelhouse.
So you already do JavaScriptand TypeScript in addition to
Ruby and you do it expertly well, and you just decided I'm going
to add C into my stack.
And where's the C++ coming from?
It's not a huge amount, butit's there.

Speaker 2 (09:16):
Yeah, the C++ is for the Nodejs bindings, so we have
native Nodejs bindings.
Nodejs is written in C++, Ithink mostly.
So you need some glue code tomake that work for Nodejs
extension but also for theWebAssembly integration.

Speaker 1 (09:32):
So in your RailsConf talk which was fantastic and you
got Andrew Mason all pumpedabout it too.
He came back from RailsConf andthe first thing he did was like
we're running Herb on Podia'scode base and seeing where it
breaks and all this stuff.
He was pumped, leaving yourtalk.
And then I got to watch therecording and I also was very

(09:52):
pumped.
It was like installed the VSCode extension.
It was like this is awesome.
It is a little simple right nowbut it still is.
Like I mentioned filling thesegaps already, like it's already
yelling at me for maybe it'scode that I didn't write, that
someone just like didn't close adiv or like the formatting is
just weird and it will highlightproblems, which is so nice.

(10:15):
It's so nice to have that kindof almost like expected tooling.
But in your talk you laid out apretty awesome vision for what
this tool can do and you saidthere's things that you're
definitely going to do, likemaking the formatter and linter

(10:36):
work and then make itconfigurable, which I'm sure
everybody appreciates Bikeshedding on how we format things
.
Again, we're going to need astandard Herb at some point.
But one of the most excitingthings was the ReactiveView
stuff.
I believe you said it wasinspired by Phoenix LiveView.

(10:57):
That feels at least from my end, where I do predominantly
application development.
I've worked on small dev toolsbut nothing to the size and
scope of her.
But that seems ambitious to me.
How ambitious do you think itrealistically is versus?
I think that this is going tohappen.

Speaker 2 (11:19):
It is super ambitious and that's kind of what I want
to go for.
I feel like for the past 20years in Rails the framework has
been around.
Actionview hasn't changed thatmuch, maybe for the better,
because it's been super stable.
You can just rely on it.
It just works even five yearsfrom now.
But the thing is thatapplications nowadays expect

(11:41):
more interactive UIs.
It requires more ambitiousviews as well and also more
ambitious tooling.
Most of the tools nowadays, ifyou just install or use a
JavaScript framework, it justhas the tooling and all the
bells and whistles built in.
You don't have to do anythingand it just has it all there.

(12:03):
And that hasn't been really thecase for the Ruby and Rails and
especially the view layer inRuby and Rails at all.
So it just felt right to go andtry to innovate in this space.
We have had approaches fromlike view components and nice
partials and like other gemsthat are trying to make it at
least a bit nice to work with.

(12:24):
But it still feels like I'mmissing something foundational
that makes this all work andfeel like it is a modern
alternative to what we havetoday.
That's why I think we have togo a bit more ambitious, to kind
of lay out the vision, to saythis is where we could go and
it's what we could have if we goand focus on it and kind of

(12:45):
build this thing.
But also, because it's soambitious, I wanted to kind of
layer it into multiple layers sowe don't have to do all at once
and just start at the verybeginning to make it just nice
to work with, then maybe see ifwe can make it reactive and
later we can see if we have moreother ideas that we can
integrate with this new approachthat we have.

(13:07):
So one of the first things Iwant to kind of work on when
this is about to come out is theway of how you get feedback
from your view files ifsomething goes wrong.
Nowadays, if you just have anerror in your view file, it
might give you a nice error, butmost of the times it doesn't.
It is quite frustrating to seeor to figure out what's wrong
with it.

(13:27):
So I just want to, now that wehave this parser, we can parse
these view files ourselves.
We know where something goeswrong and something is wrong in
the view file, so we canpinpoint the error in your file
and say this is actually whereyou did something wrong and just
having that feedback built intoRails.
So you kind of reload your fileand it just says online 20,

(13:50):
character 25.
This is where it's likesomething is wrong about this.
And that's kind of the firststep, just to make it more
actionable and kind of moreinspectable to see what is going
wrong.
And the next step would then beto see if we can make it maybe
more efficient to render some ofthese Vue files, because render

(14:11):
calls are somewhat slow if youdon't do them the right way.
So there's stuff we can do tooptimize maybe some of these
render calls and maybe how wecompile these files, these Vue
files, because all the Vue filesare getting compiled into
actual Ruby code that the app isrunning.
But if we can kind of have someoptimizations there, because we

(14:32):
have now all this introspection, these Vue files, we can maybe
make this more efficient, moreperformance.
That's something to look into.
I'm not sure how feasible thatis and if it actually makes any
sense, but it's something toexplore now that you have the
tools available to look at this.
And then, as I mentioned, thenext step would be to see if we
can make it work with ReactionView, which is like the reactive

(14:55):
views.
The idea here is that we go andlook into all the variables and
methods you are using in yourview files and somehow we are
keeping track of the state, likeyou have it in React, for
example, where you define thestate, you are looking at the
state and render it out, andwhen the state changes, the view

(15:15):
itself knows how to updateitself and to reflect the
changes and then it will renderor re-render the changes back to
the browser page.
So the same thing is kind ofwhat we want to do here, just
that we don't do it on theclient side but we do it on the
server side and maybe have itemit some turbo streams or some

(15:35):
other ways of getting theseupdates back to the browser.
But you don't have to kind ofworry about what is changing and
how it's changing.
You're just updating the statesand the kind of engine itself
knows how to reflect thesechanges and bring them back to
the client, which makes it superlike nice to work with.
This is, as you mentioned, mostinspired by Phoenix Live View

(15:56):
and to some degree also fromwhat we have been doing with
Stimulus, reflex and Capealready in the past, which is
kind of like, was an early portof Phoenix Live into the Rails
ecosystem and it kind of diedout a bit after, like Hotwire
was announced and kind of becamebig.
So there are still some, I think, nice ideas in the seamless

(16:18):
reflex that we don't have whenit goes on in Hotwire today.
But I think now that we have orare thinking about how we can
kind of improve the view layerin Rails, that we can bring back
some of these ideas, and thesereactive views are kind of one
part of that.
And as a super ambitious laststep for what we can do, if you
have all of this figured out,which will take a few months

(16:38):
from now, is see if we can makeit work with existing SPA
frameworks so that you can mountReact components, you can mount
Vue components, that you canmount Svelte components I don't
know.
Just have it like a super niceway, an easy way to use these
existing components that youmight have already, be it from
your own style guide or fromyour own design system or from a

(17:01):
third-party one like ShadSianor any of those other frameworks
, that you can just use orregister these components and
then use them in your erb filesas if they were html and it will
figure out how to compile this,how to transpile this, how to
make it hydrate the the htmlwhat it needs, and just having

(17:24):
this experience of writing HTMLERB, as you are used to from
today, just having all thesemodern alternatives and tools
right built into the Rails viewlayer.

Speaker 1 (17:36):
Can I have that now?
Because that sounds awesome,like all of that sounds.
I mean, it really is somethinglike you said, like Action View
hasn't changed much in the 20years Rails has been out.
It really hasn't.
I mean, the biggest change, atleast that I can recall, to
ActionView was the render in,and that I don't know if you
would even consider thatnecessarily ActionView, since

(17:59):
that was kind of like otherobjects, giving them the ability
to render for view components.
But yeah, I mean, for the mostpart, action View just kind of
sits there.
I think that when peoplecomplain about the Rails
frontend, I sort of feel likethat's what they're talking
about.
Action View is so basic.
If I want to do anything fancy,I'm reaching for Inertia Rails

(18:23):
or React on Rails or somethingelse to like bring that
JavaScript SPA that, like a lotof us don't want to work on that
stuff.
I mean, we occasionally have to, which makes what you're saying
sound even nicer.
It's like, hey, when you haveto use a react component or a
view component, view JScomponent, as it were, this

(18:44):
would give you the ability to dothat.
But there's a good chance ofnot having to reach for some of
that, depending on the problemyou're trying to solve because
the tooling is so much betternow, because Action View is
better.
I mean, you talk about it inyour RailsConf, talk about how
breaking down the file into thisAST and being able to generate

(19:08):
HTML back and forth and the Rubyand everything gives you.
So it's like this layeringeffect which I find so
interesting.
Right, you have this really bigproblem and you've very
effectively taken the smalleststep possible to solving this
very large problem.
But that necessary step, man, Iwish we could do all these

(19:29):
crazy things and it's like, well, these are crazy things, but
you've already built a tool.
That's like well, now we kindof see how we can get there, and
that's so cool.
Is it a mental model?
Do you have just a giantwhiteboard?
How do you go from really big,ambitious problem to, okay, what
is the smallest step that Ineed to take to make this happen

(19:50):
?
What goes on in your brain?

Speaker 2 (19:53):
Most of it was from working on Simulus Reflex, so
I've been maintaining thatlibrary with some friends over
the past few years and, workingon that, I was already kind of
thinking about this.
I was wishing to have somethinglike this to make it easier for
me to work with and make itwork and having this problem

(20:13):
there and then also trying tocontribute to Turbo and making
Turbo Rails kind of a nice thingto work with and then also
hitting limits there of what wecan do and what is possible, and
then kind of feeding back intowhat we were talking about
earlier with the tooling, withthe LSPs, with the linters that
we don't really have.
I was like, yeah, maybe it'sjust time to go all the way back

(20:35):
time to lowest level I canthink of and just try to reroll
this whole thing from the groundup, and the first thing that
you need to have a parser toknow what you're working with.
And I was like, yeah, this issuper ambitious and I don't know
how I want to do this.
I was talking about this ideain previous talks too, that it

(20:56):
would be cool to have this and Ihave been trying to make it
work with some less ambitioushacks to make it work and it
works good enough for most cases.
But then if you need to havethis extra detail or this extra
context, it's not able todeliver that.
And that's where I was likemaybe you have to just do it

(21:18):
right for once and do it prettymuch all in on that and make it
right.
And this is also largelyinspired by the whole
architecture of Prism itself.
So it is using Prism under thehood to parse the Ruby code in
your view files, but the designis also largely inspired by
Prism itself.
And yeah, like as I was workingon the parser and then also

(21:43):
slowly the linter and theformatter, I was like what if we
just also look at renderingHTML ERP and kind of try to
improve what's possible there?
Because we have all these toolsnow we know exactly what is
going on, what you're trying todo, so maybe we have a better
foundation now to also improvewhat's possible with the current

(22:05):
view layer.
And it was mostly like, yeah,this is too much, this is too
ambitious.
I don't want to kind of committo that.
But having worked on this andhaving prototyped a little bit
of how this could look like, Iwas like, yeah, I think that is
feasible and viable, at least tomake it into a prototype to
kind of show this is what'spossible.

(22:27):
I am not super sold on the wholeimplementation now that we have
to figure out how you storestates.
How do you persist statebetween requests?
How do you think about browsersessions, browser windows, like,
do you share that state?
Do you kind of have it isolated?
That's like all details thatthey have to figure out which

(22:48):
are super tricky to figure outtoo.
But at least that's more highlevel than right.
It's not to the super low levelthat you have to think about
how you do your parseless file,because that is now a somewhat
solved problem.
So I think it is quiteinteresting to go pretty much
from doing front-end work in thebrowser working on Stimulus and
Turbo and all of these toolspretty much to the whole

(23:11):
opposite side of the spectrum,to go super deep into parsers
and doing C work, differentchallenges and these super
tricky things to work on.
And it is just super excitingand also fulfilling because I
get to solve the problems I havebeen having for the longest

(23:31):
time in Rails myself.
So it's fun to work on theseproblem space.

Speaker 1 (23:36):
Yeah, and it makes you a really popular guy too,
because you're solving the sameproblems for a lot of us.
I don't think those problemsare really unique to you, or at
least from the people I'vetalked to.
The work you do tends to comeup in conversation whenever
there's conversation about thefront end side of Rails.
So I think the work you'redoing I'm glad to hear that it's

(23:58):
solving your problems, but alsothank you for solving mine so
you're doing a lot of amazingwork.
You've kind of set yourself apretty awesome and ambitious
roadmap and, in addition toalready having this work done
you already mentioned this isn'tyour day job.
This is essentially a sideproject, but you also have a

(24:20):
pretty speaking of ambitious.
You have a pretty ambitiousspeaking schedule.
You just spoke at RailsConf.
You mentioned speaking atYoroku during your RailsConf
talk.
What other conferences are yougoing to be speaking at in the
near future?

Speaker 2 (24:37):
Yeah, it's been quite the ride to being able to speak
at all these conferences andI've been enjoying traveling and
speaking at them and sharing mywork that I've been working on
in these conference talks,because it's also a big
motivation for me to get thingsdone.
And I guess you could call thistalk-driven development, TDD, I

(24:59):
don't know or conference-drivendevelopment, it is.
You have like a deadline andyou want to deliver something by
that date, so you have to getsomething done.
And it is quite motivating toget something done for a
conference and then being ableto share it and share it for the
first time and have it kind ofbe exclusive for the conference

(25:19):
to say this is now available,this is now released, A thing
you can actually install andhave in your hands and you
didn't know about it before.
And it just gives this nicefeeling of attending a talk in
person and saying, yeah, now youhave this thing that you can
use in your day-to-day work.
And that's been reallyrewarding in a sense too, to get

(25:40):
all the feedback and theexcitement from the people that
are at these events and that'skind of feeding back into the
whole cycle of making this workfor myself but also work for the
community in general.
But to kind of come back to whatis up next is I get to speak at
Railsworld now too.
I got asked to replace Xavier.

(26:01):
He cannot make his keynotespots this year, so he was
asking if I can step in for him.
And I was like I have this talkscheduled for Yoruku, but I
don't really have this ready yet.
But maybe I can make it workfor Railsworld.
So we kind of were able toarrange something and now Joe is

(26:22):
doing the keynote for him,that's replacing him, but I get
to have his spot, Joe's spot inthe schedule and I.
That's awesome, yeah, it'sexciting.
Yeah, it's exciting becauseagain, it's the big stage.
So I'm looking forward tohaving that.
And then we are doing theFriatland this year too, which
is the free conferences,back-to-back in three weeks.

(26:43):
So we are doing Railsworld,FriendlyRP in Romania and then
Yuruko in Portugal.
So in Romania and then Yurukoin Portugal.
So we're doing back-to-backconferences and I get to speak
at both ResVolt and Yuruko andthat's going to be a lot of fun.

Speaker 1 (26:59):
I guess my next question has to be like how?
How do you find time to do allthis traveling, all this
speaking?
This is a side project.
This awesome set of toolingthat this speaking, this is a
side project.
This awesome set of toolingthat you've already created is a
side project In addition toyour day job.
I feel like I struggle just tomanage my day job and

(27:21):
occasionally speaking at one ortwo conferences a quarter.
Is there a trick?
Do you have a magic potion thatslows down time or makes you
really good?
Do you have just an amazingplanner journal that you're just
like today I'm going to work onX and then you exit?
How do you do it?

Speaker 2 (27:40):
Yeah, it's a good question and I somehow asked
myself somehow how this is allpossible and doable, because I
was like, yeah, I don't know howthis works.
I don't know myself.
I think it's mostly hype that Ihave for these tools myself, so
it doesn't really feel like Iam working on these things.
But I was kind of lucky enoughto not have to work like a full,

(28:02):
full-time job.
So I'm doing consulting work forclients, I help clients, do
projects with Hotwire, and Ihave had a lot of clients that
are super flexible with mecoming and going.
So I kind of work in phaseswhere I focus a month or two on
doing just client work and thencoming back to open source, and

(28:24):
that allows me to do both at thesame time.
So I'm working for like two,three months and then not
working for two, three months ona client work at all, and that
kind of balances it out in theend.
And having that kind of mixalso gives me the immediate
feedback to bring these toolsback to my clients to say I have
built this, now Can we see ifit works for your case too, or

(28:47):
kind of just validate the ideaor like the whole project.
And that's been super nice tokind of have this feedback cycle
as I'm working through forthese ideas.

Speaker 1 (28:58):
Yeah, that's like when you're dogfooding the app
that you're working on, likeyou're going to use the app
you're working on, you'rebuilding tools and you get to
use the tools you're building atyour.
I don't want to call it a dayjob because it's like a month
job.

Speaker 2 (29:15):
But yeah, it wouldn't be possible if I wouldn't have
these awesome clients that Iwork with that are so flexible
for me coming and going and yeah, otherwise it wouldn't really
be possible.

Speaker 1 (29:25):
Yeah, unless you went to somewhere like Shopify where
they're like oh, you're on theteam that does nothing but
developer tooling for Rails andRuby, and even then you might
not get to work on the thing youwant to work on, Right, yeah.
So yeah, definitely a coolsetup.
But, yeah, you get around.
Sir, you are all over the placewith the talking and the

(29:47):
attending conferences, but it isalways super cool to see the
work that you're doing.
One thing that probably doesn'talways come out in your talks
when you're talking aboutsomething that you've built or
are hoping to build is what kindof blockers you run into.
I think a lot of us I'massuming listeners feel free to

(30:08):
text me and let me know if I'mwrong but I'm assuming most
people listening to this doapplication development, where
we get to use your tools, butwe're not building tools
ourselves.
What kind of blockers do yourun into when you're building a
tool versus building anapplication, and do you think
the problem solving there forblockers is the same or pretty

(30:31):
different depending on whatworld you're in?

Speaker 2 (30:35):
Yeah, I think it is quite similar, at least from the
problem solving, I guess,approach or the steps you go
through debugging a problem.
One thing that's been reallynice working in like library,
more abstract level codes isthat you have test cases.
In my example it has now beenparsing and formatting and

(30:55):
linking test cases and they areso fast to execute.
There's no system tests, noslow tests to kind of wait on
and see what you're changing isactually not working the way you
expect it to.
But with these like low-leveltests, you save the file and you
can keep them running in thebackgrounds and it runs your
whole test suite in millisecondsand it's really so impactful to

(31:19):
work that in a way it's reallyproductive to iterate and see if
stuff is working.
If you take the time to definethese test cases up front which
is something you can reallyeasily do with a parser or a
linter to say I expect to havean error here, I expect to have
a offense here, or I give theformat of this input and expect

(31:41):
this exact output, and as longas it's not exactly the same,
you know stuff isn't working theway expected to.
So it's really kind of nice tohave this instant feedback cycle
, which you don't really get inapplication development usually.
But I guess one thing I've beenkind of struggling to get right
in Herb in the last few weeksis parsing the ActionView tag

(32:03):
helpers.
So in Rails or in ActionView Iguess you can say that you have
different ways of expressing orwriting HTML.
You can have the raw HTML inyour view files, but if you are
interpolating a lot you kind oftend to also use tag to div
content tag.
You use form helpers, you useinput helpers, you use all these

(32:24):
different kind of helpers whicheventually evaluate back to
HTML when they are rendered out.
And since the idea of Herb isto give you more feedback about
your view files, we want to kindof understand what these tag
helpers are going to output inthe end.
So when you write tag to div weknow, at least at static

(32:46):
analysis time, that this isgoing to be a tag with div and
it's going to have theseattributes.
Some of them might be kind ofvariable dynamics that we cannot
really figure out at parse time, but most of the stuff we can
actually evaluate and kind offigure out what it's going to
render out as.
And now that Herb is kind oftrying to improve the tooling

(33:07):
and kind of give you feedbackfor also your ERP helpers.
We want to understand whatthese tag helpers mean exactly,
so we want to parse these aswell and kind of translate them
back into HTML.
So when you parse a Vue fileyou as a tooling developer just
see the HTML as if it would bewritten as HTML instead of the

(33:28):
ERP that you have in your actualfile.
So trying to kind of make thatwork, to parse the Ruby inside
your ERP tags and then mappingthis to an equivalent HTML
representation of that, has beenquite tricky.
I have a working version for afew tag helpers.

(33:50):
But having to figure out wherethese attributes are, where they
are located, how a hash in yourtag helper like if you have
data and then you have give thiswhole data attribute a hash, so
you have data controller, forexample, which are the
controller is the key inside ofthis data hash.

(34:12):
But this is going to evaluateback to a data dash controller
attribute in your renderedoutput.
But if we just parse this asRuby we don't see this exactly
and where is the whole name?
Like we in the parser want tomap this back to a location in
your view file.
So we want to know thisposition in this document.

(34:34):
This is where this attributename is.
But in the case of a Ruby hash,we have to make it work to know.
Okay, this is the data parthere, this is the controller
part here, and we put thistogether and dasherize it and
then we have the attribute name.
So, kind of just coming up withhow to map all these helpers
back to HTML so we can writethese lintels and formattles

(34:56):
more efficiently has been quitetricky.
But once this works out it'sgoing to be quite effective for
parsing these files.

Speaker 1 (35:06):
That is an interesting bit of a blocker,
because I guess when I wasthinking about Herb, I was
thinking about oh, like,everything inside of an ERB tag
gets handled as Ruby, and thenyou just look at the HTML side
of things and you create an A.
But because we can write Rubythat writes HTML, you have an

(35:26):
entire extra step that I wasn'teven thinking about.
So we should all just stopdoing.
That is what.

Speaker 2 (35:33):
No, I think you should.
That's the thing.
I think you can improve yourview code if you use these tag
helpers.
It doesn't make sense in allcases, but in a lot of cases it
might make sense.

Speaker 1 (35:44):
I run into that a fair amount where I'm putting a
lot of interpolation into.
I have a div and then likeclass equals and then I'm using
the ERB tags there and also ERBtags for the ID, and then I've
got this long list of data andI'm like this should just be the
tagdiv helper.
That would make this so mucheasier to read.

(36:04):
So I am one of your pain in thebutts who writes a lot of tag
helper stuff.
I do it myself too.

Speaker 2 (36:10):
I do it myself too, yeah, but the thing is that we
had formatters in the past andwe had linters in the past, but
none of them were reallytackling this kind of problem
before.
And that's the kind of a blindspot in these tools now.
So you can validate the HTMLstuff but you can't really
validate what these tag helpersare going to output in the end.

(36:32):
And if you write lint rules forexample, if you say all your
image tags should have an altattribute to describe the image
and you use image tag with theimage path helper to render out
your image tags, you don't getto validate these helpers with
these rules.
So you cannot really enforcethat.

(36:52):
This rule is kind of satisfiedand your code complies with that
.
So we have to map this back tosay, okay, when you see an image
tag helper, it's going tooutput an image, an img tag in
your HTML, and all the argumentsyou pass through, the keyword
arguments, are going to beattributes in your HTML.

(37:13):
So if we map this back, thelinter can see that this is just
going to be an image tag and ithas these and these attributes.
So the linter rules don't evenhave to care about if it's
written in actual HTML or ifit's written in this ERB syntax
where we use the Ruby helper togenerate this HTML for you.
So our inter-rules get supersmart and they also will just

(37:37):
work on these image tag helpersor these view helpers in general
that we have in Rails andthat's going to unlock so many
possibilities and ways to catcherrors and accessibility
concerns too, where we can nowensure that all these variations
of how you write your HTML arecovered by OWLint now, and

(37:57):
that's something that's reallypowerful, I think, for tooling
in general.
So you write this out and inthe editor you see right away
something is wrong about thisand you can immediately fix that
.
The other thing where this isgoing to be super useful is for
also lint rules again.
So if you are writing HTML, youwrite out your raw HTML and we

(38:17):
kind of see that you areinterpolating in each attribute.
We might be able to recommendto you and say you might rewrite
this as a hack helper nowbecause you are using all this
interpolation here.
So it might just be easier foryou to just use this Hack Helper
but you don't have tointerpolate at all.
So we can rewrite or have aautocorrect feature where we
rewrite all these instances to aView Helper or the other way

(38:43):
around, where we say we see thisView Helper here we can say
refactor, right-click on it andsay map it back to actual HTML.
So it can go both ways.
And these kind of refactoringtools is what we don't have at
all nowadays.
So it would be just really niceto be able to have no friction
from converting one format tothe other and have these tools

(39:05):
and linter rules and formattersjust be compatible and
interchangeable.
And that's what this is goingto enable, if you are able to
map these tag helpers back toregular HTML.

Speaker 1 (39:17):
I wonder also one part that ActionView struggles
with is really the only time weget to test our views.
If it's not a view componentSort of a system test, I guess
you could write a controllertest and then look at maybe.
But do you think that the workyou're doing with Herb that

(39:38):
allows you to do this parsingwould potentially make it easier
to test things like partials orviews?

Speaker 2 (39:47):
I think there is something to it and I haven't
really figured out or thoughtabout too much how this could
look like.
But I think that we also couldimprove the testing story.
Or at least we can hint youearly that something is not
right about your partial.
To say, if you use an instancevariable in your partial, you
shouldn't be doing that.
You should be using localvariables and try to pass them

(40:08):
as local variables into yourpartial.
Using local variables and tryto pass them as local variables
into your partial.
That's something we can catchnow with a linter rule.
To say, if you see an instancevariable, flag it and then you
have to fix it and otherwiselinter wouldn't pass Right.
Right, or use the strict localsfrom the new Rails 7.1, where

(40:28):
you say please use that instead,and that's how we as a
community can guide people towrite better view files as a
result.

Speaker 1 (40:35):
I like the new strict locals.
They were a little weird whenthey first came out.
When I first read the PR thatintroduced them, I'm like, okay,
I get it.
And then I've actually usedthem a few times I was like, oh,
this is awesome.
This is essentially just a verysimple comment that gives me
better feedback, especially sixmonths down the line when I'm

(40:55):
like I don't remember what I wassupposed to be doing in this
partial or I have a bigconditional and I'm like, do I
actually need to pass this here?
What happens if I don't?
That kind of stuff really doeshelp when you've got that.
Essentially what Herb is doingfor us.
It's tightening the feedbackloop.
It just makes everything thatmuch easier.

(41:16):
I don't have to wait until I goand render the view and I get
that error message.
As I'm writing it, herb istelling me like, hey, you're
screwing up, maybe don't do that, which I appreciate greatly.
It was sort of like when Prismfirst happened.
Things just got better.
Instead of it blowing up andbeing like there's a problem in
this file, have fun, find it.
We got an error-tolerant parserand now it was able to say
there's an error here, go fix it, which makes life better.

Speaker 2 (41:42):
So yeah, I guess that's not a direct answer to
your question where we have notbetter testing tools necessarily
, but I think we can write moretools around it to kind of
rescue you from actually writingthese bad view files in the
first place.
And the same is going to be truefor, like, render calls in your
partials or in your view files.
So if you can go and analyzethese render calls and see what

(42:06):
you're rendering and what you'repassing into them and then
maybe give you a warning that'shey, your call to render doesn't
match the signature you kind ofprovided in the strict locals,
right, so you can kind of givefeedback how this is going to
map to each other.
Or you're rendering a view herewhich we don't know about.
We cannot see that this viewexisted on your file system.

(42:28):
Create it for me, so you cankind of analyze all your render
calls and all your views andpartials and kind of build up a
tree of what is rendering what,and then maybe also find unused
partials or unused view files orall of the kind of tooling that
we haven't even been thinkingabout because we didn't have the
foundation to, yeah, buildthese tools now.
So this should be enabling alot of static analysis, which we

(42:51):
haven't been able to do before.

Speaker 1 (42:53):
It is super awesome, which makes the next question
really difficult for you,because the next question is
what is something cool, new orinteresting you want to share?
And I feel like the Herb toolor tooling or tool chain would
be a perfect cool, new andinteresting thing for you to
talk about, but you alreadytalked about it, so you have to

(43:15):
come up with somethingcompletely new.
For what is something cool, newor interesting that you've
recently learned or discoveredor built that you want to share?

Speaker 2 (43:25):
Yes, I was going to say that I was kind of planning
on talking about Reaction Viewat this point.
So there you go, because we kindof did that earlier.
But yeah, just being able towork and learn new languages and
tools has been super rewarding.
I think that having a sideproject you can have work on and

(43:47):
learn and try out new things issuper important for us as
engineers.
And it doesn't have to be asambitious as I guess Herb is,
but just kind of dabbling withstuff you wouldn't be doing in
your regular day job is so niceto level up, and I would say
that I have learned most of thethings in the past few years

(44:08):
thanks to open source.
I wouldn't have done any ofthat if it wouldn't be for open
source or for any of thelibraries I've been working on.
And I know it's quite hard toget into open source if you
don't know where to start, howto kind of tackle these issues
and where to find even issues towork on.
But yeah, so that's just what Iwanted to say here.

(44:28):
So if you are out there and arelooking to kind of want to help
out with open source, pleasereach out.
I will be happy to work youinto one of these projects that
I am working on to help you getstarted, or even something about
the other project I've beenworking on, which is Ruby Events
.
It has a lot of easy things tokind of work on there too.

(44:50):
Most of them aren't even likeRuby related, they're just data
issues.
So if that's something you kindof want to just have a first
step into open source thenplease reach out and I'm happy
to help you get started withthat.

Speaker 1 (45:05):
Yeah, I'm glad you brought up Ruby events because
if you didn't, I was going to.
You also run Ruby events, whichis a drastically different side
project than the side projectwe've been talking about, Herb.
This is much more applicationstyle.
For anybody who isn't familiarwith Ruby Events, can you give a
high-level overview of what thesite is and does?

Speaker 2 (45:27):
Ruby Events is, in the most basic form, a
collection of Ruby talks andRuby events, as the name implies
.
So if you have been missing anyof the talks at a conference in
the past, you will probablyfind them on Ruby events and you
can find all the recordings,information about speakers,
information about the sessions,information about old events

(45:50):
that happened years ago, and itjust allows you to see what has
been happening in the Rubycommunity.
I have been using Ruby eventsas preparation for my talks to
figure out what has been done inthe past.
So we categorize most of thetalks using AI to kind of tag
them into topics and you cansearch for them or kind of go on

(46:11):
a specific topic and see whattalks are on that topic.
So it gives you an easy way tobrowse what the Ruby community
has been talking about andsharing in the last 20 years.
So we have over 7,000 talks nowand over 3,000 speakers, and
it's a super rich resource foranything Ruby events related.

Speaker 1 (46:33):
Yeah, that's a lot of talks and a lot of speakers.
That's a lot of content.
Now, the one thing that I atleast noticed selfishly from my
own page that I actually like Ilike this a lot, but I did
notice it is if there's norecording, like I've spoken a
few times, three times now, atSin City Ruby, and those talks
are not recorded, but it stillgets listed under my speaker

(46:56):
profile as a talk that I gaveeven though there's no video,
which I think is awesome.
Whose idea was that?
Because I think that's great.

Speaker 2 (47:05):
Yeah, so I know that people have been giving talks
and I know that they have sharedsomething in a talk and it
hasn't been published.
But just being able to knowthat this talk exists and
actually happened it's not justme making up something, it's so
valuable.
So just allowing the speakersto have it indexed there and
have them share the slides ormaybe some other resources to

(47:27):
the blog posts or some of thereposts is really valuable.
So that's why I want to justfocus on also adding all these
conferences that don't haverecordings maybe not yet or not
at all to still be kind ofvisible on the platform so you
can discover and see what hasbeen talked about in the past.

Speaker 1 (47:46):
So at Ruby events, people can go and look at videos
of past events.
So they can go.
They can look and look atvideos of past events.
So they can go.
They can look at events thatare coming up, events that have
happened.
They can see the videos.
They can look up specificspeakers, specific topics and
you also list out any open callfor papers.
Is that all pretty manuallyupdated stuff or is it fairly

(48:10):
automated at this point whereyou have good ways of getting
that information in and it doesits own thing?
Or do you have people thatsubmit PRs to add?
Or do you just stay on top offreaking everything and update
as needed, which wouldn'tsurprise me given your tendency
to be like oh I've got a littlebit of free time, let me go

(48:31):
build a new view layer parser orkeep yourself insanely busy,
but I'm hoping it's slightlymore automated than that.
I wish.

Speaker 2 (48:41):
Yeah, it's mostly all manual at this point still,
sadly.
The reason being is that wehave such rich metadata about
all the talks and all the events.
It's quite tricky to even findthis information on the website
of the conference itself.
Sometimes conferences actuallylist out the talks, sometimes
they don't.
Sometimes they use athird-party platform, sometimes

(49:04):
it's JavaScript-based, so youcan't really easily grab
information out of it.
So we have been looking at waysto automate most of it or some
of it.
So we have been looking at waysto automate most of it, or some
of it at least, but it's beenquite tricky to make this
reliable and not hallucinateover things.

Speaker 1 (49:23):
Yes, the age-old AI issue of.
Let's just make sure it doesn'thallucinate by not using it.
I like that.

Speaker 2 (49:31):
Yeah, the funny thing was that I was kind of most
impressed by the AI was that itmade up new YouTube IDs.
So, like you know how, theYouTube URL has like an ID in it
and it was just going throughexisting talks and kind of
trying to enrich them withmetadata and then some of them
just try to change the YouTubeID to something else because

(49:52):
they are random, right.
So it would just go and make upnew YouTube IDs which wouldn't
actually exist.
So it is even more worked intoverify all these IDs all are
actually legit, are they?
Do they exist?
Are they the right ones?
Just because I don't have thatmuch time to focus on working
and making AI work, I just havebeen doing this mostly manually

(50:12):
Okay, but AI gets also better.
So we have been looking to waysto make this now work with
active agents and similar toolsto go through.
Give it some context.
Have it actually use a browserto browse these pages and then
try to extract this information.

Speaker 1 (50:30):
I really appreciate the site in general, just like
one place to find Ruby eventsthat are coming up, find talks
that have happened.
Youtube's usually decent fortracking down a playlist as long
as Comfreaks was the one, it'snot too bad, but it is nice to
have them a little bit bettercategorized.

(50:50):
I'm not as stuck in YouTube'sUI of like, if you're not in a
playlist, who knows what's goingto play next?
And I might be looking for aspecific speaker or what have
you.

Speaker 2 (51:04):
So we have some tools actually to automate it from
YouTube playlists.
So if there's a YouTubeplaylist on YouTube, we can
import them and we have it quiteeasily imported as an event on
reviewments.
So if there are videos already,it is super straightforward to
import them.

Speaker 1 (51:20):
I will give you a feature request, live on the air
.
You need a leaderboard.
You need, like a speakerleaderboard to see who has given
the most talks, because Ithought for sure it would be
Matt's, but just at first glanceMatt's has 75 talks and Aaron
Patterson has 89.
So I don't know if anyone beats89, but I feel like it would be

(51:42):
better to have a leaderboardwhere I can just go and see that
information.
So in your infinite free time,if you wouldn't mind
implementing that, that'd begreat I mean it's lucky for me
because it already exists.
So does it where?
Where, show me it's on rupeeeventsorg leaderboard oh, you
just don't have a link up at thetop.

(52:03):
You are sneaky.

Speaker 2 (52:05):
Yeah, it isn't a drop down oh, my god, there it is.

Speaker 1 (52:08):
Yes, okay, no one has beaten Mr Aaron Patterson 89
talks, 74 formats, 200 of themhave actually talks attached to
them, so like over 300 eventsthat don't have any talks

(52:36):
attached to them, so there areprobably even more Aaron
Patterson talks.
That is a safe assumption thatthere are more Aaron Patterson
talks out there than youprobably know about.
How can people, if they want tohelp improve Ruby events, what
are some of the ways that theycan contribute?

(53:00):
Like, if you said there'sprobably missing events and they
find them, say, or they find avideo that isn't tied to a
YouTube playlist, is there aneasy way for them to submit that
, or is it just as simple asgoing to the GitHub repo and
open a PR?
How does people contribute?

Speaker 2 (53:15):
Yeah, the easiest way is to just open pull requests.
We have a data folder on thetop level of the Rails app and
it is a bunch of YAML fileswhich just have the definitions
of these talks.
So there's a quite simpleformat, quite straightforward.
You just have to go and addthem one-to-one and then,
whenever we deploy the next time, they're going to be added to

(53:37):
the website.
Nice, we do have a page on slashcontributions where we show all
the ways you can help out withdata.
Some of them include addingGitHub panels to speakers or
adding dates to events where wedon't know when it actually
happened, like the actualconference dates or the location

(53:59):
where the event happens.
We don't have that for all thelocation events too.
So they're like easy ways tomake it an impactful
contribution just going throughand seeing which of these events
don't have any of them, and wekind of list them out to kind of
give you a nice overview ofwhat's missing or what we know
is missing.
There's probably more missingthan we know of, but at least
what we know is on thisdashboard.

Speaker 1 (54:20):
So you have a GitHub repo.
I'll include these links in theshow notes for people to more
easily get to them.
But you have a repo for Rubyevents.
You have a repo for Herb.
I'll include links to yourGitHub links to socials.
What are you most active on?

Speaker 2 (54:39):
I have been cross-posting to all social
media platforms.
So if you just go to my website, which is marcorufdev, you see
all the socials in the bottom ofthe page.

Speaker 1 (54:51):
So found on all socials, fabulous.
Is there anything else beforewe wrap this up, is there
anything else you wanted to talkabout that we haven't already
mentioned or gone down thatrabbit hole for?

Speaker 2 (55:04):
I don't think so.
I think that's mostly it.

Speaker 1 (55:07):
We certainly covered a lot, but I know that you also
have just a lot going on, so incase we missed anything, unless
you want to jump back to someherb stuff.
I mean sure, what do you got?
What are you thinking about?
What's on the top of your head?

Speaker 2 (55:20):
Most recently it's been the formatter that I have
been working on to improve theoutputs.
So the formatter itself as itis right now is mostly like an
early preview, where we noticesome stuff's still broken and
some stuff is going to be overformatted.
But I have been adding a lot offixes to make it more reliable
and more consistent.

(55:41):
So when you format a Vue filein your editor or using the CLI,
it produces a good resultalready.
And one of the nice things Ihave been working on this week
is adding Tailwind class sortingto the Format2.
So Tailwind has an officialrecommended way of how you

(56:02):
should be sorting your Tailwindclasses and it's been the
default in JavaScriptapplications that you can just
save your file and it willauto-format and auto sort these
classes for you.
And given that we have thisformat now written in TypeScript
, we can use this plugin too andmake it plug into the Herb

(56:24):
formatter.
So whenever you kind of savewith the Herb format and you
have the setting enabled, itwill also go and format your
tailwind classes and you can nowwrite your own rewriters and
your own rules how you wantstuff to be rewritten as the
formatter is formatting the file.
So if you have any custom rulesthat you have in your company

(56:46):
or in your code base or for yourframework.
You can now write some of theseform or rewrite them and have
them part of the formatting flow.

Speaker 1 (56:55):
I didn't know that Tailwind actually had a
recommendation for the orderingof their classes.
I guess that makes sense forsomething that's so
utility-first to help betterorganize.
Is that one of those placeswhere it's like, hey, we can do
it if you're writing raw HTML,but if you're writing raw html
but if you're writing using atag helper, maybe it doesn't

(57:16):
work there yet.
Or is that something thatprobably will work in both
places?

Speaker 2 (57:22):
there is like ways to format html or like have it
format in html with the alreadyexisting plugin they have, but
it wouldn wouldn't thenauto-format the ERB the right
way because it has no knowledgeabout it being an ERB
interpolation right there.
So if you're interpolating inyour class attribute, it would
know that this is ERB and itwould kind of scramble up all

(57:44):
your classes and your ifconditions and the else's and so
on.
So you have to kind of guide itto say this is ERB, we're going
to handle this, but these areclasses.
You can format those.
And once we have the taghelpers the actual tag helpers
mapping also in place, we canalso run them as part of the
rewriting of the tag helpers.

(58:05):
And then you can have it alsoauto-format or auto-sort the
classes in the ERB helpers,which is going to be, I guess,
really cool if that works out.

Speaker 1 (58:15):
There's so many cool things that you can do on the
Vue side of things to make lifeso much easier.
I'm sure, given that you work alittle bit more on the front
end than some of us do, you knowof them all, which is how you
come up with your roadmap.
But it is cool to see some ofthese tools making their way to
the Rails ecosystem, where Ruby,being so focused on developer

(58:40):
happiness, it would make sensefor us to get developer
happiness tooling for our Rubyand, in this case, rails
applications, which actuallybegs the question have you
thought about Herb fornon-ActionView Ruby applications
, like maybe Hanami orBridgetown or something else

(59:02):
where it's Ruby probably usesERB templates, but isn't
ActionView?

Speaker 2 (59:10):
I mean, the good thing is that ERB the parsing as
it is right now is quiteuniversal, so it should work on
these view files too.
Maybe we can have options toenable or disable the ActionView
helper parsing, for if it'sgoing to be parsed in the Hanami
app or if it's going to beparsed in a Bridgetown app where
we don't have them available,so that you can pass it options

(59:32):
to say, please enable thisanalyzer or this kind of
transformation or have it alittle bit more dynamic.
But since we don't really havethe ActionView tag helpers
anyway right now, it should beworking for all of these as it
is today.
So it works fine on everythingfor now, until the next feature
release, and then maybe I wantto make this work for any HTML

(59:54):
EPU file that you can think of,if it is in Rails or not.
So I'm also looking in ways tomake reaction view work in
Hanami apps, if that's possibleand something that community
wants to have too.
So if it's going to be viablewhich I'm not sure it is at this
point, but if we are goingthere and's going to be viable
which I'm not sure it is at thispoint, but if we are going
there and are going to explorewhat is possible, I also want to

(01:00:15):
include Hanami or maybe evensimpler Sinatra or other apps
that are not Rails.

Speaker 1 (01:00:22):
That'd be superb.
I'm sure there's lots of peopleout there that would benefit
greatly from the tooling acrossthe Ruby ecosystem, not just
Rails.
But as a Rails dev myself, Igreatly appreciate the tooling
across the Ruby ecosystem, notjust Rails, but as a Rails dev
myself, I greatly appreciate thetooling regardless.

Speaker 2 (01:00:37):
Yeah, and the same is true for the linter.
We have custom linter rules nowthat are specifically built for
Action View, which wouldn'tmake sense in other contexts.
So also for those, you wouldkind of scope them the right way
or have them enabled ordisabled for how we're going to
use them in your app.

Speaker 1 (01:00:55):
Well, you have lots on your plate speaking at
multiple conferences, going tomultiple conferences, this whole
Herb ecosystem and Ruby eventsso I don't want to take up too
much more of your time becauseyour time sounds pretty
stretched thin as it is.
We've already talked a littlebit about how people find you.
I will include those in theshow notes so that people can

(01:01:18):
find you and hopefullycontribute and help out or reach
out to you if they want to getstarted on open source or
developer tooling, since you arethe guy.
Thanks so much for joining theshow and getting this recording.
It's been a little bit tryingto get you on, but I'm glad that
it finally happened.
And as the Herb project evolvesand all of your other projects,

(01:01:41):
feel free to hit me up nexttime you want to have a chat
about whatever you're working onand get it out until they open.
I'd love to have you back on.
Yeah, thank you so much forhaving me Listeners.
We will see you in the next one.
Bye.