Skip to content

SYSTEM Cited by 1 source

Hotwire Turbo

Turbo (sometimes referred to as Rails Turbo or Hotwire Turbo — the open-source repo is hotwired/turbo-rails) is the navigation substrate of the Hotwire stack from Basecamp / 37signals. It enables partial-page-update navigations in server-rendered web apps by intercepting link clicks + form submissions, fetching fragments of HTML from the server, and swapping them into the DOM without a full browser reload.

The architectural pitch is "server-rendered HTML over the wire, SPA-like UX without the SPA framework" — a third path between full-page reloads and a heavy client-side runtime (React, Vue, Ember).

Where Turbo sits in a navigation taxonomy

GitHub explicitly distinguishes Turbo from hard navigations and React soft navigations in concepts/navigation-mix. Their definition: "a Rails Turbo transition that updates targeted page regions without a full reload. It avoids some hard-navigation overhead but still depends heavily on server-rendered responses." (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

The cost shape of a Turbo navigation is server-bound: the client doesn't pay browser cold-start or React hydration, but it does pay the full server-rendering cost for the page fragment. This is in tension with React soft navigations (client-runtime-bound, server cost minimised) and with hard navigations (everything paid in full).

Why server-cost-bound navigations benefit from cache-hint

signalling

Because Turbo's critical path is server-render time, anything that lets the server skip work translates directly into Turbo HPC improvement. GitHub's service-worker cache-hint header does exactly that — when the service worker tells the server that issue data is already cached client-side, the server can return a thin response and skip the application-fragment computation. "This had an especially strong effect on Turbo navigations, because Turbo paths are still heavily constrained by server response time. Once the service worker can signal that issue data is already present, the server spends much less time computing the application fragment, and Turbo benefits almost immediately from that reduction in backend work." (Source: sources/2026-05-14-github-from-latency-to-instant-modernizing-github-issues-navigation-performance)

The architectural lesson generalises: a cache-hint protocol that lets the server skip work helps server-bound navigation classes more than it helps client-runtime-bound classes, even if the underlying client cache was originally designed for client-side rendering.

In the wiki

This is a stub system page for cross-link completeness with the GitHub Issues navigation rewrite. The 2026-05-14 source treats Turbo as a fixed external constraint ("a Rails Turbo transition") and does not disclose Turbo internals.

Seen in

Last updated · 542 distilled / 1,571 read