Rails + Inertia.js Conversion

Your Rails Views Are Holding You Back

Your Rails application works. The business logic is solid, the data layer is reliable, and your team knows the codebase. But the frontend feels dated. Page transitions reload everything. Forms lack real-time validation. Users expect the responsiveness of a single-page application, and your ERB templates can’t deliver it.

You’ve considered the obvious options, and each one has problems:

• Build a separate SPA with a REST/GraphQL API: Now you’re maintaining two codebases, two deployments, and a contract layer between them. Your Rails controllers become thin wrappers around JSON endpoints, and you lose the server-side routing that made Rails productive in the first place.
• Sprinkle in Hotwire/Turbo: Better than full-page reloads, but you’re still working within ERB’s constraints. Complex interactive UIs - dashboards, multi-step wizards, drag-and-drop interfaces - are harder to build and test.
• Rewrite in Next.js or Nuxt: You abandon the Rails ecosystem entirely. Your models, validations, background jobs, and deployment pipeline all need reimplementation. That’s a 12-18 month project with significant risk.

None of these options let you keep what works about Rails while getting the frontend experience your users expect.

Inertia.js: Rails Controllers, Modern Frontend

Inertia.js solves this by connecting your Rails controllers directly to React, Vue, or Svelte components. Your routes stay in Rails. Your authentication stays in Rails. Your business logic stays in Rails. The only thing that changes is what renders in the browser.

The controller still handles routing, authentication, and authorization. You still write Rails. But your users get instant page transitions, reactive UI updates, and the component-based architecture that makes complex interfaces manageable.

If this pattern matches what you need, schedule a free 30-minute consultation to discuss whether Inertia fits your application.

Anyway, we recommend converting Rails applications to Inertia incrementally. A big-bang rewrite introduces unnecessary risk. Instead, we work through your application section by section, keeping both the legacy views and the new Inertia pages running simultaneously.

Phase 1: Architecture Assessment

Before writing code, we evaluate your application to identify conversion boundaries:

• Which pages benefit most from a component-based UI?
• Where are the shared layouts and partials that become reusable components?
• What data serialization strategy fits your models? (ActiveModel Serializers, Jbuilder, or plain hashes)
• Does your team have existing React/Vue/Svelte experience, or do we need to recommend a framework?

This phase typically takes 1-2 weeks and produces a conversion roadmap with prioritized milestones.

Phase 2: Foundation

We set up the Inertia infrastructure so subsequent conversions are straightforward:

• Install inertia_rails gem and the JavaScript adapter for your chosen framework
• Configure a build pipeline - we recommend Vite for its speed and Rails integration
• Set up TypeScript (optional, but it catches serialization mismatches between controllers and components)
• Create base layouts, error pages, and authentication flows in Inertia
• Establish component patterns for your design system

Phase 3: Incremental Conversion

We convert views to components in priority order:

1. Static and simple dynamic pages first - these build momentum and let your team see results quickly
2. Shared UI components - buttons, forms, modals, tables that get reused across the application
3. Complex interactive features - multi-step wizards, dashboards, drag-and-drop interfaces, real-time updates
4. Optimization - code splitting with dynamic imports, lazy loading, bundle analysis

Each converted section goes through your existing test suite. We add component tests alongside integration tests so coverage stays consistent.

Phase 4: Polish

Once the core conversion is complete:

• Client-side validation that mirrors your server-side rules
• Optimistic UI updates for faster perceived performance
• Loading states and skeleton screens instead of blank pages
• Error boundaries that degrade gracefully
• Bundle size analysis and optimization

Technical Stack

While there’s quite a bit of flexibiliy, here’s a rundown of the sort of thing we recommend:

Backend requirements:

• Rails 6.0 or later (Rails 7+ preferred for import map compatibility)
• inertia_rails gem
• Data serialization via ActiveModel Serializers, Jbuilder, or manual hashes

Frontend framework options:

• React: Largest ecosystem, most available component libraries, easiest to hire for
• Vue: Gentler learning curve if your team is newer to component frameworks
• Svelte: Smallest bundle sizes, simplest syntax, but smaller ecosystem

We’ll recommend the right framework based on your team’s experience and your application’s requirements - not just what’s trendy.

Build tools:

• Vite (recommended): Fast builds, good Rails integration via vite_rails
• esbuild: Simpler configuration, fast compilation
• Webpacker/Shakapacker: Only if you’re already using it and migration cost isn’t justified

Additional tooling:

• TypeScript for catching data-shape mismatches between controller props and component expectations
• TailwindCSS if you want utility-first styling that pairs well with component architecture

Choosing a Migration Strategy

The right strategy depends on your application size, risk tolerance, and how actively you’re developing new features.

Incremental conversion works best for most applications. You convert section by section while both the legacy views and Inertia pages coexist. Users never see a broken experience. If a converted page has issues, you can roll it back to the ERB version. This is lower risk but takes longer.

Big bang conversion makes sense for smaller applications (under 30 views) or when you’re already planning a significant rewrite. It’s faster if the scope is manageable, but there’s no fallback if something breaks.

Hybrid approach - use Inertia for new features while keeping stable existing views in ERB. This works well when you’re building new functionality at the same time as modernizing. The downside is maintaining two rendering approaches indefinitely.

We’ll recommend the right approach during the architecture assessment. In our experience, most applications with 50+ views benefit from incremental conversion over 3-6 months rather than a risky big-bang migration.

Not sure which strategy fits your application? Contact us to discuss your specific situation.

Timeline and Investment

Timelines depend on application size and complexity:

• Small application (under 30 views): 1-2 months
• Medium application (30-100 views): 3-6 months
• Large application (100+ views): 6-12 months

These ranges assume incremental conversion with an active development team. If your application has significant JavaScript already (Stimulus controllers, jQuery, inline scripts), add time for migrating that logic into components.

We provide both frontend and Rails expertise. If your team has JavaScript experience, we can work alongside them - converting the architecture while they build new components. If your team is primarily Rails, we handle the full conversion and include training on the Inertia patterns and your chosen framework.

What You’ll Have After Conversion

The deliverables aren’t just a codebase swap. When we’re done, you’ll have:

• An Inertia-powered application where page transitions happen instantly and forms work without full reloads
• A component library matching your design system, documented with usage examples
• TypeScript interfaces (if applicable) that catch data mismatches between your Rails controllers and frontend components at compile time
• Test coverage maintained or improved - component tests alongside your existing integration tests
• Build configuration optimized for development speed and production bundle size
• Architecture documentation explaining the patterns, data flow, and conventions we established
• Team training so your developers can maintain and extend the Inertia architecture independently

The goal isn’t just a conversion - it’s making sure your team owns the result and can build on it without calling us for every change.

Next Steps

If your Rails frontend is limiting your product, let’s talk about whether an Inertia conversion makes sense for your situation. We’ll review your application’s architecture, discuss the trade-offs specific to your codebase, and give you an honest assessment of scope and timeline.

Schedule a free 30-minute consultation. We’ll help you understand your options - whether or not we work together.

Have questions first? Contact us and we’ll respond within two business days.