At Evil Martians, we advocate and build for startups on Rails, and we also know Ruby and Rails give teams a productivity boost and competitive edge. However, we’re also aware of what these startups struggle with the most: frontend. In this post, we share our “silver toolkit” for dealing with it!
The overarching frontend story of Rails feels like the classic One Thousand and One Nights, an epic tale compiled over hundreds of years (in other words, it’s not a short one).
Irina Nazarova CEO at Evil Martians
But it only takes 6 words to tell the frontend story for Rails in 2025. And those 6 words? “Cooling down Hot Wires with Inertia.” That little story serves as a better touchpoint for startup teams, those both lean and meticulous.
At Evil Martians, we advocate and build for startups on Rails–these are small teams making a huge impact by building superior products—and winning markets with them. We know exactly why startups choose Rails (see my keynote)—despite the lack of buzz. We also know how Ruby and Rails give teams a productivity boost and competitive edge.
But we also know what these startups struggle with the most: frontend.
So, we’ve spent the last 2 years searching for the next frontier of productivity for Rails frontend: trying out tools, gems, patterns, working with dozens of customers, and building and contributing to open source.
Today, we’re finally ready to present that solution!
Diverting from the mainstream?
To the outside observer, it may seem strange we’re suggesting something different from what is officially there on rubyonrails.org, but for a company that’s been deeply integrated into the Ruby community for 18 years, this proposal is actually sound.
Importantly, it is aligned with the Rails Doctrine–the big tent. After all, Rails is uniquely designed to integrate alternative solutions to almost every key part of the framework–and in a nice way.
This design principle, and the ongoing competition between the official and the alternative (remember MySQL vs. Postgres?), is a major source of adaptability of Rails, and its success!
Having said that, choosing an alternative path does require something from us: trust in the vision of the alternative maintainers.
Now, this is where we can put modesty aside and say that if you are a fast-paced small team, looking to conquer the world, you can trust our judgement: we’ve helped clients from the best teams with some of the hardest problems out there, doing weeks or years-long projects, bringing them from Seed to later stage and IPO, learning from our missteps, building widely used open source solutions, and extending Rails in the most maintainable way possible.
(In fact, we wrote a book about it (“Layered Design for Rails applications”) which is in the top-3 recommended books in Rails Community Survey 2024!)
Now let’s cut to the chase.
A silver toolbox
Here’s the little catch: we don’t have a silver bullet! But we do have a silver toolbox. Frontend tasks are so diverse in nature that reaching more optimal productivity, the next frontier, is achieved not just with one tool, but with a combination of tools. Let’s talk about them, and how to make the appropriate selections.
Tool #1: Hotwire/Turbo frontend for simple/CRUD pages
The new mainstream, HTML-over-the-wire frontend, powered with View Component, or Phlex, is the most productive approach to build pages that have two characteristics:
- They can delegate state management to the server. These include simple CRUD pages, most admin panels, wizards and any screens where there is little entanglement between the user’s actions and the state of multiple elements on the page.
- They don’t look like an already existing complex component from the React/Svelte/Vue ecosystem. This is because building something that already exists is sub-optimal. (More on that later.)
Here is an example of a Hotwire frontend: a music app called Turbo Music Drive. Take a second to watch in action:
We built it as an exploration into the limits of Hotwire: seeing how far we could go with inter-dependent actions and updates while staying productive.
Now, this is roughly the limit of where you want to go with Hotwire, because we can simplify it by using our next tool. We can apply a cooling solution before the wires—those in Turbo and also those inside our brain—get overheated.
Tool #2: Turbo Mount for a standalone React/Svelte/Vue component
Paradoxically, all you need to stay productive with Hotwire is the ability to elegantly escape from it when needed! Even in a perfectly wired Turbo app, some components can start overheating with more complex reactive requirements. That’s when it’s best to cool things down by building that specific piece in React, Vue, or Svelte and mounting it into your Turbo-powered view using our open source tool, Turbo Mount.
Turbo Mount allows you to introduce the frontend framework of choice on a very granular, component level. Turbo Mount creates a clean bridge between Rails views and modern JavaScript components. It handles all prop passing and lifecycle events automatically, letting you seamlessly embed React/Vue/Svelte components into your Hotwire-powered pages.
Here is an example where we replaced the player in Turbo Music Drive with an existing React component using Turbo Mount. The key benefits of this approach were:
- We use an existing library component
- We end up having a lot less custom JS code (compare player_controller.js and Player.tsx)
- The component’s code is now isolated cleanly in one place (instead of _player.html.erb and player_controller.js)
- We only have 50 lines of React and TS thanks to Turbo Mount
The limitation of this approach is obviously that the reactivity of our UX is bounded by the component. But as soon as we feel the need for a full page reactive SPA, we can use our next tool.
Tool #3 Inertia for React/Svelte/Vue SPA where you need it
When you see the temperature rising—multiple components getting tangled in complex state management and the whole page needing reactivity—it’s time for Inertia.js to take control. It lets you build single-page applications (SPAs) with Rails and your favorite frontend framework (React, Vue, or Svelte), all without the overhead of a separate API.
The key benefit of using Inertia on Rails is seamless integration with your existing Rails application. When using Inertia, there is no need for a separate API layer, you can use familiar routing patterns and controllers. The only component that changes is your views.
Whenever you’re building a complex dashboard with multiple interdependent widgets, real-time updates, and sophisticated state management or something similar, Inertia lets you leverage the full power of modern frontend frameworks while keeping the simplicity and conventions of Rails.
You can find the Inertia version of Turbo Music Library here. You can see that the backend logic and code stay almost the same. At the same time, our UI is now powered by React and its reactivity. We use React the way it’s meant to be used: as a view layer library (not a multi-functional frankenstein with routes, API, complex stores, etc.).
This approach gives us an opportunity to leverage the rich frontend ecosystem and tooling, delegate the UI/UX work to the frontend team (or AI, such as Bolt), and let Rails focus on what it does the best—your app’s business logic. Technically speaking, we can eliminate a good portion of HTTP round-trips and rely on the local state where possible. For example, in our music player we don’t need to make HTTP requests to update the player’s state (play another song):
We can go further and make this symbiotic relationship even stronger by introducing type system stitches via Typelizer (one can hardly imagine a modern frontend engineer writing anything but TypeScript).
Finally, Inertia leaves a room for a HTML-over-the-wire feel through server-side rendering support, though that would require introducing yet another tool–let’s get to it!
Tool #4 Vite Ruby: our secret ingredient
The toolbox we’re presenting today works great thanks to one secret ingredient, Vite Ruby. Vite abstracts the specific build tools (it relies on esbuild and Rollup, with Rolldown coming up) from the application level and provides fast builds, great DX and flexibility with its plugin system for whatever the future holds.
It “just works” and unlike #nobuild it doesn’t lock you out of a bunch of gems that require a build tool. Vite serves as the foundation that makes our entire frontend strategy possible, providing lightning-fast development experience and reliable production builds.
Our course, while tools are essential, they’re only valuable when backed by long-term support and evolution. That’s where our commitment comes in.
Our commitment
At Evil Martians, we don’t just build Turbo Mount, contribute to Inertia, and promote Vite Ruby everywhere just because we can–rather, we build, maintain, and actively contribute to these tools because we use them with our clients. So, we’re invested in their success and evolution.
If you are using these tools and experiencing any issues, or if you feel that something is missing, please let us know! Reach out—we’re here to help.
Moving forward
In 2025, the frontend landscape for Rails isn’t about choosing a single solution—it’s about having the right tool for each job. In that spirit, our silver toolbox approach gives you all of the following:
- Hotwire for rapid development of standard CRUD interfaces
- Turbo Mount for seamlessly integrating reactive components when needed
- Inertia for building full SPAs without sacrificing Rails conventions
This combination allows startup teams to stay lean while delivering superior user experiences. With these tools in your arsenal, you can focus on what matters most—building features that delight your users and grow your business.
Don’t let things get too hot–stay cool this winter–and when something is slowing you down, reach out to us for a boost of productivity!