Search
RubyKaigi 2025
Empowering Developers with HTML-Aware ERB Tooling
Edit
#html
#hotwire
#developer-tooling
#language-server-protocol-lsp
#ruby
#stimulus-js
Summarized using AI

Empowering Developers with HTML-Aware ERB Tooling

Marco Roth • April 16, 2025 • Matsuyama, Ehime, Japan • Talk

In his presentation titled "Empowering Developers with HTML-Aware ERB Tooling" at RubyKaigi 2025, Marco Roth discusses the evolution and future of ERB (Embedded Ruby) tooling amidst the rising demands of modern web development. He focuses on enhancing developer tools in the Ruby ecosystem, particularly with the integration of HTML-aware ERB parsing tools, thereby improving how developers create and manage HTML within their Ruby applications.

Key Points Discussed:
- Background and Motivation: Marco shares his experience with Ruby and contributing to the open-source community, especially within the Hotwire ecosystem (Stimulus, Turbo). He highlights a significant gap in advanced ERB tooling compared to JavaScript, noting the necessity to adapt tooling for modern development needs.

  • History of Ruby Developer Tooling: He outlines the historical lack of comprehensive tooling for Ruby developers, noting how advancements started with RubyMine in 2008 and progressed to include Language Server Protocol (LSP) integrations in 2016 with tools like Soloraph and Shopify Ruby LSP.

  • The Need for HTML-aware ERB Tooling: Recognizing that typical ERB tooling lacked support for dynamic ERB elements, Marco stresses the importance of having tooling that understands HTML alongside Ruby syntax to enhance productivity in web development using frameworks such as Ruby on Rails.

  • Introduction of Herb Parser: Marco introduces a new parser called Herb, designed to efficiently parse ERB files. This custom parser is implemented in C, allowing for seamless integration with Ruby and JavaScript environments without dependencies. Herb features three main components: a parser, formatter, and linter, which collectively improve development workflows for ERB.

    • Parser: The parser generates a clean syntax tree representing the ERB document, addressing issues related to context loss when combining Ruby and HTML.
    • Formatter and Linter: Future developments will include a formatter to beautify ERB code similar to tools like Prettier, and a linter that checks for HTML validity, which integrates with existing Ruby tools like RuboCop.

  • Vision for Future Tools: Marco expresses aspirations to enhance the ERB rendering engine to enable smarter updates in applications, drawing parallels to Fenix LiveView, and to potentially harmonize tooling across different templating engines (HAML, Slim) by sharing the underlying syntax tree.

Conclusion and Future Directions:
Marco concludes by emphasizing the community's role in advancing HTML and ERB tooling. He invites developers to collaborate and contribute ideas, reiterating the goal of providing robust tools to modernize the Ruby front-end development experience. Marco's enthusiasm for innovative development within Ruby showcases a proactive approach to keeping the language relevant and attractive for future developers.

Empowering Developers with HTML-Aware ERB Tooling
Marco Roth • Matsuyama, Ehime, Japan • Talk

Date: April 16, 2025
Published: May 27, 2025
Announced: unknown

ERB tooling has lagged behind modern web development needs, especially with the rise of Hotwire and HTML-over-the-wire. Discover a new HTML-aware ERB parser that unlocks advanced developer tools like formatters, linters, and LSP integrations, enhancing how we build and ship HTML in our Ruby applications.

https://rubykaigi.org/2025/presentations/marcoroth.html

RubyKaigi 2025

00:00:07.919 nice to meet you my name is Marco and I'm here today to talk about HTMLware
00:00:13.679 ERB tooling if you haven't met I would love to say uh hi after the talk and meet you
00:00:21.359 um I have been doing a lot of open source the last few years and you can say I love open source i've been doing a
00:00:28.080 lot of open source things and most prominently I was part of the core team
00:00:33.600 for stimulus reflex and cable ready and I've been maintaining stimulus over the last few years as well most of my open
00:00:40.320 source contributions were in the hotwire ecosystem and mostly around hotwire
00:00:45.760 stimulus turbo and all of that and over the years I started to get more like
00:00:52.399 interested into improving the developer tooling in the rails and hotwire
00:00:57.800 ecosystem that's why I'm here today to talk about hotwire or hotwire and hmlb
00:01:04.680 tooling and something has been really kind of holding us back a little bit so that's why I think I want to address
00:01:10.880 some of the things here today of how we can improve the way we work in our HTML
00:01:16.080 and ERB views and apps but first I want to talk a little bit about the history
00:01:21.119 of Ruby developer tooling it's true that for most of the time that Ruby existed there was no
00:01:28.000 really tools a lot of tools around for the editor especially in the way we know
00:01:33.439 it today most editors just had basic support for Ruby so there wasn't really anything
00:01:40.159 fancy like LSP and autocompletes it's just the way you were used to and how it wasn't back in the day this kind of
00:01:47.759 changed in 2008 when Ruby Mine was announced for the first time where we got some more advanced features on
00:01:53.280 autocomplete and indexing and just the way you can write and work with Ruby
00:01:59.119 so it was typical back then that every editor that was introducing Ruby support had to write some integration to make
00:02:05.040 Ruby work in their editor and that's been mostly the situation for almost a decade up until
00:02:12.000 2016 when Microsoft introduced the language server protocol
00:02:17.120 the idea of the language server protocol is that you can write one implementation of a so-called language server for one
00:02:24.800 language and each of the editors that support the language protocol can use
00:02:30.239 this too and then have all this feature built in as well and a year later we got
00:02:36.640 the first language server for Ruby which was called Soloraph and at this time was when more
00:02:43.040 and more of these LSPs showed up over the scene and we got tools like the Python LSP the TypeScript LSP and the L
00:02:51.120 Tailwind LSP and so there was more and more of these tools for Ruby solraph showed that this
00:02:58.239 was possible to also do it in Ruby even though it's such a dynamic and flexible language
00:03:03.840 but then later in 2022 we got the Shopify Ruby LSP which really uh
00:03:09.280 improved the way language servers work for Ruby the way it was done one thing I noticed from working in
00:03:16.400 the wider JavaScript ecosystem was that the JavaScript tooling was really awesome and the experience in these
00:03:22.000 tools was really great too so my idea was to bring over these tools that we
00:03:27.200 know and love from the JavaScript languages over to the Ruby and Rails
00:03:33.640 ecosystem which is why I ported over a stimulus language server that worked
00:03:39.040 with the HML in our Rails applications so what this did was it was
00:03:45.120 analyzing the Ruby files and the HTML DRB files to look for instances where you were using stimulus it helped you
00:03:51.840 autocomplete with the attributes and it helped you guide some um with
00:03:56.879 diagnostics that some things might be wrong so it was looking at your JavaScript files to see if you set up
00:04:02.480 the things the right way with the naming and conventions how stimulus uses it and then a year later we got the
00:04:09.599 turbos which did a similar thing for turbo but the thing here was it was a super limited super basic language
00:04:16.639 server implementation but at this point it was clear to me that LSPs are the feature of dev tooling
00:04:23.680 but as I was mentioning there was something missing to really make this the right thing so stimulus and turbo
00:04:30.960 LSP were HTML only so they only worked on HTML syntax now this would have worked in
00:04:38.000 this file here too which could have been a HTML file but it only worked for the HTML static syntax if there were any ERB
00:04:46.240 tags in here it would just ignore them so Steam LSP was looking at these attributes giving you guidance
00:04:53.199 autocomplete and diagnostics to make sure you write the right code but as I mentioned no ERB
00:05:01.160 support but for most Rails apps it's quite common that you use active view ERB helpers so you might see uses like
00:05:09.120 that where you use tag.de ive or where you use a hash syntax for the data
00:05:14.440 attributes but this meant that we get no errors no diagnostics no recommendations
00:05:19.680 for these ERB snippets so we have to understand the
00:05:25.160 ERB and the fact is that there was not really any ERB tooling especially no
00:05:30.320 HTML ERB tooling in the ecosystem so why do we want HML ERB
00:05:36.560 tooling um I think now it matters even more than ever because as of Rails 7
00:05:45.120 Hotwire Stimulus and Turbo are the default set for the frameworks for the front ends that have been established
00:05:52.400 it also shows in the um rails developer survey from last year that stimulus
00:05:57.520 rised from the last almost second to last place to the first place last year and has now a 31% um share over the
00:06:05.360 whole um participants of the survey in the JavaScript state of the JS
00:06:12.000 survey we also saw something similar with Alpine.js which is quite similar to stimulus that there has been some gain
00:06:18.880 in popularity this is not a lot of like compared to the rest of them but the JavaScript
00:06:25.120 ecosystem is much bigger so it's kind of interesting to see that there's still the uptick in this um
00:06:31.800 development similarly with HTMX which is similar to Turbo there has been some advancements there too and some
00:06:38.080 popularity gains as well so I think the advanced HTML tooling is getting more important now so
00:06:45.919 my goal my idea was to add ERB support to all the tools we have in the Ruby
00:06:51.120 ecosystem so they work with these developer tools as well so at my resol talk two years ago I
00:06:58.639 was introducing the stimulus LSP and I had this slide up where I also showed that I have plans to add this ERP
00:07:05.919 support to the Ruby LSP or the Turbo LSP as soon as they kind of as soon as this works out and then a few months later at
00:07:13.440 the Rubycon hack day in Chicago we had the goal to just see what it takes to
00:07:19.039 make this work in Rubsp so we got together to work on this and we quickly realized that there is
00:07:25.840 more than we need or that we we need more advanced tooling than what we could do at the moment so it was more than we
00:07:33.440 needed and we needed more than the basics we had at the time the thing is
00:07:38.960 that ERB is versatile so you don't have to use it with HTML you can use it for
00:07:44.240 emails you can use it for YAML files you can use it for texts it doesn't really matter but the thing we care about is
00:07:50.720 that we want to use it with HTML so we want to care or we want to look at HTML ERB at the same time so we have this we
00:07:57.919 have this plan to add uh support for this so can we just use no giri and
00:08:03.120 prism to make this work so if you have a look at this file here
00:08:09.199 this is a standard ERB and HTML file what we could do is we could split this
00:08:14.319 up and look at this from two different angles one from the Ruby aspect and one from the HTML
00:08:19.400 aspect then we could say let's remove the Ruby from the HTML and the HTML from the Ruby so we just have the source of
00:08:27.199 each of the languages left now we could use this we could use
00:08:33.200 Prism to pass the Ruby parts we could use node gear to pass the HTML parts and
00:08:38.800 this would work and we get the result back but the problem is that we lose the context of where we have been
00:08:45.120 interpolating the ERB inside the file itself another problem is that the
00:08:51.760 output from the nugiri here doesn't include any location information so it
00:08:57.040 would be super hard to bring these two results back into one syntax tree that we can use to analyze the Ruby uh ERB
00:09:03.600 file so we lost the context and we needed some way to piece this together again
00:09:10.640 but even if we would be able to do this we wouldn't have any control over the edge cases of what we would be doing if
00:09:17.279 there's invalid syntax if there is anything we didn't um expect it's really
00:09:22.959 hard to then piece this together again so if you take a look at these examples here in the first example it
00:09:29.519 doesn't really matter where we interplating because it's just at the top level but if you look at the attributes it really matters where we
00:09:35.839 are interpolating because this could lead to a cross-sight scripting attack from if you control the attributes value
00:09:42.399 or if you just are interpolating in attribute value it's different again so we want to know where we want to
00:09:49.040 interpolate to be able to build the tools around it so I knew I wanted to build this
00:09:56.399 thing and so I knew I had to build my own parser to be able to do that and this is the idea of where this
00:10:02.560 HTMLware ERB parser came from i was looking around if there's anything like this already in the
00:10:09.399 ecosystem and I found a few of these parcels that were HTML aware but none of
00:10:15.839 them really went that far that I was thinking or hoping for to build these tools i had in
00:10:22.200 mind so I did some early experiments and was trying to figure out in which language I want to write this in the
00:10:29.200 stimulus and turbul are written in Typescript and the rublesp is written in Ruby rubocop is written in Ruby so we
00:10:36.399 would have to use one or the other language but since we want not to use
00:10:42.959 JavaScript from Ruby or Ruby from JavaScript I was thinking there must be something else so I was thinking maybe
00:10:48.800 this is best to follow Prism's lead and implement this in C the thing is I
00:10:54.720 didn't know C so I had to figure out C first but eventually I got it to work
00:11:00.880 and that's what I I'm here today to show you i have a written a parser it's
00:11:06.880 called Herp herb stands for HTML and DRB that's the name and I want to show you
00:11:12.800 what it can do today so what is Herp herb is a set of
00:11:19.040 tools that is designed to make it more productive to work in HTML DB files
00:11:24.800 as of right now it consists of three pieces a parser a formatterer and a
00:11:29.959 llinter and we're going to take a look at the parser first so this is a handwritten parser
00:11:36.079 that's HTMLware and can parse ERB files it's written in pure C99 and has no
00:11:42.320 additional dependencies which is following the lead of Prism again the only dependency it has is Prism itself
00:11:48.880 for parsing the Ruby snippets in the ERB file and also here it's trying to follow
00:11:54.079 Prism's design goals of being portable error tolerant and maintainable and here especially the
00:12:00.880 portable aspect was important to me because I want to use this from JavaScript i want to use this from Ruby
00:12:06.120 itself but maybe leave it open to other languages as well if you want to write more bindings
00:12:12.320 so this also features now a custom HTML extern parser which is not one that I
00:12:18.000 could just use from anywhere because an HTML compliant parser would try to auto
00:12:24.720 uh to fix some of the missing tags would try to shift around some of the nodes in the tree but what we need and what we
00:12:31.519 want is that we want to represent exactly what's in the file in the pause result so this parser is designed for
00:12:39.360 tooling not the same way as browser would run in the interpreted um
00:12:44.839 HTML and what it exposes in the end is a clean syntax tree of the inleafd HTML in
00:12:51.279 one result so this is as I mentioned written in C it has bindings for Ruby it has
00:12:57.519 JavaScript and TypeScript types as well and all you have to do today is to
00:13:02.639 add gem herb to your gem file or whatever and then you get to use the
00:13:07.920 herb interface Ruby API to lex parse extract Ruby code extract HTML code from
00:13:14.240 any ERB source we also provide two packages for
00:13:19.600 Node.js and the browser um the browser package is using a mcript and web assembly builds so you
00:13:27.680 can run this fully in the browser without any um server um requests and it
00:13:33.519 also has the same API for both of them so you can use a JavaScript API to parse and work with ERB
00:13:40.040 files so let's take a look at how this works so for an empty document if
00:13:45.920 there's nothing in your document all you get back is a document notes you have some location information you have
00:13:51.839 errors and you have the children of the document so let's add some text content and see how this looks like
00:13:58.880 so now we have this text in our documents and you can see there's a HTML text note now in our children array and
00:14:06.240 it represents this text as you would expect now if you are writing out a
00:14:11.680 document in your editor you never have a full complete um document as you are
00:14:17.360 writing it as you are typing it out there might be syntax error there might be an incomplete document so we want to
00:14:23.600 handle that in a way so this why we have support for partial HTML elements as well and what
00:14:29.680 you can see here is that if we open a H1 tag and we don't close it it has an
00:14:35.040 error in the errors array as you would expect and then you can see here that
00:14:40.720 there's a HTML element node to represent this H1 tag it has a open tag because that's what we see in the document but
00:14:47.440 the close tag itself is n to represent that there's a missing close tag
00:14:52.720 if you would use the same document with no quiri and would parse this with the HTML 5 fragment and convert it back to
00:15:00.600 HTML it would would return you the full element including the closing tag but as
00:15:06.639 you can see this closing tag was never part of our initial inputs so if you want to build tools around this it's not
00:15:12.160 really helpful if we get um additional notes injected into the um pass results
00:15:21.120 that's why mostly I was thinking it makes more sense to write our own custom lexum
00:15:27.000 parser this obviously works for complete HTML elements too so if you give it a
00:15:32.079 complete HTML element it has the element nodes an open tag the content text note
00:15:38.480 and then a close tag at the end this works for nested elements too
00:15:44.240 so you have um element nodes inside the element node and at the very bottom you
00:15:49.920 have the text node inside of it now this is all HTML at this point so we want to take a look at ERB as
00:15:56.440 well so if you just have an ERB output tag like we have here it will represent
00:16:01.680 this as a ERB content note including um the tag openings the content and the tag
00:16:07.120 closing as separate um tokens on the result you can also see that it's parsing this
00:16:13.440 already and that it's valid Ruby as a whole if we see that this is valid Ruby
00:16:18.560 we don't touch it anymore but if you see this is incomplete Ruby like for example if we are dealing with control flow
00:16:25.000 structures we are doing a second processing step here so if you look at this document
00:16:30.880 here you have the if opening ERB tag and the end closing tag and the way this
00:16:37.040 parcels easy to first pass through is that we have three elements a EB content tag the two new lines to indicate the
00:16:43.360 two new lines and then the closing end tag so what we do now is we traverse all
00:16:49.440 the ERB content nodes and parse them with Prism and do some analysis to figure out if they need to be put
00:16:55.759 together to form a bigger construct so in this case we have this if nodes
00:17:02.079 and what we do here is we see the if nodes we collect all the nodes up until we see a second end nodes and put all of
00:17:08.640 these elements inside of this ERB tag or this if tag so in this case we
00:17:14.319 transformed this from the three of them to one of them and this is going to be a ERB if nodes and inside of it that has
00:17:20.559 the two new lines as before but the end tag is now a property of this whole construct which is the if
00:17:28.120 node so this gives us one object to deal with and we know the nested nature of
00:17:33.600 these elements now this gets more interesting if we start to nest HTML
00:17:38.640 tags in it too so if you put the H1 tag in here we can now see it's a little bit
00:17:44.320 small but you can see here we have the opening tag again the closing tag at the bottom and these two form the if tag or
00:17:51.760 the if construct and inside of it we have this H1 element which is now nested
00:17:56.799 in this if construct so this gives us some hierarchy and opens us some doors to be
00:18:03.840 able to understand more about the nature of this HTML documents we can also more
00:18:10.240 precisely analyze it and then also maybe transform or rewrite some of the stuff because we know exactly what's in the
00:18:16.640 document itself it also supports attributes stock types comments it also includes all the
00:18:22.880 whites space so this might be important too and for the control flow structures
00:18:29.039 in Ruby we support all of these constructs here and each of them have a separate representation in the ERB um
00:18:36.960 node too so there's a second ERB if not node there's a ERB case node there's a EIB begin node and so on all of them
00:18:44.640 follow the exact same design as the prism nodes so if you would want to convert one from the other you could do
00:18:51.200 this very easily and this is what's available today this is the first public release I
00:18:56.880 want to share today this is now open source under my GitHub
00:19:03.080 handle/herp and at least for me this is now where the fun can begin we have the foundation to parse and understand these
00:19:10.080 ERP documents and now we can build more advanced tools on top of it so if this
00:19:17.200 sounds interesting to you I invite you to take a look at this and see if you have any ideas to build with this and
00:19:24.160 maybe we can improve the ERB tooling together if you just want to try and see what
00:19:30.480 this is like and what it feels like we have a interactive browser based puzzle playground as well so this allows you on
00:19:38.480 the left side you have the content of the document on the right side you have the pause results and as you scroll
00:19:45.679 through click on the notes you can highlight the source location of these
00:19:52.559 and this works in both ways so you can click and forth on both sides this is super helpful to just see
00:19:59.440 what the process is and helps with debugging some of these um um documents that are more
00:20:05.559 complex so this is on the herb tools dev/playground and feel free to check it
00:20:11.640 out now to look ahead we have been talking about the parcel now but they
00:20:16.720 have two more pieces here so this is the formatter um the idea here is that we
00:20:22.400 want to build the HTML ERB auto form as you may might know it from prettier or
00:20:28.159 from rubocop some of the rules there the idea is that you give it some unstructured ERB document or some
00:20:35.600 slightly unstructured ERB documents and including in the LSP or in some CLI when
00:20:42.159 you hit command save or run the herb format command it will output this formatted
00:20:48.799 document for you i am thinking that there might be some configuration rules of how you want to
00:20:54.640 structure these um uh ERB nodes but the idea is that this will just format it
00:20:59.679 for you there have been some tools that did this in the past but they always required you to have Ruby installed to
00:21:07.200 have the gem in the right path and right location for it to figure it out but I'm hoping that this will just work out of
00:21:13.520 the box when you install the LSP that this just works because it's not dependent on Ruby itself anymore to work
00:21:20.720 and then lastly the llinter as I mentioned earlier we want to build a llinter but the thing is that
00:21:28.480 we don't have a fully compliant HTML parser which is by design but what we can do because we see all the stuff in
00:21:35.440 the in the syntax tree we can check for valid validity with HTML 5 after the
00:21:42.159 fact so we can check do you have the right um elements in the structure uh do you have invalid tags nested under each
00:21:49.200 other are we missing some old attributes on image tags or are we doing unsafe interpolation somewhere in the
00:21:55.720 document this is just like some examples of what we can build and build rules for and maybe this can also just tightly
00:22:02.159 integrate with rubocop so you can run this as part of your regular rubocop run and one more thing about this was
00:22:10.159 which I was working on this whole idea of just writing this parser i noticed
00:22:15.200 that there's some I guess possibility to also build a new smarter ERB rendering
00:22:22.679 engine and this is kind of the vision that I want to share at Railscon earlier uh later this year and this is code
00:22:30.159 named reaction view so the idea here is that we built an action view um add-on
00:22:36.080 that will understand these ERB views and can analyze how the ERB ears are
00:22:42.159 structured and then more smartly updates and rerenders um part of the um
00:22:49.400 template when it's state changes so we'll show an example here so we have a
00:22:54.640 basic template which is a items um array and we loop over it we render out a list
00:23:00.640 item for each of the items the instance variable here is kind of representing a state so we have three
00:23:06.960 items in the state and then the bottom left you see the rendered view itself so we render this initially send
00:23:14.320 it down to the client from the server and then in some way the state gets updated we have a fourth element in the
00:23:20.960 state now so we want to reflect that we see that the state changed that the
00:23:26.799 items changed so we want to rerender the view so we look did the items instance
00:23:33.919 variable actually contain in the in the view and we see it is here so we see
00:23:39.360 that and then we see okay we just have one more item new so we just rerender this part of the
00:23:45.240 template and then render the diff for this fourth element and when we do that we just get
00:23:51.440 this fourth item and all we have to do is then to apply this to the results and
00:23:57.600 then reflect this state change this is super similar to how Fenix live view in
00:24:02.720 alexir handles this and that's where the main inspiration from this comes from um one more thing that they have
00:24:10.640 here to discuss is a other thing I have been noticing that maybe there is
00:24:16.320 possibility to write a HTML templating syntax tree what this means is that we
00:24:24.000 have been focusing on ERB and HTML for now but we have a few other templating
00:24:31.279 engines like HAML and Slim and if we do this the right way I think there's a way that we can bundle these efforts and
00:24:39.200 improve the tooling in general for all of these tools together so this includes all of these
00:24:44.240 template languages as well and the way it works now this is how herp does it today so you have this HTML ERB view
00:24:51.440 this gives you a pause result and the same is true for when
00:24:56.559 you're using action view with these helpers that gives you the same result as well but we could also do this with
00:25:03.200 HAML so whenever we see this hammer syntax we translate this into the same parse results and could do the same
00:25:09.679 thing for slim and if we do this we can build all the tools for HTML itself on this parse
00:25:17.600 result that we share between these engines so the rule is as long as we can transform this syntax into the same tree
00:25:24.320 structure we can reuse these tools for all these source files and that means we
00:25:29.600 can combine the efforts to build more advanced tools on top of HTML
00:25:35.480 templating okay so what's next for the short-term future of um Herb so we want
00:25:42.000 to ship these two features the format and lint very soon they are currently in progress i couldn't finish them in time
00:25:48.320 for this presentation but they are on the way and then the other thing is that
00:25:54.720 we want to integrate these this parser now into the existing ecosystem of tools
00:25:59.919 um so this means we want to add it to stimulus LSP maybe we can write a Ruby LSP add-on to integrated into Ruby LSP
00:26:06.720 directly for handling the ERB files there too and also more advanced tools for turbo LSP so we can look at all the
00:26:14.159 turbo frames and turbo streams um the helpers to make it more easy to work with so you want to add more diagnostics
00:26:22.320 more code actions refactoring tools transformations and all that stuff then we are still missing the view
00:26:29.919 helpers election view helper support they are on the way too so this just means that we want to see or transform
00:26:36.799 these syntaxes here for using link tags content tag if we use the attributes for
00:26:42.159 the data attributes the hash syntax we want just to transform this syntax into the same HTML representation so we can
00:26:49.360 build tools on top of it so when you are building tools for HTML it doesn't matter if it's actually HTML itself or
00:26:56.320 if you're using these helpers here another thing that's quite interesting is that we can do
00:27:02.520 multifile analysis and diagnostics because we understand all these views now we can see okay you're
00:27:10.159 rendering a render a partial here and we can look up where this partial might be and then kind of construct a whole tree
00:27:16.400 of all your view files and partials and then build or give you some maybe unused
00:27:23.440 view file found here so you can refactor these um out if you don't use them
00:27:28.919 anymore so this process is now ready and I found when I was working on this that
00:27:34.159 there are a few gems out there that do something very similar but aren't quite there yet so maybe this parcel can help
00:27:41.120 refine some of these gems to make them more easier and maintainable so to conclude
00:27:49.039 um Prism itself has been really awesome to work with i have been using this heavily for this project here obviously
00:27:56.399 but Prism itself is now shipping with Ruby 3.4 for as of last Christmas and I think it has had a big impact on the
00:28:04.080 whole tooling ecosystem and the Ruby internals itself and I believe that herb itself could have a similar impact in
00:28:10.799 the way HTML templated tooling works but also that it could power this more advanced ERB rendering engine that could
00:28:18.159 be used for smarter updates in the front end and I think it's fair to say that
00:28:24.080 the community itself has built really awesome tooling around the Ruby ecosystem over the last few years and I
00:28:30.320 think that's now it's time to build the same level of tools and the same care and same level of of detail for the view
00:28:37.600 layer as well and I think that with herb we have a path forward to make this
00:28:43.720 happen in the end I love Ruby and that's why I'm here today too I want to keep
00:28:49.360 writing Ruby I want to keep Ruby as attractive as possible for people to get
00:28:54.880 started and use as well So this has been my presentation
00:29:00.799 about the hot wire and HTML earware Earview tooling and I've prepared this slide here for a summary of what we
00:29:08.799 talked about today including the Ruby gems including the MPM packages the herb
00:29:14.240 tools and these more advanced tools for HTML
00:29:19.720 ERB and then finally I want to thank all of these people that have in some way or
00:29:25.440 form helped out with this release today that made it happen some of them helped
00:29:30.960 out with testing some of them helped out with um contributing codes some of them have helped out with the gem name and
00:29:37.840 others have helped out with design and branding but all of them have been here to help out to make this release
00:29:43.120 possible and then finally a big thanks to all the contributors for Prism Ray compiler
00:29:50.320 recompile doc and then Mike's Rubyc extension explains um repository which
00:29:55.679 helped me bring her to Ruby in native
00:30:00.840 extension so this is her tools this is the um parser for HTML um and if you
00:30:09.600 have any ideas opinions or questions feel free to reach out after the talk and that's all I have for today thank
Marco Roth
@marcoroth
Explore all talks recorded at RubyKaigi 2025
+66