Ask a room of Laravel developers which frontend to use and you'll get three camps, each completely sure of itself. The Livewire people think you're overcomplicating things. The Inertia people think Livewire is fine "for small apps". The SPA people are already writing an OpenAPI spec.

Here's the uncomfortable truth: all three are good. I've seen great products built with each, and I've seen teams suffer with each. The suffering almost never comes from the tool. It comes from picking it for the wrong reason.

So instead of crowning a winner, let's look at how each one actually works, and the handful of questions that should decide it for you.

How each one works, in one paragraph each

Livewire: the server drives the UI

You write components as PHP classes with Blade templates. When the user types or clicks, Livewire sends a small request to the server, the component's PHP code runs, and the changed HTML is patched into the page. State lives on the server. For instant client-side bits (dropdowns, toggles) you add Alpine.js. You can build a dynamic interface while writing almost no JavaScript.

Inertia: server routing, JavaScript pages

You keep Laravel's routes and controllers, but instead of returning a Blade view, a controller returns a React, Vue or Svelte page component with props: Inertia::render('Invoices/Index', ['invoices' => $invoices]). Inertia handles the navigation, so it feels like a single-page app. There's no separate API to design; the controller is the API for that page.

Separate SPA: two apps, one contract

The frontend is its own project (React with Vite, Next.js, Vue, whatever you like), usually deployed separately, and it talks to Laravel through a JSON API with Sanctum or tokens for auth. The API is a real product with its own versioning, docs and contract.

Side by side

Laravel 12's official starter kits reflect this split nicely: there's a Livewire kit, and React and Vue kits built on Inertia. A separate SPA isn't a starter kit because it's really two projects.

The questions that actually decide it

1. Is there (or will there be) a mobile app?

This is the biggest one. If a React Native or native app needs the same data and actions, you're building a JSON API anyway. At that point, a web SPA on the same API means one backend contract for every client. That doesn't automatically rule out Inertia or Livewire for an admin panel, but the main product UI has a strong reason to share the API.

2. Who is on the team?

A team of strong Laravel developers who don't love JavaScript will be productive with Livewire on day one. A team that already thinks in React components will find Inertia natural and will get the huge React ecosystem for free. Fighting your team's strengths is the most expensive choice on this list.

3. How "app-like" is the interface?

Forms, tables, filters, dashboards, CRUD with some dynamic behaviour: Livewire handles this beautifully. A drag-and-drop planner, a rich editor, an interface that must keep working on a bad connection, or anything with lots of instant client-side state: that's where server round trips start to show, and Inertia or an SPA feel better.

4. Do you need SEO and fast first paint?

Livewire renders HTML on the server, so it's naturally friendly to search engines. Inertia can do server-side rendering, but it's an extra moving part to run. An SPA usually needs a framework with SSR (like Next.js) if public pages must rank well. For an internal dashboard, none of this matters.

Myths worth dropping

"Livewire doesn't scale." It scales like any server-rendered Laravel app: with your server and database. The real cost is a request per interaction, so chatty components (updating on every keystroke) need care, like debouncing input and keeping component state small.

"Inertia locks you in." Your controllers, models and business logic are plain Laravel. If you later need a public API, you add API routes and resources next to your Inertia controllers. It's extra work, not a rewrite.

"A separate SPA is more professional." It's more separated, which helps when separate teams own each side. For a small team, it can mean two deploys, CORS settings, auth tokens, an API contract to maintain and twice the build tooling, all to ship the same screens.

Mixing is allowed

You don't have to pick one for everything. A common, sensible setup: a JSON API that serves the mobile app and a customer-facing SPA, plus an internal admin area built with Livewire or Inertia inside the same Laravel app, because staff screens are mostly forms and tables and don't need a public contract. The only rule is to make the split deliberate, not accidental.

The short version

• Livewire: PHP-first teams, form-heavy and admin-heavy apps, one simple deploy.
• Inertia: full-stack teams who like React or Vue, rich UI without designing an API.
• Separate SPA: a mobile app or third parties share the API, or frontend and backend are separate teams.

Which one did you pick for your last Laravel project, and would you pick it again?