From React to Rails: Building the Sileo-Rails Gem with Codex

I found Sileo in a tweet by @midudev: a React toast library with smooth animations and a clean API. My stack is Rails with Propshaft, not React, so I used it as an excuse to learn Codex as a pair programmer and rebuild it as a Rails gem called Sileo-Rails, on top of Stimulus. It took a lot of back and forth.

Generate TL;DR ✨

TL;DR

Why Clone a React Library into Rails?

The Rails ecosystem has toast notification gems, but none matched the polish and simplicity of Sileo's API. Most need too much configuration or produce notifications that feel dated. Sileo's approach (declarative, minimal setup, good defaults) was exactly what I wanted.

I could have wrapped the React component and shipped it that way. But that means adding React to my asset pipeline, managing npm dependencies, and running a React runtime for a single UI component. That's not the Rails way, and it doesn't sit well with Propshaft.

So the question was whether I could keep Sileo's design and API ergonomics while making it feel native to a Rails + Stimulus stack.

What Codex Actually Helped With

I pointed Codex at the original Sileo repository and asked it to analyze the component structure, animations, and API surface. Within minutes I had a breakdown of the CSS keyframe animations and their timing functions, the React component props and their defaults, the state management for the toast lifecycle (enter, active, exit), and the positioning logic for stacking multiple toasts.

Codex then generated an initial Stimulus controller with the core animation logic translated to vanilla JavaScript. It handled the DOM manipulation for creating, positioning, and removing toast elements. The CSS animations went from React's styled-components to plain CSS that works with Propshaft's asset pipeline.

Good, right? Not quite. Codex used yarn and reached for a more complicated setup than a modern Rails 8.1 app needs. That part was easy to fix. The harder part was getting the visual rendering and the behavior right, and that took multiple iterations and human judgment.

Where Codex really shined was the repetitive work: generating the gem structure, writing the Railtie for automatic integration, creating the helper methods for the view layer, and building the configuration DSL. These are well-understood patterns in the Rails ecosystem, and Codex handled them competently. Later it produced all the scaffolding and documentation to publish the gem to RubyGems.

What Still Required Engineering Judgment

Codex's first draft worked, but it wasn't quite right, and the gaps were the kind only a human catches.

The animation timing felt off. The CSS was technically correct but didn't feel as smooth as the original. I had to adjust the cubic-bezier timing functions and fine-tune durations, watching the animation over and over and making micro-adjustments. Subjective work, no way around it.

The DOM structure and styling didn't match Sileo's, and I couldn't get it to respond the way I wanted, so eventually we recreated the whole thing from scratch. Stacking was another one: multiple toasts had to stack without overlapping, and Codex's initial logic didn't account for dynamic height changes when toasts carried different content lengths.

Memory management was easy to miss. The original React component leans on React's unmount lifecycle. In Stimulus I had to make sure controllers disconnected properly and event listeners got removed. Not hard, but the kind of thing that bites you later.

On API ergonomics Codex did well: it proposed a Ruby API that worked, and I never touched a single line of Ruby to build the demo site.

These were blockers because a polished library lives in the details. Codex accelerated the first 80%; the last 20% still needed my eye and took me several hours to get right.

Why Stimulus Was the Right Fit

Stimulus isn't trying to be React. No virtual DOM, no complex state, no pretense of being a full application framework. What it does is connect JavaScript behavior to HTML elements in a way that feels natural in a Rails app.

For toasts that's perfect. They're ephemeral: they appear, maybe update once or twice, and disappear. They don't need complex state management. They need a way to be triggered from the server (flash messages) or the client (JavaScript calls), CSS animations for the enter and exit transitions, and DOM manipulation for positioning and removal.

The resulting gem, sileo-rails, feels native to Rails. Install it, add the helper to your layout, and call toast.success from anywhere. No React, no webpack, no npm install.

What This Says About AI-Assisted Development

This project reinforced something I keep noticing: AI is great at translation, not design. Codex could read React code and produce equivalent JavaScript, generate a gem structure that followed Rails conventions, translate component props into Ruby method signatures. All translation work, and it did it well.

What it couldn't do was make judgment calls about feel, ergonomics, or fit. Is this animation smooth enough? Does this API feel natural to a Ruby developer? Is this the right abstraction for a Rails gem? Those questions need context and taste that Codex doesn't have.

The pattern that works for me: use AI for the mechanical translation, then apply human judgment for the refinement. Trying to prompt-engineer your way to a perfect first draft takes longer than just iterating by hand on the parts that matter.

I don't think better models fix this. Taste isn't something you can encode in a prompt. You develop it through use, feedback, and iteration. The AI produces options; someone still has to choose.

Closing

sileo-rails is on GitHub and RubyGems. Small project, but it captures something I value: using AI to go faster on implementation while keeping ownership of the design decisions.

If you work with Rails and want toast notifications without dragging React into your stack, give it a try. Thanks to Aaryan for the original Sileo library and the design inspiration that made it worth rebuilding in Rails.