
Sign up to save your podcasts
Or


What if you could keep Rails pages fast, accessible, and SEO‑friendly, yet still get modern interactivity without shipping a mountain of JavaScript? We sit down with Cameron Dutro to unpack Live Component, a server‑first approach that breathes life into ViewComponent by treating state as data, rendering on the server, and morphing the DOM with Hotwire. No fragile ID wiring. No React by default. Just clear state, small payloads, and focused updates.
We trace the path that led here: experiments rendering Ruby in the browser with Ruby.wasm, Opal, and even a TypeScript Ruby interpreter, and why those payloads and debugging pain pushed the work back to the server. Cameron explains the Live Component mental model—initializer‑defined state, slots, and a sidecar Stimulus controller—plus how targeted re‑renders make forms and micro‑interactions feel instant. We talk transports (HTTP vs WebSockets), serialization best practices for Active Record data, and where React still shines for high‑intensity builders and editors.
Beyond the code, we dig into the bigger web story: how DX‑first choices often punish users on slower devices and networks, and why a balanced, server‑driven approach can close that gap. You’ll hear real‑world tradeoffs, debugging techniques that feel like home to Rails devs, and a clever fix born from a Snake game that surfaced timing issues and led to a preempt option for queued renders. If your team wants dynamic islands without adopting a full SPA, this conversation offers a practical roadmap.
Explore Live Component at livecomponent.org and the GitHub org at github.com/livecomponent. If this resonated, follow, share with a Rails friend, and leave a review so more builders can find it.
Send us some love.
Judoscale
Autoscaling that actually works. Take control of your cloud hosting.
Support the show
By Drew Bragg5
66 ratings
What if you could keep Rails pages fast, accessible, and SEO‑friendly, yet still get modern interactivity without shipping a mountain of JavaScript? We sit down with Cameron Dutro to unpack Live Component, a server‑first approach that breathes life into ViewComponent by treating state as data, rendering on the server, and morphing the DOM with Hotwire. No fragile ID wiring. No React by default. Just clear state, small payloads, and focused updates.
We trace the path that led here: experiments rendering Ruby in the browser with Ruby.wasm, Opal, and even a TypeScript Ruby interpreter, and why those payloads and debugging pain pushed the work back to the server. Cameron explains the Live Component mental model—initializer‑defined state, slots, and a sidecar Stimulus controller—plus how targeted re‑renders make forms and micro‑interactions feel instant. We talk transports (HTTP vs WebSockets), serialization best practices for Active Record data, and where React still shines for high‑intensity builders and editors.
Beyond the code, we dig into the bigger web story: how DX‑first choices often punish users on slower devices and networks, and why a balanced, server‑driven approach can close that gap. You’ll hear real‑world tradeoffs, debugging techniques that feel like home to Rails devs, and a clever fix born from a Snake game that surfaced timing issues and led to a preempt option for queued renders. If your team wants dynamic islands without adopting a full SPA, this conversation offers a practical roadmap.
Explore Live Component at livecomponent.org and the GitHub org at github.com/livecomponent. If this resonated, follow, share with a Rails friend, and leave a review so more builders can find it.
Send us some love.
Judoscale
Autoscaling that actually works. Take control of your cloud hosting.
Support the show

34 Listeners