Learn what Hotwire is in Ruby on Rails and how Turbo and Stimulus simplify modern, fast, interactive web applications.
• 22 min read
• 22 min read
If you have spent time in the Rails community lately, you have probably heard the word Hotwire come up in a pull request or a conversation about a fast, interactive page that somehow did not involve React. Hotwire is the reason for that, and it has quietly become one of the most important parts of modern Rails development.
In simple terms, Hotwire is an approach to building fast, interactive web applications by sending HTML from the server instead of JSON. Instead of Rails acting as an API that feeds data to a heavy JavaScript frontend, it renders HTML the way it always has, just in a smarter, more targeted way.
Hotwire matters because a lot of teams had drifted into building single page applications for products that never needed that much complexity. A blog, an admin dashboard, or a CRUD tool would end up with a full JavaScript framework, a separate API layer, and two codebases to keep in sync. Hotwire solves that by letting Rails developers build modern, responsive interfaces without carrying all that extra weight.
Hotwire is made up of two main technologies: Turbo, which handles navigation and HTML updates, and Stimulus, a small JavaScript framework for the moments when you need custom browser behavior, like toggling a dropdown or copying text to the clipboard.
By the end of this article, you will understand what Hotwire is, how Turbo Drive, Turbo Frames, and Turbo Streams work together, when Stimulus fits in, and how to combine all of it to build real, interactive Rails 8 features.
Hotwire stands for HTML Over The Wire. Instead of your server sending JSON that JavaScript interprets and turns into HTML, your Rails app sends HTML directly, and the browser displays or swaps it into place.
Hotwire is the default frontend approach for new Rails applications. When you generate a Rails 8 project, Turbo and Stimulus are included automatically, which tells you how central this approach has become to the framework.
The main components are:
Hotwire lets developers keep most application logic on the server, where Rails is strongest. Validations, business rules, and data access stay in Ruby, and the browser's job shrinks to displaying HTML and reacting to small, well-defined interactions.
Hotwire is technology-agnostic and could work with other backends, but it was built by the Rails team at 37signals and pairs naturally with Rails conventions like partials, views, and controllers.
One thing worth being clear about early: Hotwire is not a replacement for JavaScript. You will still write JavaScript when you need custom browser behavior. Hotwire just reduces how much of it you need and how much state you have to manage on the client.
To understand why Hotwire matters, look at the problems that had become common before it existed.
Teams shipped huge JavaScript bundles just to render pages that were mostly static content, which hurt users on slower connections. Frontend state management became its own specialty, keeping a client-side store in sync with the server through loading states, caching, and re-fetching. Many apps ended up with a full JSON API even when nothing outside the app's own frontend consumed it, which meant writing serializers and client code to consume them. Business logic often got duplicated between frontend and backend, since a validation rule might need to exist both in the Rails model and in JavaScript for instant feedback. Teams built single page applications for products that never needed one, like a blog or an internal admin panel. And many ended up maintaining two separate applications: a Rails API and a JavaScript frontend, each with its own deployment pipeline and specialists.
Hotwire offers another path: interactive, modern-feeling applications with one codebase, one primary language for core logic, and a much smaller JavaScript footprint. It removes a lot of unnecessary complexity for the many applications that are fundamentally server-rendered with pockets of interactivity.
Hotwire keeps the traditional Rails request and response cycle, but makes it smarter.
The key idea is that HTML returned from the server can progressively update part of a page instead of forcing a full reload.
A simple example: a user clicks "Load more" on an article list. Instead of reloading the page, the browser sends a request, Rails renders just the new batch of articles, and Turbo appends that HTML to the list. No blank page flash, no lost scroll position, and no custom JavaScript state management required.
Turbo breaks down into three tools:
Alongside these, Stimulus handles JavaScript behavior that doesn't fit into HTML updates, like toggling visibility or wiring up a third-party library.
Turbo is responsible for most navigation and HTML updates; Stimulus steps in only when you need custom, client-side behavior. Keep this division in mind as we go deeper into implementation.
Turbo Drive works automatically with almost no code. It intercepts link clicks and form submissions and handles the resulting page load with JavaScript instead of a full browser refresh.
Benefits include faster navigation, since the browser doesn't reparse every stylesheet and script; partial page updates, because Turbo Drive merges the new head and swaps just the body; a preserved application shell, so elements like a persistent sidebar aren't interrupted; fewer full-page reloads; working browser history, including back and forward; and form submissions handled the same intercepted way, including redirects.
In a Rails 8 app with the default setup, Turbo Drive is already active:
<%= link_to "View Article", article_path(@article) %>
Clicking that link won't trigger a full reload; Turbo Drive fetches the page in the background and swaps it in. To opt out for a specific link, such as a file download:
<%= link_to "Download PDF", article_pdf_path(@article), data: { turbo: false } %>
The practical impact is real: a traditional Rails app, without touching a controller or view, can feel noticeably faster simply because Turbo Drive is on by default. It doesn't turn your app into an SPA; it just removes the overhead of full page reloads for ordinary navigation.
Turbo Frames scope updates to one section of a page instead of the whole document. This unlocks patterns that used to require custom JavaScript, like inline editing or self-contained page sections.
They're useful for updating part of a page without affecting the layout, independent sections that refresh on their own, inline editing, modal dialogs, search results, pagination, and forms that re-render with validation errors in place.
Here's an editable article title:
<%= turbo_frame_tag "article" do %>
<h1><%= @article.title %></h1>
<%= link_to "Edit", edit_article_path(@article) %>
<% end %>
When a user clicks "Edit," Turbo looks for a matching turbo-frame id="article" in the response and swaps only that content:
<%= turbo_frame_tag "article" do %>
<%= form_with model: @article do |form| %>
<%= form.text_field :title %>
<%= form.submit "Save" %>
<% end %>
<% end %>
The server responds with HTML targeted to the frame, and Turbo replaces just that section, leaving the rest of the layout untouched.
For a deeper look at Turbo Frames, including lazy loading and targeting frames from outside their boundaries, CodeCurious has a full article on how Turbo Frames work in Ruby on Rails.
Turbo Streams update multiple parts of a page at once, using a small set of defined actions: append, prepend, replace, update, remove, before, and after.
Example: submitting a new comment should add it to the list and update the count in one request.
Controller:
def create
@comment = @article.comments.create(comment_params)
respond_to do |format|
format.turbo_stream
format.html { redirect_to @article }
end
end
create.turbo_stream.erb:
<%= turbo_stream.append "comments", partial: "comments/comment", locals: { comment: @comment } %>
<%= turbo_stream.update "comment_count", @article.comments.count %>
That single response appends the new comment and updates the counter, with no full reload and no custom JavaScript. Turbo Streams shine for creating comments, updating notification badges, removing records after a delete, updating counters, and other live UI changes. The server decides what changed, and it sends back a precise set of instructions for how the DOM should update.
Stimulus is Hotwire's JavaScript half, for moments when HTML updates alone aren't enough. It's intentionally modest: instead of managing an entire app's state, it attaches small, reusable controllers to HTML that already exists.
Stimulus is built around controllers (JavaScript classes connected through data-controller), targets (specific elements referenced in your JavaScript), actions (declarative event listeners like data-action="click->clipboard#copy"), values (typed data passed from HTML), and classes (configurable CSS class names).
A clipboard controller:
// app/javascript/controllers/clipboard_controller.js
import { Controller } from "@hotwired/stimulus"
export default class extends Controller {
static targets = ["source"]
copy() {
navigator.clipboard.writeText(this.sourceTarget.value)
}
}
<div data-controller="clipboard">
<input data-clipboard-target="source" type="text" value="<%= @article.url %>" readonly>
<button data-action="click->clipboard#copy">Copy Link</button>
</div>
This is small and self-contained. It doesn't manage global state or fetch data; it reacts to one event and does one thing. Stimulus is useful for toggling a menu, validating a field as the user types, or integrating a third-party library, without requiring a full JavaScript application.
Turbo is appropriate for: page navigation, server-rendered updates, scoped sections through Frames, multi-part DOM updates through Streams, and form submissions.
Stimulus is appropriate for: dropdown menus, modal open and close behavior, tabs switching content already on the page, drag and drop, clipboard actions, browser APIs, and small interactive behaviors that don't need a server round trip.
A useful test: does this change need new data from the server, or is it a purely visual adjustment? Data means Turbo; a visual toggle or browser API means Stimulus. In practice, most non-trivial features use both. A modal might be opened by Stimulus, but its content loaded from the server through a Turbo Frame.
Let's build a comments feature step by step: display, add, update, remove, and a live count.
Display, inside a frame:
<%= turbo_frame_tag "comments" do %>
<div id="comments_list"><%= render @article.comments %></div>
<span id="comment_count"><%= @article.comments.count %></span>
<% end %>
A comment form:
<%= form_with model: [@article, Comment.new] do |form| %>
<%= form.text_area :body %>
<%= form.submit "Post Comment" %>
<% end %>
Creation, via Turbo Stream:
def create
@comment = @article.comments.create(comment_params)
respond_to do |format|
format.turbo_stream
format.html { redirect_to @article }
end
end
<%= turbo_stream.append "comments_list", partial: "comments/comment", locals: { comment: @comment } %>
<%= turbo_stream.update "comment_count", @article.comments.count %>
Deletion, the same way:
def destroy
@comment.destroy
respond_to do |format|
format.turbo_stream
format.html { redirect_to @article }
end
end
<%= turbo_stream.remove @comment %>
<%= turbo_stream.update "comment_count", @article.comments.count %>
No Stimulus controller is even needed here, since everything is a server-driven HTML update, a good illustration of how far Turbo alone carries you before custom JavaScript enters the picture.
Hotwire doesn't change how you think about controllers. Standard actions still respond with HTML, and Turbo just adds another format alongside it: the Turbo Stream.
def update
if @article.update(article_params)
respond_to do |format|
format.turbo_stream
format.html { redirect_to @article }
end
else
render :edit, status: :unprocessable_entity
end
end
Rails detects a Turbo request and, if a matching .turbo_stream.erb template exists, renders it instead of a full page. Redirects still work as expected, followed by Turbo Drive the same way a normal navigation would be. This means developers often don't need separate API endpoints for Hotwire interactions; the same action handles both a normal and a Turbo-enhanced submission.
Hotwire relies heavily on Rails views and partials, which is part of why it feels so natural in an existing codebase. Partials remain the unit of reuse: the same comment partial rendered on a full page can be reused inside a Turbo Stream response. Turbo Frames are just HTML tags, so they drop directly into existing ERB templates. Turbo Stream templates describe DOM changes declaratively through the turbo_stream helper.
<%# app/views/comments/_comment.html.erb %>
<div id="<%= dom_id(comment) %>">
<p><%= comment.body %></p>
<%= link_to "Delete", article_comment_path(comment.article, comment), data: { turbo_method: :delete } %>
</div>
This partial is rendered on the initial page load and reused inside create.turbo_stream.erb. The dom_id helper is what lets Turbo later target and remove that specific element. Reusable partials keep markup in one place, so a layout change applies everywhere, whether through a full page load or a stream update. That's progressive enhancement in action: HTML is the foundation, and Turbo adds behavior on top without duplicating structure.
Forms are where Hotwire has the biggest impact on user experience, since submissions used to require the most custom JavaScript. A standard form_with already benefits from Turbo Drive. For more control, wrap the form in a Turbo Frame or respond with a Turbo Stream.
Validation errors are handled gracefully: if a form inside a Turbo Frame is submitted and the server re-renders it with errors, Turbo replaces the frame's content automatically.
<%= turbo_frame_tag "new_article" do %>
<%= form_with model: @article do |form| %>
<% if @article.errors.any? %>
<ul>
<% @article.errors.full_messages.each do |message| %>
<li><%= message %></li>
<% end %>
</ul>
<% end %>
<%= form.text_field :title %>
<%= form.submit "Save" %>
<% end %>
<% end %>
Redirects after a success still work inside a frame, or you can respond with a Turbo Stream to update other parts of the page, like adding a new record to a list while closing an open modal. Inline forms and modal forms both follow the same pattern: the form lives inside a frame or is targeted by a stream, and the server's response decides what happens next, all without a separate frontend application.
Hotwire fits naturally with create, read, update, and delete flows. For create, a new record form can live in a frame, and a successful submission can append the record to a list via a stream. For read, frames make it easy to load record details without a full navigation. For update, inline editing lets a user edit a field in place and see it reflected immediately. For delete, a link can trigger a stream that removes the element and updates related counts, all in one request.
Across all four, the pattern stays the same: frames scope where updates happen, and streams describe what changes. That consistency is one of Hotwire's biggest strengths for admin panels, dashboards, and content management interfaces.
Turbo Streams aren't limited to responding to the current user's own request. They can be broadcast to other connected browsers using Action Cable, which is how Hotwire supports real-time features like live notifications, comments appearing for every visitor on an article, chat interfaces, and dashboards updating as new data arrives.
Conceptually: when a comment is created, Rails can broadcast a Turbo Stream append action to a channel every visitor on that page is subscribed to. Each browser receives the same HTML update and applies it automatically, with no polling or custom WebSocket handling in the frontend. This won't turn into a deep Action Cable tutorial, but it's worth knowing that the same append, update, and remove actions you use for a single request are exactly what powers these broadcasts. Only the trigger changes, from a direct response to a model callback or background job.
In a traditional setup, a lot of JavaScript is needed just to fetch data, manage loading and error states, and render updates on the client. With Hotwire, most of that logic stays in Rails, and JavaScript drops significantly. Server-side rendering is central, versus a typical SPA rendering after fetching JSON. Application complexity is usually lower for CRUD-heavy apps, since there's no separate client-side data layer. State management is largely avoided, since the server is the source of truth. Development speed often favors Hotwire for Rails teams, with no context switching between codebases. Maintenance is simpler with fewer moving parts, though large apps still need discipline. Performance differs: Hotwire ships less JavaScript up front, though a fully loaded SPA can feel snappier for very complex, stateful interactions. Team skill requirements shift toward Ruby expertise rather than deep JavaScript specialization.
Hotwire does not eliminate JavaScript; it changes how much you write and where it lives, shifting the balance toward the server.
Hotwire is a strong alternative to React in several situations: server-rendered applications, CRUD-heavy apps, dashboards and internal tools without extremely complex interactivity, content-heavy sites like blogs, and applications with modest client-side state that mostly comes from the server.
React or another framework may be better when an app needs deeply complex, persistent client-side state that doesn't map to server-rendered HTML, like a collaborative design tool; when a team has deep existing React expertise; or when multiple independent frontends, like a web app and a separate mobile app, genuinely need to share one API.
For a deeper comparison, CodeCurious has a full article on Hotwire vs React, which should you pick in 2026.
Hotwire tends to be a strong choice when you're building a Rails monolith, when most logic naturally belongs on the server, when you want to minimize frontend complexity and move quickly, when you need interactive interfaces without the overhead of a full SPA, and when your team is primarily Rails-experienced.
A practical example: an internal admin tool for managing customer orders, with searchable tables, inline status updates, and a few modals, is close to an ideal Hotwire use case. Almost every interaction maps directly onto Frames, Streams, or a small Stimulus controller.
A JavaScript framework may serve you better for highly interactive applications that constantly react to fast-changing client input, complex client-side state that needs heavy manipulation before touching the server, offline-first applications, rich browser-based editors, advanced real-time client-side experiences like collaborative cursors, and applications with an intentionally independent frontend and backend, possibly maintained by separate teams.
Hotwire is not always better, and the right choice depends on where your application's complexity actually lives.
Smaller JavaScript payloads mean less code to download and parse before a page is interactive. Faster navigation comes from Turbo Drive avoiding full reloads. Partial updates through Frames and Streams mean the browser only processes what changed. Server-side rendering delivers a mostly complete page immediately, improving perceived load time. Reduced frontend complexity means fewer chances for client-side bugs to degrade a long session.
Actual performance still depends on your database queries, caching strategy, network conditions, and implementation quality. Hotwire removes a category of frontend performance problems, but it won't fix a slow N+1 query on its own.
Server-rendered content means a crawler gets complete HTML immediately, rather than an empty shell waiting on JavaScript. Crawlable HTML and real URLs come naturally from Turbo Drive. Page titles and meta tags work exactly as they always have in Rails layouts and views. Progressive enhancement means core content and navigation still work if JavaScript fails to load.
Hotwire itself is not an SEO solution; you still need good titles, clean heading structure, and standard SEO practices. What it provides is a server-rendered foundation that makes implementing those fundamentals straightforward.
Watch for using Stimulus for something Turbo already handles, like fetching HTML manually in a controller instead of using a frame or stream. Avoid creating unnecessary JavaScript for behavior plain HTML and CSS could cover. Don't overuse Turbo Streams by stacking many actions where a simple frame replacement would do. Keep Turbo Frame structure clear; ambiguous or deeply nested frame ids cause confusing update bugs. Make sure controllers actually handle the turbo_stream format, since a mismatch silently breaks updates. Don't ignore accessibility: dynamic updates should still respect focus and be discoverable by screen readers. Avoid making interactions depend entirely on JavaScript, which undermines progressive enhancement. Don't treat Hotwire as a full JavaScript replacement, and don't force a genuinely complex, stateful interface into Turbo and Stimulus when it needs a real client-side architecture.
Avoiding these usually comes down to one principle: reach for the simplest tool that solves the actual problem.
Start with normal Rails HTML and add Turbo only where it clearly helps. Use Frames for isolated regions with a single responsibility, and Streams for targeted updates rather than full reloads. Use Stimulus only for behavior that genuinely needs JavaScript, and keep controllers small and focused. Reuse partials across full pages and stream responses. Keep business logic in models and service objects, not JavaScript. Lean on progressive enhancement so core functionality works without JavaScript. Consider accessibility for dynamically inserted content. Question new complexity before adding it, and measure performance with real profiling rather than assumptions.
Hotwire applications still need thorough testing, even with less JavaScript. Rails integration and request tests verify controller behavior, including that a Turbo Stream response contains the expected actions and targets. System tests, using Capybara with a real or headless browser, confirm that Frame and Stream updates actually apply in a rendered page. Stimulus controllers with meaningful logic can be tested with JavaScript tools, though many simple ones are adequately covered by system tests. Form submissions deserve coverage for both the success path and the validation-error path rendering correctly inside its frame or stream.
Less JavaScript doesn't mean less test coverage; it shifts the focus from client-side unit tests toward request specs and full system tests exercising the real request and response cycle.
Let's tie this together with an article management interface supporting listing, searching, pagination, inline editing, creating, deleting, validation, and a live count.
Listing and searching, scoped to a frame:
<%= turbo_frame_tag "articles" do %>
<%= form_with url: articles_path, method: :get, data: { turbo_frame: "articles" } do |form| %>
<%= form.text_field :query, value: params[:query] %>
<%= form.submit "Search" %>
<% end %>
<div id="articles_list"><%= render @articles %></div>
<%= link_to "Next", articles_path(page: @articles.next_page, query: params[:query]) %>
<% end %>
Turbo Drive handles standard pagination links, while the search form's data-turbo-frame attribute keeps search and results scoped inside the same frame. Inline editing follows the pattern shown earlier in this article.
Creating, via a stream that prepends the record and updates the count:
<%= turbo_stream.prepend "articles_list", partial: "articles/article", locals: { article: @article } %>
<%= turbo_stream.update "article_count", Article.count %>
Deleting, removing it and updating the count in the same response:
<%= turbo_stream.remove @article %>
<%= turbo_stream.update "article_count", Article.count %>
Validation errors render inside the create form's frame, exactly as shown in the forms section. Turbo Drive covers ordinary navigation, Frames scope the list and search, and Streams handle create, update, and delete. Stimulus isn't strictly required here, a good demonstration of how far Turbo alone carries a typical CRUD interface.
What is Hotwire in Ruby on Rails? Hotwire is a set of techniques for building fast, modern web applications by sending HTML directly from the server rather than relying primarily on JSON and client-side JavaScript to render the interface.
Is Hotwire part of Rails? It's the default frontend approach included with new Rails applications, maintained by the Rails core team, though it's technically a separate set of libraries that could be used outside Rails.
Is Hotwire a JavaScript framework? Not exactly. Turbo and Stimulus are JavaScript libraries, but Hotwire as a whole is better described as an approach that minimizes how much custom JavaScript you write.
What is the difference between Turbo and Stimulus? Turbo handles server-driven navigation and HTML updates through Drive, Frames, and Streams. Stimulus adds small, targeted JavaScript behavior to HTML already on the page.
Is Hotwire better than React? Neither is universally better. Hotwire tends to fit server-rendered, CRUD-heavy applications well, while React fits applications with complex, persistent client-side state better.
Does Hotwire replace JavaScript? No. It reduces how much JavaScript you typically write, but Stimulus and custom JavaScript remain part of most real applications.
Can Hotwire be used with Rails 8? Yes, it's included by default in new Rails 8 applications and works with Rails 8 conventions out of the box.
Is Hotwire good for SEO? Its server-rendered architecture makes standard SEO practices straightforward, since crawlers receive complete HTML directly, though Hotwire itself is not an SEO solution.
Can Hotwire build a single-page application? Turbo Drive can make navigation feel similar to an SPA by avoiding full reloads, but the underlying model is different, since the server still drives most updates.
When should I use Hotwire? It's a strong fit for Rails monoliths, CRUD applications, dashboards, and internal tools where most logic belongs on the server and the team is Rails-focused.
Is Hotwire good for beginners? Yes. Because it builds on standard Rails views, partials, and controllers, beginners can be productive without first learning a separate frontend framework and its tooling.
Hotwire is an approach to building modern, interactive web applications by sending HTML from the server instead of leaning on a heavy JavaScript frontend. It's made up of Turbo, covering navigation through Turbo Drive, scoped updates through Turbo Frames, and multi-part DOM changes through Turbo Streams, along with Stimulus, which adds targeted JavaScript when a purely server-driven update isn't enough.
Together, these tools let Rails developers build inline editing, live comment sections, dynamic forms, and even real-time updates, while keeping the majority of application logic in Ruby, on the server, where Rails has always been strongest.
Hotwire matters in modern Rails development because it offers a genuine alternative to the assumption that every interactive application needs a full JavaScript framework and a separate API layer. For the many applications that are fundamentally server-rendered with pockets of interactivity, it removes a significant amount of unnecessary complexity while still delivering a fast, responsive experience.
If you haven't tried it yet, the best next step is to experiment. Take an existing Rails view, wrap a section in a Turbo Frame, or add a small Stimulus controller to a button. You'll likely be surprised by how much interactivity you can build with tools you already understand.