Your Views Deserve a Grammar @ Tropical on Rails 2026, São Paulo, Brazil

Rails has always been the "batteries included" framework, but the view layer never got the same treatment. HTML+ERB has been loosely defined for 20 years. What happens when you give it a proper grammar? You get a parser, a toolchain, and eventually, reactivity.

From a parser written in C, to a linter with 60+ rules, a language server, a rendering engine, and browser dev tools, all powered by the same syntax tree. We'll trace the evolution from Turbolinks to Hotwire, show where the current approach hits a ceiling, and introduce Herb and ReActionView: a path to reactive, server-rendered Rails views without leaving ERB behind.

Transcript

1. Marco Roth Your Views Deserve a Grammar April 9, 2026 - Tropical on Rails 2026
2. Marco Roth !  @marcoroth_  @marcoroth@ruby.social 🌐 marcoroth.dev  @marcoroth Full-Stack Developer & Open Source Contributor  @marcoroth.dev
3. Developer Tooling & Developer Experience
4. 2021 Stimulus LSP
8. <div data-controller="hello"> <input data-hello-target="name" type="text"> <button data-action="click->hello#greet"> Greet </button> <span data-hello-target="output"></span> </div>
9. <%= tag.div data: { controller: "hello" } do %> <%= content_tag :input, data: { hello_target: "name"} %> <%= tag.button data: { action: "click->hello#greet" } do %> Greet <% end %> <%= tag.span data: { hello_target: "output" } %> <% end %>
10. HTML+ERB
12. Linter Formatter Good Error Messages Guidance
14. The JavaScript tooling and DX is awesome
15. I noticed this myself
16. https://bsky.app/profile/anniesexton.com/post/3l72crajnke2q
17. This is not about Static Typing
18. Its about missing tooling in general
19. Especially in the Rails View Layer
20. "#$
21. Ruby Prism Parser Kevin Newtown
22. HTML+ERB
23. HTML+ERB HTML+ERB
24. Herb
25. Improving the tooling for HTML+ERB and the View Layer
26. Toolchains ?
27. What is a programming language?
28. ✓ A syntax ✓ A parser ✓ A compiler or interpreter
30. New programming language?
31. A modern programming language is a full toolchain
32. ✓ syntax ✓ parser ✓ compiler or interpreter ✓ formatter ✓ linter ✓ language server ✓ package manager ✓ test runner ✓ CLI ✓ Interactive Playground ✓ Actionable error messages ✓ Editor integration ✓ Browser dev tools ...
34. Rust + Cargo cargo new → project setup cargo build → compile cargo test → run tests cargo fmt → format code cargo clippy → lint code cargo doc → generate docs cargo bench → benchmarks cargo publish → release One tool. Everything built in.
35. Go go build → compile go test → test runner go fmt → formatter (shipped day one) go vet → static analysis go doc → documentation go run → run directly go mod → dependency management gopls → language server No debates. No configuration. The language decided for you.
37. Vite / VoidZero Ecosystem Vite → dev server, build orchestration, HMR | Rolldown → Rust bundler (replacing Rollup + esbuild) | OXC → Rust parser, linter (oxlint), transformer | Vitest → testing (built on Vite) VitePress → documentation (built on Vite) One parser. Shared infrastructure. Every tool benefits from every improvement.
39. Integration beats collection.
41. There has been a lot of innovation in the JavaScript world
42. But there's a cost to this pace of innovation.
43. The Cost of Churn JavaScript (2015-2025): Grunt → Gulp → Webpack → Rollup → Parcel → esbuild → Vite Mocha → Jasmine → Jest → Vitest Bower → npm → yarn → pnpm → Bun → npm Backbone → Angular → React → Vue → Svelte → Solid → ... Every 2-3 years: rewrite your toolchain.
45. Rails just works. And it keeps working.
46. Challenge: How do you innovate without breaking what already works?
47. The New Wave
48. Major Ruby DX Events Since Ruby 3.0 2021 2022 2023 2024 2026 2025/11/06 Ruby 3.0 (release) 2025 repl_type_completor (release) Tomoya Ishida RubyWorld Conference 2025 Steep (v1.0 release) Soutaro Matsumoto debug.gem (release)
 Koichi Sasada RDoc modernization IRB & Reline transformation Tomoya Ishida Mari Imaizumi
 Hitoshi Hasumi Herb (release) Marco Roth Prism (release) Kevin Newton Ruby LSP (release) Vini Stock RBS in Sorbet Alexandre Terrasa
 Alexander Momchilov rbs-inline (release) Soutaro Matsumoto https://github.com/st0012/slides/tree/main/2025-11-06-ruby-world-conference
49. Importance of Shared Infrastructure RubyWorld Conference 2025 2025/11/06 Prism Herb repl_type_completor Ruby LSP Sorbet RuboCop RDoc (Experimental/WIP) Steep RBS https://github.com/st0012/slides/tree/main/2025-11-06-ruby-world-conference
50. But there's one place this hasn't really happened yet.
51. The View Layer
52. Look beyond your own ecosystem.
53. See what others do well. Understand why it works. Bring it back. The Ruby way.
54. What would it look like if we brought all of these ideas to the Rails view layer?
55. ... and make it feel like it belongs here?
56. With the goal of making it as backwards compatible as possible
57. HEEx
58. HEEx
60. .ex Elixir (Ex) .rb Ruby (rb)
61. .eex Embedded Elixir(EEx) .erb Embedded Ruby(ERb) .ex Elixir (Ex) .rb Ruby (rb)
62. .heex HTML+EEx (HEEx) .eex Embedded Elixir(EEx) .erb Embedded Ruby(ERb) .ex Elixir (Ex) .rb Ruby (rb)
63. .heex HTML+EEx (HEEx) .eex Embedded Elixir(EEx) .erb Embedded Ruby(ERb) .ex Elixir (Ex) .rb Ruby (rb) ?
64. .heex HTML+EEx (HEEx) .eex Embedded Elixir(EEx) .erb Embedded Ruby(ERb) .herb HTML+ERB (Herb) .ex Elixir (Ex) .rb Ruby (rb)
65. Why Tooling Never Existed?
66. Because there was nothing to build against.
67. There was no parser like Prism
68. ERB has no spec. No formal grammar.
69. The "language" is defined by whatever the engine implementation does.
70. Erubi behaves one way. ERB from stdlib behaves slightly differently.
71. Slim, Haml, ERB. All different.
72. You can't build a linter for a language that doesn't have a definition.
73. You can't build a formatter for syntax that doesn't have rules.
74. You can't build a language server when the "spec" is a regex in an engine.
75. Marco Roth Your Views Deserve a Grammar April 9, 2026 - Tropical on Rails 2026
76. The questions are not "What's wrong with ERB?" "What's wrong with Erubi?"
77. Erubi is simple, stable, and reliable.
78. It served Rails well for 20 years.
79. The question is ...
80. What becomes possible when the ERB engine also understands HTML?
81. Why is this hard?
82. <div class="container"> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div>
83. This file contains THREE languages: 1. HTML → <div>, <h1>, <b>, class="..." 2. ERB → <% %>, <%= %> 3. Ruby → @user, if @show_details
84. Why can't we use existing parsers?
85. HTML → Nokogiri Ruby → Prism
86. <div> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div> <div> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div>
87. Ruby HTML <div> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div> <div> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div>
88. Ruby HTML <div> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div> <div> <span><%= @user.firstname %></span> <b><%= @user.lastname %></b> </div>
89. Ruby HTML @user.firstname @user.lastname <div> <span> </span> <b> </b> </div>
90. Ruby HTML @user.firstname @user.lastname <div> <span> </span> <b> </b> </div> t require "prism" Prism.parse("...") require "nokogiri" Nokogiri::HTML5.fragment("...")
91. Ruby HTML @user.firstname @user.lastname <div> <span> </span> <b> </b> </div> t
92. We lost the HTML-context in the process
93. <%= "Hello World" %> <div <%= attributes %>></div> <div id="<%= dom_id(post) %>"></div>
94. Ruby HTML @user.firstname @user.lastname <div> <span> </span> <b> </b> </div>
95. It doesn't allow for much control with edge cases
96. and to understand the context and hierarchy of the templates
97. HTML-aware ERB Parser Nokogiri is a spec compliant HTML parser
98. HTML-aware ERB Parser Nokogiri is designed to behave like a browser
99. HTML-aware ERB Parser Its not built for tooling
100. <h1>Title
101. irb(main):001> Nokogiri::HTML5.fragment(html).to_html <h1>Title
102. irb(main):001> Nokogiri::HTML5.fragment(html).to_html <h1>Title => "<h1>Title</h1>"
103. irb(main):001> Nokogiri::HTML5.fragment(html).to_html <h1>Title
104. irb(main):001> Nokogiri::HTML5.fragment(html).to_html <h1>Title => "<h1>Title</h1>"
105. HTML-aware ERB Parser Lets parse this with Herb
106. <h1>Title @ HTMLElementNode ├── errors: (1 item) │ └── @ MissingClosingTagError │ ├── message: " │ │ Opening tag `<h1>` at (1:1) │ │ doesn't have a matching │ │ closing tag `</h1>`. │ │ " │ └── opening_tag: "h1" │ ├── open_tag: │ └── @ HTMLOpenTagNode │ ├── tag_opening: "<" │ ├── tag_name: "h1" │ ├── tag_closing: ">" │ ├── children: [] │ └── is_void: false │ ├── tag_name: "h1" ├── body: (1 item) │ └── @ HTMLTextNode │ └── content: "Title" │ ├── close_tag: ∅ └── is_void: false ^^^^^
107. <h1>Title @ HTMLElementNode │── errors: (1 item) │ └── @ MissingClosingTagError │ ├── message: " │ │ Opening tag `<h1>` at (1:1) │ │ doesn't have a matching │ │ closing tag `</h1>`. │ │ " │ └── opening_tag: "h1" │ ├── open_tag: │ └── @ HTMLOpenTagNode │ ├── tag_opening: "<" │ ├── tag_name: "h1" │ ├── tag_closing: ">" │ ├── children: [] │ └── is_void: false │ │── tag_name: "h1" │── body: (1 item) │ └── @ HTMLTextNode │ └── content: "Title" │ └── close_tag: ∅ └── is_void: false ^^^^^
108. HTML-aware ERB Parser ERB has some rules...
109. HTML-aware ERB Parser ...but nobody checks them
110. <% if valid? %> <h1>Title</h1> <% end %>
111. HTML-aware ERB Parser ERB = Embedded Ruby
112. HTML-aware ERB Parser Which means it has to follow the same rules Ruby has to follow
113. HTML-aware ERB Parser Since we have no grammer of what defines a valid HTML+ERB template
114. HTML-aware ERB Parser The following is technically valid
115. <% if valid? %> <h1>Title</h1> <% end %>
116. HTML-aware ERB Parser but this would crash as soon as you run it
117. <% if valid? %> <h1>Title</h1> <% end %> <% if valid? %> <h1>Title</h1> <% end %>
118. <% if valid? %> <h1>Title</h1> <% end %>
119. <% if valid? %> <h1>Title</h1> <% end %> @ ERBIfNode ├── tag_opening: "<%" ├── content: " if valid? " ├── tag_closing: "%>" ├── statements: │ └── @ HTMLElementNode │ ├── open_tag: │ │ └── @ HTMLOpenTagNode │ │ ├── tag_opening: "<" │ │ ├── tag_name: "h1" │ │ ├── tag_closing: ">" │ │ ├── children: [] │ │ └── is_void: false │ │ │ ├── tag_name: "h1" │ ├── body: │ │ └── @ HTMLTextNode │ │ └── content: "Title" │ │ │ └── close_tag: │ └── @ HTMLCloseTagNode │ ├── tag_opening: "</" │ ├── tag_name: "h1" │ └── tag_closing: ">" │ ├── subsequent: ∅ └── end_node: └── @ ERBEndNode ├── tag_opening: "<%" ├── content: " end " └── tag_closing: "%>"
120. <% if valid? %> <h1>Title</h1> <% end %> @ ERBIfNode ├── tag_opening: "<%" ├── content: " if valid? " ├── tag_closing: "%>" ├── statements: │ └── @ HTMLElementNode │ ├── open_tag: │ │ └── @ HTMLOpenTagNode │ │ ├── tag_opening: "<" │ │ ├── tag_name: "h1" │ │ ├── tag_closing: ">" │ │ ├── children: [] │ │ └── is_void: false │ │ │ ├── tag_name: "h1" │ ├── body: │ │ └── @ HTMLTextNode │ │ └── content: "Title" │ │ │ └── close_tag: │ └── @ HTMLCloseTagNode │ ├── tag_opening: "</" │ ├── tag_name: "h1" │ └── tag_closing: ">" │ ├── subsequent: ∅ └── end_node: └── @ ERBEndNode ├── tag_opening: "<%" ├── content: " end " └── tag_closing: "%>"
121. <% if valid? %> <h1>Title</h1> <% end %> @ ERBIfNode ├── tag_opening: "<%" ├── content: " if valid? " ├── tag_closing: "%>" ├── statements: │ └── @ HTMLElementNode │ ├── open_tag: │ │ └── @ HTMLOpenTagNode │ │ ├── tag_opening: "<" │ │ ├── tag_name: "h1" │ │ ├── tag_closing: ">" │ │ ├── children: [] │ │ └── is_void: false │ │ │ ├── tag_name: "h1" │ ├── body: │ │ └── @ HTMLTextNode │ │ └── content: "Title" │ │ │ └── close_tag: │ └── @ HTMLCloseTagNode │ ├── tag_opening: "</" │ ├── tag_name: "h1" │ └── tag_closing: ">" │ ├── subsequent: ∅ └── end_node: └── @ ERBEndNode ├── tag_opening: "<%" ├── content: " end " └── tag_closing: "%>"
122. <% if valid? %> <h1>Title</h1> <% end %> @ ERBIfNode ├── tag_opening: "<%" ├── content: " if valid? " ├── tag_closing: "%>" ├── statements: │ └── @ HTMLElementNode │ ├── open_tag: │ │ └── @ HTMLOpenTagNode │ │ ├── tag_opening: "<" │ │ ├── tag_name: "h1" │ │ ├── tag_closing: ">" │ │ ├── children: [] │ │ └── is_void: false │ │ │ ├── tag_name: "h1" │ ├── body: │ │ └── @ HTMLTextNode │ │ └── content: "Title" │ │ │ └── close_tag: │ └── @ HTMLCloseTagNode │ ├── tag_opening: "</" │ ├── tag_name: "h1" │ └── tag_closing: ">" │ ├── subsequent: ∅ └── end_node: └── @ ERBEndNode ├── tag_opening: "<%" ├── content: " end " └── tag_closing: "%>"
123. <% if valid? %> <h1>Title</h1> <% end %> @ ERBIfNode ├── tag_opening: "<%" ├── content: " if valid? " ├── tag_closing: "%>" ├── statements: │ └── @ HTMLElementNode │ ├── open_tag: │ │ └── @ HTMLOpenTagNode │ │ ├── tag_opening: "<" │ │ ├── tag_name: "h1" │ │ ├── tag_closing: ">" │ │ ├── children: [] │ │ └── is_void: false │ │ │ ├── tag_name: "h1" │ ├── body: │ │ └── @ HTMLTextNode │ │ └── content: "Title" │ │ │ └── close_tag: │ └── @ HTMLCloseTagNode │ ├── tag_opening: "</" │ ├── tag_name: "h1" │ └── tag_closing: ">" │ ├── subsequent: ∅ └── end_node: └── @ ERBEndNode ├── tag_opening: "<%" ├── content: " end " └── tag_closing: "%>"
124. <% if valid? %> <h1>Title</h1> <% end %> @ ERBIfNode ├── tag_opening: "<%" ├── content: " if valid? " ├── tag_closing: "%>" ├── statements: │ └── @ HTMLElementNode │ ├── open_tag: │ │ └── @ HTMLOpenTagNode │ │ ├── tag_opening: "<" │ │ ├── tag_name: "h1" │ │ ├── tag_closing: ">" │ │ ├── children: [] │ │ └── is_void: false │ │ │ ├── tag_name: "h1" │ ├── body: │ │ └── @ HTMLTextNode │ │ └── content: "Title" │ │ │ └── close_tag: │ └── @ HTMLCloseTagNode │ ├── tag_opening: "</" │ ├── tag_name: "h1" │ └── tag_closing: ">" │ ├── subsequent: ∅ └── end_node: └── @ ERBEndNode ├── tag_opening: "<%" ├── content: " end " └── tag_closing: "%>"
125. Ruby HTML @user.firstname @user.lastname <div> <span> </span> <b> </b> </div>
126. This opens a lot of doors for understanding, analyzing, working with HTML+ERB documents. What If We Established a Grammar?
127. What if we established a HTML+ERB grammar?
128. Establish a formal syntax to define what's valid and invalid
129. Provide structure, hierarchy, and HTML-awareness that tools can understand and reason about
130. This is what Prism enables
131. Herb Parser (HTML+ERB structure) + Prism (Ruby grammar) = Full validation before runtime
132. Missing <% end %>? → Herb + Prism catch it at parse time Invalid Ruby syntax? → Prism catches it at parse time Unclosed HTML tag? → Herb catches it at parse time
133. Then we could: → Parse it (not just split it) → Analyze it (static analysis) → Lint it (catch mistakes) → Format it (consistent style) → Validate it (no invalid HTML) → Understand it (language server) → Compile it intelligently (optimizations) → Track changes (reactivity)
134. Establishing the grammar is what makes everything else possible.
135. Herb
136. A grammar.
137. A grammar. A parser.
138. A grammar. A parser. A full toolchain for HTML+ERB
139. This is what was missing.
140. The language definition itself
141. ✓ syntax ✓ parser ✓ compiler or interpreter ✓ formatter ✓ linter ✓ language server ✓ package manager ✓ test runner ✓ CLI ✓ Interactive Playground ✓ Actionable error messages ✓ Editor integration ✓ Browser dev tools ...
142. The Herb Toolchain
143. Parser → HTML+ERB parser Formatter → format-on-save in your editor Linter → 60+ rules (including accessibility) Language Server → diagnostics, highlights, code actions CLI → herb lint, herb format, herb analyze Playground → herb-tools.dev/playground (WebAssembly) Editor → VS Code extension, Zed, Neovim Error messages → annotated, syntax-highlighted, exact locations Runtime engine → Herb::Engine (drop-in for Erubi) Browser DevTools → view outlines, ERB hover, jump-to-source Highlighter → syntax highlighting engine Rewriter → automated refactoring Printer → lossless AST reconstruction
144. One parser. One truth.
146. This is really powerful.
147. If your editor tells you there is an error, you don't have to run the code to find out
148. Because its powered by the same underlying architecture
150. Herb Language Server
160. Document Highlights Support
162. Support for Action View Helpers
163. <div data-controller="hello"> <input data-hello-target="name" type="text"> <button data-action="click->hello#greet"> Greet </button> <span data-hello-target="output"></span> </div>
164. <%= tag.div data: { controller: "hello" } do %> <%= content_tag :input, data: { hello_target: "name"} %> <%= tag.button data: { action: "click->hello#greet" } do %> Greet <% end %> <%= tag.span data: { hello_target: "output" } %> <% end %>
169. Rewriter Code Actions
171. Folding Ranges
173. Smart Comment Toggling
175. Herb Linter
177. No style guide on how to write to good views
178. A way to help guide people towards best practices and to avoid commons mistakes
179. Not just people...
180. But also LLMs and Coding Agents
181. Having these rules and best practices encoded in tools like Herb, helps agents reason about this more efficiently and accurately
190. Herb Formatter
191. <div><h1><%=@title%></h1><%if user_signed_in?%> <p>Welcome,<%= current_user.name%>!</p><%else%> <p>Please<%= link_to"sign in",login_path%>.</ p><%end%></div>
192. <div><h1><%=@title%></h1><%if user_signed_in?%> <p>Welcome,<%= current_user.name%>!</p><%else%> <p>Please<%= link_to"sign in",login_path%>.</ p><%end%></div> S cmd
193. <div><h1><%=@title%></h1><%if user_signed_in?%> <p>Welcome,<%= current_user.name%>!</p><%else%> <p>Please<%= link_to"sign in",login_path%>.</ p><%end%></div> bundle exec herb format [file]
194. <div> <h1><%= @title %></h1> <% if user_signed_in? %> <p>Welcome, <%= current_user.name %>!</p> <% else %> <p>Please <%= link_to "sign in", login_path %></p> <% end %> </div>
196. - name: Herb Linter run: npx @herb-tools/linter - name: Herb Formatter run: npx @herb-tools/formatter --check .github/workflows/lint.yml
197. ::Engine Herb
198. HTML-aware ERB Rendering Engine
199. Erubi::Engine API-compatible
200. It's using the Herb Parser to parse the templates
201. The same parser that's running in your editor is now also rendering your views
202. Makes the tooling a lot more accurate and instant
203. Which means we can do a lot of cool things!
204. Let's improve error messages
207. The Herb Parser already exactly knows where the error is
210. Since we control the rendering now
211. We can inject additional HTML attributes in development
212. <html data-herb-debug-file-name="application.html.erb" > ... </html>
213. [data-herb-debug-file-name] { outline: blue dotted 2px; outline-offset: 2px; } // ...
216. <html data-herb-debug-outline-type="view" data-herb-debug-file-name="application.html.erb" > ... </html>
219. <html data-herb-debug-outline-type="view" data-herb-debug-file-name="application.html.erb" data-herb-debug-file-relative-path="..." > ... </html>
221. <html data-herb-debug-outline-type="view" data-herb-debug-file-name="application.html.erb" data-herb-debug-file-relative-path="..." data-herb-debug-file-full-path="..." > ... </html>
226. Show ERB content on hover
229. Jump-to-source
231. The Key Insight
233. String Templating Engine HTML Templating Engine ↓
234. Our engine is now aware of its HTML surroundings and can enhance it
235. From Tooling to Runtime
236. Parser understands structure → Linter can check HTML validity → Formatter can indent correctly → Language server can navigate
237. Engine compiles with structure → Invalid HTML won't compile → Debug attributes map DOM ↔ template → Error messages are precise
238. With all this knowledge we can also start to tackle more ambitious things
239. But first
240. Lets look at the good ideas we've built
241. Turbolinks → fast page transitions, no SPA needed Stimulus → modest JS for HTML you already have CableReady → fine-grained DOM operations from the server StimulusReflex → server-side reactivity over ActionCable Turbo Drive → Turbolinks evolved Turbo Frames → partial page updates, lazy loading Turbo Streams → server-pushed HTML fragments Turbo Morphing → DOM diffing without manual targets
243. ✓ Simple mental model, server renders HTML ✓ No build step required ✓ Works with existing ERB views ✓ Progressive enhancement built in ✓ Turbo Frames for lazy-loaded sections ✓ Turbo Streams for real-time updates ✓ Stimulus for client-side behavior ✓ It just works for 80% of use cases
244. ✓ State lives on the server ✓ One source of truth (your database) ✓ No client-side state sync bugs ✓ No stale data problems ✓ No hydration mismatches ✓ Authorization stays where it belongs
245. This is enough for most Rails apps. This is why people choose Rails. This is why people choose Hotwire.
246. But when you need more fidelity or high interactivity Hotwire can fall short
247. The Hotwire approach can get really hairy
248. To the point where it can feel like glue code held together with duct tape
249. This is why a lot of teams choose SPAs from day one
250. And don't choose the HTML-over-the-wire approach
252. ✓ Keep Rails as the backend ✓ Use React/Vue/Svelte for the view ✓ Great DX for rich interactions ✓ Smooth transitions, client-side state ✓ You get the best of both worlds
253. But: → You leave ERB and ActionView behind → You need a JavaScript framework → You need a build pipeline → Rails itself is no longer "full-stack"
254. What if we could complete the Hotwire story?
255. And how would that look like?
256. What if Rails apps could have...
257. → Optimistic UI updates → Offline functionality → Lazy loading driven by the template → Instant interactions without full reloads → Beautiful, modern UX → Component-driven deferred rendering
258. Without abandoning server-rendered HTML?
259. Without writing a React/Vue/Svelte SPA?
260. Without giving up what makes Full-Stack Rails great?
261. Reactivity
263. StimulusReflex Phoenix LiveView
265. Keep what's great. Add what's missing. No JavaScript framework required.
266. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered
267. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed
268. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view
269. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view tracing dependencies
270. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view tracing dependencies render delta for item `4`
271. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view tracing dependencies render delta for item `4` <li>4</li>
272. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view tracing dependencies render delta for item `4` <li>4</li>
273. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view tracing dependencies render delta for item `4` apply delta to view <li>4</li>
274. <ul> <% @items do |item| %> <li><%= item %></li> <% end %> </ul> @items = [1, 2, 3, 4] <ul> <li>1</li> <li>2</li> <li>3</li> <li>4</li> </ul> State View Template Rendered View Log Initial view rendered @items state changed re-rendering view tracing dependencies render delta for item `4` apply delta to view
275. How can we make this work?
276. The missing piece was always the parser.
277. Herb
278. With the Herb Toolchain as the foundation this now feels doable.
279. Herb Diffing Engine
280. It's not quite ready yet.
282. Sneak Peek
283. <div>Hello World</div> ↓
284. <div>Hello World</div> <div>Hello Ruby</div> ↓
285. <div>Hello World</div> <div>Hello Ruby</div> ↓
286. <h1><%= title %></h1> ↓
287. <h1><%= title %></h1> <h1 class="title"><%= title %></h1> ↓
288. <h1><%= title %></h1> <h1 class="title"><%= title %></h1> ↓
289. This also works for HTML Elements, ERB Content etc.
290. And you might already be able to see where this is going!
291. Herb Dev Server
292. Hot Reloading in Development
295. No full page refresh
296. Just incremental updates emitted by the Herb Diff Engine
297. The Engine knows: What changed How it changed
298. And can figure out the minimal set of DOM operations the reflect the change on the website
299. element.setAttribute("class", "new-value")
301. This is going the be the foundation to make reactivity work
302. How are views and partial connected?
303. Refactoring View Files Detecting Unused Partials Cross-file diagnostics Which page renders this partial
306. Conclusion
307. We started with this question. Now we have the answer.
308. What becomes possible when the view layer gets a grammar?
309. A grammar enables a parser. A parser enables a toolchain. A toolchain enables a platform.
310. I hope this talk has given an overview of Herb and its potential
311. What it can enable in the future.
312. How it could complete the Hotwire story.
313. So that we can keep writing Ruby
314. and build ambitious Rails applications with even less complexity
315. The Ruby Prism Parser had a big effect on Ruby internals and the tooling landscape
316. Herb can have a similar effect for HTML Templating and Tooling.
317. One More Thing
318. After 2.5 years we have come full circle
319. I'm happy to announce
320. Now powered by Herb
325. Acknowledgments
326. Thank you to everyone who tried Herb and reported issues
328. github.com/sponsors/marcoroth 
330. https://gem.coop/updates/2026-fellowship/
331. Travel Support
333. Please try the tools, report issues, and give feedback.
335. herb-tools.dev
336. Thank you %  @marcoroth_  @marcoroth@ruby.social 🌐 marcoroth.dev  @marcoroth  @marcoroth.dev  /in/marco-roth