Turbolinks Laravel Package

Product Decisions This Supports

• Perceived-performance features without a frontend rewrite. This package wires Turbolinks into a Laravel app: middleware to detect Turbolinks requests, Blade directives/helpers to emit data-turbolinks-track asset fingerprints, and redirect handling for partial responses. The product outcome is faster-feeling navigation (body swap instead of full reload) on an existing server-rendered Blade app, at a fraction of the cost of an SPA migration.
• Roadmap sequencing: "make it fast" vs. "rebuild it." It is a credible bridge to close out a performance OKR this quarter while an Inertia/Livewire/Hotwire decision waits for next cycle. It buys time; it does not change the architecture.
• Build vs. buy. The honest framing: you are not really buying this package — it is a thin (~100-line) integration wrapper. The actual decision is Turbolinks vs. Hotwire Turbo vs. Inertia.js vs. Livewire. This package only removes maybe a day of glue code, so its value is mostly as a validated reference implementation.
• Use cases it fits: legacy Blade monoliths, internal admin back-offices, content/marketing pages served by Laravel, and any funnel where users bounce on slow multi-page flows (multi-step forms, list → detail → back navigation).
• Risk register input. With ~110 stars, an unspecified/unverified repository, and a score under 1.0, this is a low-signal dependency. Turbolinks itself is archived upstream (superseded by Turbo), so adopting this is a deliberate bet on a frozen stack — a point that belongs in the technical-debt ledger, not just the sprint plan.

When to Consider This Package

Consider it when all of the following hold:

• The product is a classic server-rendered Laravel/Blade app with no client-side router, and the team has no appetite for an SPA rewrite.
• The dominant UX pain is navigation latency between server pages (repeat asset downloads, full re-renders), not client-side interactivity.
• You are on — or can pin to — the Laravel/PHP versions this package actually supports; verify in a spike, because the package predates current Laravel releases and unmaintained middleware is a silent-breakage risk on upgrade.
• The frontend is reasonably disciplined: page-specific JS runs on turbolinks:load, third-party widgets (analytics, chat, payment iframes) are re-initializable, and there are no assumptions of a clean document per navigation.
• You accept the exit cost: it is removable, but every feature built afterward must respect body-swap semantics.

Look elsewhere when:

• Greenfield project. Go straight to Hotwire Turbo (Turbolinks' maintained successor, same mental model, broader ecosystem) or Inertia.js/Livewire if you want component-level interactivity. Starting on an archived paradigm is a roadmap tax you cannot justify.
• You need rich client state, offline behavior, optimistic UI, or real-time collaboration — that is an SPA/Inertia conversation, not a Turbolinks one.
• Your pages are heavy on DOM-mutating third-party scripts (ads, tag managers, complex embeds). Body swaps will surface a long tail of "works on reload, breaks on navigate" bugs that will consume the savings.
• Strict accessibility or SSR-hydration guarantees are contractual. Verify focus management, screen-reader announcements, and scroll restoration explicitly before committing.
• Supply-chain posture matters (regulated, enterprise): unverified repo + no active maintainer is a procurement blocker regardless of MIT licensing.

How to Pitch It (Stakeholders)

To executives (30 seconds): "We can make the app feel roughly twice as fast on page-to-page navigation with a small, MIT-licensed integration layer, no redesign and no new platform. It is a tactical win that lets us hit this quarter's performance target while we decide whether to invest in a proper frontend modernization next cycle. Cost: days, not months. Risk: the underlying technique is a legacy one, so we treat it as a bridge, not a foundation."

To engineering: "This is a thin Laravel integration for Turbolinks — request middleware, Blade helpers for asset tracking, redirect handling. It replaces maybe a day of hand-rolled glue. Two caveats I want your read on: (1) upstream Turbolinks is archived and Hotwire Turbo is the maintained successor with essentially the same programming model, so the migration path is clean but now is the cheaper moment to pick the successor; (2) the package's Laravel/PHP compatibility needs a half-day spike before we commit. If the spike is clean, this is a low-ceremony way to ship the performance win and keep the door open."

Decision framing to leave on the table: approve a short spike comparing this package against Hotwire Turbo on the same codebase — same effort envelope, and it turns a legacy dependency into a maintained one. Default to this package only if the spike shows Turbo's integration cost is materially higher and the app is genuinely on a short horizon before replatforming.