I keep seeing startups build web applications with Rails, Turbo, and Hotwire, and I'm struggling to understand the appeal. The approach feels overly dependent on server-rendered HTML and forms, with lots of manual coordination between templates, backend responses, and small Stimulus controllers. Compared with more browser-focused frontend frameworks, it seems less flexible, potentially slower for interactions that could happen entirely on the client, and harder to scale cleanly as the application grows. Is the main advantage development speed, hiring, maintainability, or simply familiarity with the Rails ecosystem?
4 Answers
Turbo works well when the application is mostly server-backed CRUD and the team wants to ship quickly with minimal JavaScript. It fits the Rails philosophy: keep the browser relatively thin, let the server handle most state, and avoid maintaining a separate frontend application. That tradeoff is much less attractive for highly interactive products, where a client-heavy framework gives you more control over UX and performance.
For startups, the practical benefits are usually speed, talent availability, and having fewer specialized roles. A Rails developer can build a working MVP quickly without a separate frontend and backend team. The choice isn’t necessarily that Turbo is the best tool for every interface; it’s that it can reduce the amount of infrastructure and coordination needed early on.
Before AI-assisted development became common, Rails was especially popular for getting an MVP from idea to production quickly.
Hotwire means Turbo plus Stimulus, and they don’t have to be used equally. Turbo can handle navigation, partial page updates, and server-rendered workflows, while Stimulus is best kept for small pieces of browser behavior. A common mistake is putting too much application logic into Stimulus controllers, which makes the overall design feel much more complicated than intended.
Even when you keep Stimulus small, you still end up working around browser behavior, splitting logic across templates and controllers, and sending requests for interactions that a client-side framework could handle locally. That’s where the tradeoff becomes frustrating for frontend-heavy applications.
The right answer depends heavily on the product. Turbo and Hotwire are comfortable and productive for conventional server-driven applications, but they aren’t automatically a good fit for complex, highly interactive interfaces. Alternatives such as Phoenix LiveView or a modern client-side framework may provide a cleaner experience for teams that prioritize richer browser interactions. Also, jQuery itself isn’t inherently terrible—it’s old, and it can become messy when used for uncontrolled DOM manipulation or callback-heavy code, but poor usage is not entirely the library’s fault.
That approach can be perfectly fine for simple applications, but larger products eventually expose the limits of relying on round trips for so many interactions.