Inertia.js: SPA routing for Laravel, Rails and Django without an API

The problem Inertia.js solves: a frontend without a second API

The usual path to a single-page application means building an API first. Your controllers stop returning views and start returning JSON, a second routing layer appears in the browser, and authorization and validation have to be re-expressed on the client. Inertia.js takes the other route. The backend keeps doing what the README says it already does well: routing, controllers, models, authorization, validation. Instead of returning a template, it returns a page component with its data. The browser receives that component and its props, swaps the page in place, and no full reload happens.

The audience is narrow and specific. It is for teams already committed to Laravel, Rails, Phoenix, Django, Symfony, AdonisJS, Go or .NET on the server, and to React, Vue or Svelte on the client. It is not for teams building a backend that other clients will consume, because the response format is designed around one frontend rather than a general-purpose API contract. The README is explicit that everything stays in one application: one codebase, one router, one source of truth.

Adapters on both sides: what the repository actually contains

Inertia is not a framework and does not replace the ones you use. It is the layer between backend and frontend, and it works through adapters. The React, Vue and Svelte adapters all live in the inertiajs/inertia repository, which the repository layout confirms: packages/ holds core, react, vue3, svelte and vite, and the root package.json wires them together with scripts such as dev:core, dev:react, dev:vue and dev:svelte, all driven by pnpm with a pnpm-workspace.yaml at the root.

On the server, the Laravel adapter is officially maintained, and community adapters cover Rails, Phoenix, Django, Symfony, AdonisJS, Go and .NET. That split matters when you evaluate the project. The client half is developed in this repository under a single release cadence. The server half is not, with the exception of Laravel. If your backend is Django or .NET, the quality of your experience depends on an adapter maintained outside this repository, and the README does not describe the support level of any individual community adapter.

The versioning reflects that split. Recent releases include v3.7.1 and v3.7.0 on the 3.x line, and v2.3.28 on the older 2.x line, published within hours of each other. Two maintained lines exist in parallel, so a new project should confirm which line its adapter targets before writing code. The default branch is 3.x, and the documentation linked from the README is the v3 documentation.

Installing Inertia.js and making a first page visit

The README does not carry install steps itself. It points to the documentation at inertiajs.com/docs/v3/getting-started, which takes you from installation to how the protocol works under the hood, and to Laravel's official React, Vue and Svelte starter kits, which ship with login, registration, password resets, email verification, two-factor authentication and profile settings already working. If you are starting from nothing on Laravel, a starter kit is the shorter path than assembling the pieces by hand.

The repository itself is a pnpm workspace. The root package.json defines how the packages are built and developed:

pnpm install
pnpm build:all

The first command installs the workspace, the second runs the build filter across ./packages/*. This is the contributor path, not the application path. If you are building an application rather than working on Inertia itself, you install the framework-specific packages instead, and the documentation is where those package names and setup steps live.

For local development of the library, the root scripts run all adapters at once under concurrently, with each adapter named in the output:

pnpm dev

That command starts core, react, svelte, vue and vite together. The test applications are separate, and each one pairs a server with a Vite dev server:

pnpm dev:test-app:vue

What you should see is a server process and a Vite process running side by side, with the server watching the tests/app directory and the Vite process serving the adapter's test app. The README does not document a single-command install for an application using Inertia, and the repository's own scripts assume pnpm throughout.

What a page visit sends: protocol features and their cost

The feature list reads like a product surface rather than a router. Page visits, forms, file uploads with progress and server-side validation; optimistic updates that render before the server responds and roll back if it fails; partial reloads, deferred props, prefetching, polling and infinite scroll; server-side rendering, code splitting and view transitions; history encryption for pages holding sensitive data; and DevTools that show every request, header and hydrated prop while you build.

The interesting part is what these imply. Partial reloads, deferred props and prefetching all exist because the server is still in the loop on every navigation. An Inertia page visit is a request to your backend, not a client-side route resolution, which is exactly why authorization and validation keep working as they did. The trade-off is that the network is on the critical path for navigation in a way it is not for a purely client-rendered SPA with a cached data layer. Prefetching and deferred props are the project's answer to that, and the documentation is where you should read how each behaves before relying on it.

Optimistic updates deserve the same scrutiny. Rendering before the server responds and rolling back on failure is a real feature with a real failure mode: a rollback is visible to the user, and the documentation describes the rollback behaviour but the README does not describe how to present a failed optimistic update without disrupting the page.

Where Inertia.js is the wrong tool

The clearest boundary is the API case. Inertia returns page components with their data, not a general-purpose resource representation. If you need a public API that mobile apps, third parties or a separate service will consume, you will end up building that API anyway, and Inertia sits alongside it rather than replacing it. Choosing Inertia for a product whose primary consumer is not your own frontend means maintaining both paths.

The second boundary is adapter risk. The React, Vue and Svelte adapters live here under one release process. Rails, Phoenix, Django, Symfony, AdonisJS, Go and .NET adapters are community-maintained, and the README does not state their support level, their release cadence or which Inertia version each tracks. Before adopting Inertia on a non-Laravel backend, that is the first thing to check, because a lagging adapter determines which version of the client packages you can use.

The third is operational. Server-side rendering is listed as a capability, and the README's deployment section notes that Laravel Cloud handles your asset build and SSR server for you. If you deploy elsewhere, running an SSR process is your responsibility, and the README does not describe how to run that process outside a managed platform. Teams that want a static frontend with no server process at request time are not the audience.

Alternatives and the actual difference in approach

The honest alternative is the conventional SPA plus API split, where your backend exposes JSON endpoints and the frontend owns routing, data fetching and client-side authorization checks. The difference is not cosmetic. In that model, the server does not know about page components at all, and every screen has to handle loading, error and empty states explicitly. In Inertia, the server returns the page and its props in one response, so those states are shaped by the backend rather than assembled on the client. You trade a reusable API contract for a shorter path from controller to screen.

The second alternative is server-rendered templates with islands of interactivity. That keeps the request-per-navigation model Inertia also uses, but without a component tree owning the whole page. If most of your screens are static and only a few need rich interaction, Inertia's page-component model is more machinery than the problem requires.

Neither alternative is worse in general. The deciding question is whether the API has consumers other than your own frontend. If it does, build the API and treat Inertia as the wrong layer. If it does not, Inertia removes a whole category of client-side data plumbing.

Maintenance, versions and the MIT licence

The repository is not archived, and the last push was on 2026-09-16. Releases land on two lines: v3.7.1 and v3.7.0 on 3.x, and v2.3.28 on 2.x. Because the default branch is 3.x and the documentation is the v3 documentation, a new project should start on 3.x unless its server adapter has not caught up. That is the upgrade cost to plan for: the client packages in this repository move on their own schedule, and a community server adapter that targets 2.x pins you to 2.x regardless of what ships here.

Inside the repository, the maintenance surface is a pnpm workspace with a shared build, type-check and lint pipeline, plus Playwright for browser tests and a playgrounds directory. Contributing guidance is in CONTRIBUTING.md, and the README points to a security policy for reporting vulnerabilities.

The licence is MIT, stated in the README and in LICENSE.md. That is permissive and permits commercial use and modification, but this is not legal advice; if you are redistributing Inertia or bundling it into a product with unusual licensing constraints, have counsel read the actual LICENSE.md text rather than this summary.

Editorial conclusion

Adopt Inertia.js if your backend already owns routing, controllers, authorization and validation, and you want React, Vue or Svelte without maintaining a separate JSON API. Do not adopt it if you need a public, versioned API that clients other than your own frontend will consume; the adapter model assumes one backend serving one frontend. Before committing, verify which adapter exists for your framework on the community adapters page, confirm your framework version against the 3.x documentation, and read the protocol section to understand what a page visit actually sends and receives.

Frequently asked questions

Official sources

1. inertiajs/inertia on GitHub
2. License: MIT
3. Project website
4. README
5. Releases