What happens when you try to bring single-page-app speed and interactivity into Rails without piling on React or Vue?
For Nolan Alimonti and Daniel Cannon, the answer lies somewhere between a desire to write less JavaScript, a need for maintainable code, and a willingness to wrestle with Turbo’s quirks to get there.
In this episode of SaaS That App: Building B2B Web Applications, Nolan Alimonti (Development Team Lead at Delta) and Daniel Cannon (Chief Innovation Officer at Delta) join hosts Aaron Marchbanks and Justin Edwards for a deep dive into Turbo, Stimulus, and Hotwire and how they’re reshaping Rails development for better (and sometimes, for more complicated).
Turbo Without the Hype
Turbo promises the best of both worlds: the snappy feel of a single-page app without forcing Rails developers to drag in React, Vue, or another heavy front-end framework. Instead of reloading an entire page every time someone clicks, Turbo quietly swaps out pieces of content, making apps feel faster and more interactive without all the extra weight.
For Nolan Alimonti and Daniel Cannon, that shift is more than a technical tweak; it’s a mindset change. Turbo lets their team do a lot more with a lot less JavaScript, leaning back into Rails’ server-side rendering roots while still giving users the seamless, modern experience they expect. But as Nolan points out, writing less JavaScript doesn’t mean there’s less work to do; it just changes where that work happens.
Less JavaScript, More Thinking
Using Turbo means you won’t be writing endless lines of custom JavaScript, but you also won’t be off the hook for complexity.
Rather than giant, messy scripts, modern Turbo apps use small, reusable pieces of Stimulus code “sprinkled” across the application. This makes for a cleaner, more maintainable codebase and dramatically reduces the old jQuery-style bloat that used to creep into Rails projects.
But that simplicity at the surface comes with a trade-off: developers have to think more deeply about architecture from the start. Building with Turbo means planning how all those small components fit together, and that takes real forethought and discipline.
The Learning Curve
Turbo isn’t plug-and-play. For many developers, it’s a mindset shift. The Rails philosophy of “convention over configuration” is embedded in how Turbo works, which means a lot happens behind the scenes. For newcomers, that can feel like stepping into an unfamiliar maze. When something breaks, the issue isn’t always obvious, and traditional debugging habits don’t always apply.
For seasoned Rails developers, Turbo eventually “clicks,” but there’s an initial learning curve where even simple tasks feel strange. Stimulus introduces its own new patterns, and developers used to direct DOM manipulation have to unlearn old reflexes before Turbo starts to feel natural.
Not the Right Fit for Every Project
Turbo can make Rails apps faster and cleaner, but it isn’t the right tool for every scenario. Because Turbo triggers a network request for almost every user action, scaling becomes a consideration. A typical Rails app might handle this easily, but if you’re running a platform with hundreds of thousands or millions of concurrent users, those constant requests can pile up quickly.
Turbo also isn’t built for every kind of app. For projects that demand highly complex, ultra-interactive experiences, think Canva-level interfaces; a full single-page app may still be the better path. Turbo works best where Rails has always shone, structured, business-focused apps where maintainability and speed of development matter most.
Rails Defaults Are There for a Reason
Despite the trade-offs, Turbo and Stimulus aren’t fringe experiments; they’re the new Rails defaults.
For developers starting fresh, that matters. Choosing to bypass Turbo now isn’t just about writing a bit more JavaScript; it means intentionally stepping away from the direction Rails itself is moving. That’s not inherently wrong, but it’s not a casual decision either.
For Nolan and Daniel, this is the future of Rails development: fewer front-end frameworks, more server-side power, and a codebase that feels cohesive rather than bolted together.
Building Rails Apps the Turbo Way
Turbo changes how you think about building in Rails. It’s not just about writing less JavaScript; it’s about using the framework’s new defaults wisely. Nolan and Daniel highlighted a few principles that make Turbo projects succeed:
- Keep JavaScript light and reusable. Turbo isn’t about zero JavaScript; it’s about “sprinkling” small Stimulus controllers where they’re needed.
- Plan architecture early. Cleaner codebases only happen when you think about how those small pieces fit together from the start.
- Respect the Rails conventions. Turbo relies heavily on Rails’ “convention over configuration” mindset. Ignore those patterns, and you’ll get lost fast.
- Know when to stop. Turbo isn’t right for everything. If your app needs extreme interactivity or will operate at a massive scale, there’s a point where a single-page app is still the smarter choice.
Final Thoughts
Turbo is not hype. It’s not a passing trend. And it’s not effortless. It’s the next step in Rails’ evolution, a way to make apps feel modern and fast without drowning in JavaScript. But like anything worth doing, it takes thought. Developers have to plan, learn, and sometimes wrestle with new conventions before the payoff appears.
For teams willing to make that investment, Turbo offers something powerful: Rails apps that feel fresh and fast, with codebases that stay clean and manageable over time.
Nolan Alimonti Background
Nolan Alimonti is Development Team Lead at Delta Systems, where he tackles complex client projects by uniting front-end speed with backend clarity. With deep experience in React and Ruby on Rails, he’s known for simplifying messy codebases, improving scalability, and steering apps toward cleaner, maintainable architecture. A hands-on specialist in modern Rails development, Nolan has led significant refactors, helping teams migrate from TurboLinks-era code to sleek, serviceable Turbo and Stimulus builds. His goal is to make apps snappier and smoother, while keeping the stack lean and intentional.
Daniel Cannon Background
Daniel Cannon is the Founder of Strive DB and Chief Innovation Officer at Delta Systems, where he drives the adoption of emerging technologies and modern development practices across the organization. A senior developer with a history of tackling thorny technical challenges, Daniel has a knack for questioning assumptions, stress-testing ideas, and finding pragmatic ways to turn cutting-edge tools into everyday solutions. His perspective on Turbo, Stimulus, and Rails comes from hands-on experience shaping how these tools are used in real-world applications and mentoring teams through the learning curve.
Listen to the new episode on: