Laravel 12 starter kits: Livewire or React with Inertia?
Compare the actual architecture choices in Laravel 12 and evaluate them with a representative workflow, explicit page props, and failure-state checks.
React and Inertia belong to the same option
The Laravel 12 React starter kit uses Inertia. React is the component library; Inertia connects those components to Laravel routes and controllers. Treating React, Inertia, and Livewire as three competing starter kits obscures the decision before a project begins.
This article discusses the Laravel 12 kit generation: React 19 with Inertia 2 on one path, or a Livewire frontend on another. These version numbers describe that architecture, not the latest releases. A kit is application code you will maintain, so inspect the generated project and lockfiles rather than assuming future installer output remains identical.
The important question is who owns interaction state. A PHP-oriented team may prefer Livewire for forms and server-backed actions. A team building complex browser interactions may prefer React with Inertia. Both still need Laravel validation, authorization, and clear boundaries around persistence.
Keep the page response intentionally small
An Inertia controller returns a page name and props, not a separate public API contract by default. The page component receives those props in the browser. Do not serialize a whole model merely because it is convenient; choose the fields this screen requires.
This route is an example for an existing Laravel 12 React/Inertia 2 application with its default User model. The corresponding resources/js/pages/account/show.tsx component must render the account prop. Missing page files or a mismatched resolver path are integration errors, not empty-account states.
<?php
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Route;
use Inertia\Inertia;
Route::get("/account", function (Request $request) {
return Inertia::render("account/show", [
"account" => [
"displayName" => $request->user()->name,
],
]);
})->middleware("auth")->name("account.show");
Prototype a workflow that exposes the costs
A static dashboard will make almost every option look easy. Use a searchable list, an edit form with server validation, and a slow save instead. Include an expired session and an authorization denial. Watch what happens when the user presses Back, submits twice, or changes filters while a request is in flight.
For Livewire, inspect the number and timing of server round trips in the chosen interaction. For React with Inertia, inspect where local state can disagree with the last server response. Neither observation is an automatic rejection; it identifies the behavior the team must understand and maintain.
The following is a decision record template, not configuration for either framework. Fill it with observed results from the prototype, including failures. Avoid a numeric score until the team agrees which constraints matter.
scope: authenticated-account-editor
candidates:
- livewire
- react-with-inertia
checks:
- server-validation-preserves-input
- expired-session-has-a-recovery-path
- denied-record-is-not-serialized
- back-navigation-restores-expected-context
- repeated-submit-does-not-duplicate-writes
reviewers:
- php-maintainer
- frontend-maintainer
decision: pending-prototype
Choose the ownership model you can sustain
React with Inertia is useful when reusable browser components and local interactions dominate the work while Laravel remains the route and data boundary. Livewire is useful when the team wants more interaction behavior near PHP and templates. A separate API-driven SPA is another architecture, justified by needs such as independent clients or deployment boundaries; it is not implied merely by choosing React.
Whichever path wins, keep domain operations independent of presentation. Test writes and permissions at the Laravel boundary, then add browser coverage for the interactions that motivated the choice. Assign responsibility for frontend dependency updates, server behavior, and accessibility so the starter kit remains a foundation rather than an unowned bundle of generated code.