Two halves of the Rails view layer toolchain

Marco Roth's keynote at Tropical on Rails 2026 ("Why Rails Needs a View Layer Toolchain") is the consolidation of two years of work that has changed what the Rails view layer can be. Herb, an HTML-aware ERB parser written in C with bindings for Ruby, Node, Java, Rust, and the browser. Herb tooling: linter, formatter, language server, browser dev tools. ReActionView, an ActionView-compatible ERB engine. Together they treat ERB as a proper language with proper tools, rather than as strings with regex.

If you have spent any time in the Rails view layer in the last decade, you know what was missing. No AST, no language server, errors surfacing at render time, linters that could not tell you a closing tag was wrong, formatters that did not know about the actual structure. Most of the wins JavaScript developers have had with Prettier, ESLint, TypeScript, and language servers over the last ten years have not had Rails view layer equivalents.

Marco is shipping those equivalents. It is one of the most important things happening in the Rails ecosystem right now.

The code half of the toolchain is only half of it.

The code half is what Marco is building. Parser, AST, language server, linter, formatter, browser dev tools. It treats ERB the way TypeScript treats TS files. The template is a structured artifact the tooling understands.

That unlocks specific things. Real-time errors in your editor. Reliable autoformat that does not break ERB tags. Linter rules that catch unsafe interpolation patterns. AI coding agents that can read the AST and understand what your template actually contains, rather than guessing from regex.

The whole thing is the developer-experience layer for working on ERB templates. Marco has spent enough time at the seam between ERB and developer tools to know exactly where the friction is and what to do about it. The work is good.

It is not the whole toolchain.

The design half is the seam between Figma and production code.

The reason this is its own half: every real Rails app eventually has a design system. The design system has tokens (colors, spacing, typography), components (Button, Card, NavBar), and patterns (forms, tables, dialogs). The team builds the system in Figma. They also build it in code, often as ViewComponent or Phlex components. These two systems drift.

Drift looks like three versions of every button across the codebase, six shades of blue accumulated over eighteen months, tokens defined in Figma that do not exist in CSS, and components composed in Figma that have no implementation. At that point the Figma file and the codebase are two systems sharing a name.

The design half of the toolchain solves this. A canonical token source authored once (in our case, DTCG-in-YAML). Projections to every surface that needs them: CSS, Figma variables, DESIGN.md for AI agents. Round-trip between design tool and code through a 3-way merge with per-group ownership. ViewComponent and Code Connect bindings so built components in code map to built components in Figma. Proposed components rendered as labeled placeholders in the design tool until they ship in code.

Nobody is building this as broadly as Marco is building the code half. The pieces exist in fragments: Tokens Studio, Style Dictionary, Figma's Code Connect, DESIGN.md and the Google Labs initiative. Nobody has assembled the full toolchain with Rails-specific opinions: ViewComponent and Phlex as targets, ERB partials as outputs, the connection to the broader Rails view layer.

We are building that inside Talos. The full case study lands when the system reaches Phase 3 lockdown (estimated mid-2026). The architecture is in a Field Note: Why DESIGN.md doesn't survive contact with a real design system.

For most of Rails history, the view layer was the renderer. ERB templates plus partials plus helpers. The team wrote templates by hand. Designers handed off comps. The translation from Figma to ERB happened in someone's head.

That worked at small scale. It does not work at scale, and it has not worked for several years for teams that take design seriously. The design system layer became necessary, and the code-tooling layer became necessary, and neither layer existed in coherent form.

AI coding agents make both layers load-bearing. The agent reads the codebase, picks a button component, ships. If the codebase has three button components and no system, the agent ships the wrong one. If the design system exists in Figma but not in code that the agent can read, the agent ignores it. If the design system exists in code but the AST is regex-parsed strings, the agent can read the file but cannot reliably modify it without breaking the template syntax.

Both halves of the toolchain need to be real for AI agents to do the work safely.

The code half makes the templates structured and modifiable. The design half makes the components canonical and bindable. Together they make the view layer the kind of place where an AI agent can read the system, understand the components, modify the template safely, and ship.

Marco is building the code half. The design half is the other half. They meet at the place where the designer's components and the developer's templates are the same thing.

Four seams.

Code Connect bindings. Built components in Figma map to built components in code. When Marco's parser identifies a ViewComponent in an ERB template, the Code Connect mapping should tell us which Figma component it represents and what variants exist. The parser and the design tool are looking at the same component from two sides.

Token references. When the linter sees a hardcoded color in a template, it should know what the design system's token for that color is and offer to substitute. This requires the linter (Marco's half) to know about the token canonical (the design half). Both halves point at the same token source.

Component proposals. When a designer composes a new component in Figma that does not yet exist in code, the design tool marks it as proposed. The code-side tooling should be able to read those proposals from DESIGN.md or a manifest and scaffold the ViewComponent. The two halves close the loop on net-new component creation.

AI agent grounding. When an AI agent writes a new template, it should reach for components from the system, use tokens from the canonical, and respect the patterns the linter would enforce. The agent reads the parser AST (code half) and the DESIGN.md projection (design half) and writes coherent output.

None of these seams work without both halves. Marco's parser cannot suggest token substitutions if the tokens are not in a structured canonical. The design canonical cannot drive code without a parser that knows where the templates are and what they contain.

We are building the design half inside Talos right now. The Talos work is real, but it is one engagement's worth of build-it-and-find-out, not the broad ecosystem investment Marco is making on the code side. Marco's work has community traction, multiple contributors, and language bindings shipping across the ecosystem. The design half we are building is more contained.

The right framing is that both halves need to exist. Marco's work is the proof that the code half is a real category of tooling that the Rails community can adopt. The design half is still earlier. If you are reading this and working on adjacent problems (Style Dictionary for Rails, DTCG bindings to ViewComponent, Code Connect at scale), the two halves of the toolchain need to find each other.

By Rails World 2026 or RailsConf 2026, here is what the Rails view layer toolchain should look like to feel complete.

Marco's code half exists in production form. Herb in v1.0 or beyond. ReActionView shipping with the default Rails install. Language server in every major editor. Linter rules adopted as community standards. ERB safety guarantees baked into the framework.

The design half exists in some real form too. A canonical token format the Rails ecosystem agrees on (DTCG is the obvious candidate). Generated CSS or SCSS, Figma variables, and DESIGN.md projections all derived from the canonical. ViewComponent and Phlex component manifests that round-trip with the design tool. A real Code Connect story for Rails.

Both halves are pluggable, opinionated about Rails, and connected at the seams above.

That is the Rails view layer toolchain. It is bigger than what any single talk or any single piece of work can deliver. Marco's work is showing the shape of the code half. The design half is open.

The view layer Rails deserves is one where both halves exist. It is time for the design half to catch up.

Marco's talk is at https://www.youtube.com/watch?v=LRtbNgNCzp4. His writeups are at https://marcoroth.dev. The Herb project is at https://github.com/marcoroth/herb.