There is one thing I have always liked about Laravel.

It lets me build business applications quickly.

Routes are in Laravel.

Controllers are in Laravel.

Authentication is in Laravel.

Validation is in Laravel.

Business logic is in Laravel.

Database access is in Laravel.

Then React became more popular, and we started moving more of the frontend into a separate JavaScript application.

That gave us many benefits.

But it also introduced another problem.

Suddenly we needed to manage two worlds.

Laravel
   ↓
API
   ↓
React

Then:

Laravel
+
React
+
TypeScript
+
API clients
+
State management
+
Frontend routing
+
Authentication handling

This architecture can be excellent.

I use it when the application really needs that separation.

But for many Laravel applications, I sometimes feel that we create an API boundary simply because modern frontend development tells us that we should.

This is where Inertia.js becomes interesting.

And now Inertia.js 3 is making this architecture even more mature.

In May 2026, Inertia.js 3 entered beta with important changes including PHP enum support, better TypeScript generics, improved form handling, request cancellation changes, ESM-only packages and other updates. It requires PHP 8.2+, Laravel 11+ and React 19+ for its React adapter. (laravel.com)

For me, Inertia's biggest idea is still very simple:

Why build a separate API when Laravel can remain the application backend and React can still provide a modern frontend?

The traditional SPA architecture

Let's start with the architecture many teams know.

Browser
   ↓
React
   ↓
API
   ↓
Laravel
   ↓
Database

A user opens the application.

React starts.

The frontend makes API requests.

Laravel processes them.

JSON comes back.

React updates the state.

This is a valid architecture.

But we now have to maintain two distinct applications.

The backend knows nothing about the frontend page structure.

The frontend knows nothing about Laravel's controller logic except through APIs.

This separation is useful when we genuinely need it.

But it also creates work.

An API is not free

When we build an API-first architecture, we need to think about:

Routes
Controllers
Resources
Authentication
Authorization
Validation
Pagination
Errors
Frontend API clients
Types
Loading states
Caching

Then somebody needs to make sure the backend response matches what React expects.

For every feature, we create another boundary.

Sometimes that is exactly what we want.

Sometimes it is unnecessary.

Inertia takes a different approach

Inertia allows Laravel to continue handling the server-side routing and controller layer while React, Vue or Svelte becomes the frontend UI.

Laravel remains in control of:

Routes
Controllers
Middleware
Authentication
Authorization

The frontend receives page data and renders the interface.

Laravel's official Laravel 13 starter kits use Inertia 3 with React 19, Vue 3 or Svelte 5, depending on the selected frontend stack. (laravel.com

This gives us an interesting middle ground.

We don't have a classic Blade application.

But we also don't necessarily need a completely separate API-driven frontend.

Think of Inertia as a bridge

The architecture becomes:

Laravel
   ↓
Controller
   ↓
Inertia
   ↓
React Page

Instead of:

Laravel
   ↓
JSON API
   ↓
React API client
   ↓
React Page

The frontend is still a modern JavaScript application.

But Laravel remains the place where the request lifecycle lives.

I like this because it reduces some of the plumbing.

Laravel controllers still feel like Laravel controllers

Imagine:

public function index()
{
    return Inertia::render('Customers/Index', [
        'customers' => Customer::latest()->paginate(),
    ]);
}

The controller is still easy to understand.

We are not creating:

API controller
+
Resource
+
React API service
+
Frontend fetch

just to display a page.

Laravel gets the data.

Inertia passes the page props.

React renders them.

That is a very simple architecture.

This is especially good for business applications

Think about:

ERP
CRM
HRMS
Inventory
Booking
Admin panel
Billing

A huge part of these applications is:

Tables
Forms
Filters
Pagination
Search
Settings
Reports
CRUD

These features need good frontend experiences.

But they do not necessarily require a completely independent backend and frontend architecture.

This is where Inertia is attractive.

Inertia lets React feel more like a Laravel frontend

This is probably the best way I can explain it.

In a pure SPA architecture, React owns routing.

Inertia allows Laravel to keep server-side routing.

So:

Route
↓
Laravel Controller
↓
Inertia Page
↓
React

The application still feels like Laravel.

The UI still feels like React.

That combination is powerful.

This does not mean React becomes less powerful

This is an important point.

We still get React.

We can use:

Components
Hooks
State
TypeScript
React libraries
UI libraries

We are not turning React into Blade.

We are simply changing how the server and client communicate.

That makes Inertia an architectural choice rather than a replacement for React.

Inertia 3 is a meaningful upgrade

The current Inertia 3 beta brings several changes that I think Laravel developers will appreciate.

One of the useful changes is stronger TypeScript support, including generics for form errors and slot props.

It also adds PHP enum support directly in Inertia::render() responses. (laravel.com)

That is interesting because modern PHP applications increasingly use enums.

For example:

enum InvoiceStatus: string
{
    case Draft = 'draft';
    case Paid = 'paid';
    case Cancelled = 'cancelled';
}

Being able to send those values more naturally to the frontend helps create stronger contracts.

Type safety becomes more important

This connects directly with the TypeScript topic I wrote earlier.

Suppose Laravel sends:

InvoiceStatus

and React expects:

'draft' | 'paid' | 'cancelled'

The stronger the contract, the easier it becomes to work on a large frontend.

Inertia 3's improvements around TypeScript generics and enum support are a good step in this direction. (laravel.com)

This is especially useful when Laravel and React are maintained by the same team.

Forms are one of the strongest parts of Inertia

Forms are everywhere in business applications.

For example:

Create Customer
Edit Customer
Create Invoice
Update Product
Create Booking
Change Password

A traditional API architecture means we manage:

Request
Loading
Validation
Errors
Success
Redirect

on the client.

Inertia gives Laravel-style form handling while keeping the React interface.

Inertia 3 also includes form-related improvements such as useFormContext and more explicit request cancellation behavior. (laravel.com)

For a Laravel developer, this makes the frontend workflow feel much more natural.

Laravel validation can remain close to Laravel

Imagine Laravel validation:

$request->validate([
    'name' => ['required', 'string'],
    'email' => ['required', 'email'],
]);

We still get Laravel's normal validation system.

The frontend can display those errors.

This is one of the big benefits for me.

We don't need to recreate the same validation rules in JavaScript just to provide a good user experience.

The server remains the source of truth.

But frontend validation can still exist

This does not mean:

"Never validate in React."

Client-side validation can improve user experience.

For example:

Email format
Required fields
Simple ranges

can be checked immediately.

But important business validation should still happen on the server.

This is the same rule I follow regardless of framework:

Frontend validation is for user experience.

Backend validation is for security and correctness.

The routing experience is one of Inertia's biggest advantages

In a separate React SPA, we usually need:

React Router

or another frontend routing system.

Then Laravel has its own routes.

Now we have two routing worlds.

With Inertia:

Laravel routes
=
Application routes

React renders the appropriate page.

That can make URL management and authorization much simpler.

Authorization remains on the server

This is one thing I really like.

Suppose:

GET /invoices

Laravel middleware and policies decide what the user can access.

React does not decide.

It only displays what the server allows.

This fits naturally with Laravel's authorization architecture.

For a SaaS system, that can be very useful because tenant isolation stays in the backend.

This is particularly useful for multi-tenant SaaS

Imagine:

Company A
Company B
Company C

The Laravel backend knows:

Current user
Current team
Current tenant
Permissions

The controller can load only the data the user is allowed to see.

Then Inertia passes that data to React.

The frontend doesn't need to reconstruct tenant authorization logic.

This reduces duplication.

Inertia does not mean there is no API

This is another misunderstanding.

An application can use Inertia for its web interface and still provide APIs.

For example:

Web
↓
Laravel + Inertia + React

and:

Mobile
↓
Laravel API

and:

Desktop
↓
Laravel API

That is actually a very interesting architecture.

The web application gets the productivity benefits of Inertia.

Other clients still get proper APIs.

This fits a SaaS product very well

Suppose I have:

Xnoll Web
Xnoll Mobile
Xnoll Desktop
Third-party API

I don't necessarily need the same frontend architecture for all clients.

I could have:

Laravel
│
├── Inertia web application
│
├── API
│
├── Queue workers
│
└── Business services

Now the same backend logic supports multiple clients.

That is a much more flexible architecture.

Inertia 3 also removes Axios from the default package setup

One of the notable Inertia 3 changes is that Axios is no longer included by default, and developers can use the built-in HTTP client or an Axios adapter where needed. (laravel.com)

I actually like this direction.

Every dependency has a maintenance cost.

If a framework can provide what most applications need without another dependency, that's usually helpful.

At the same time, applications that genuinely need Axios can still add it.

ESM-only is another important change

Inertia 3 packages are ESM-only, so CommonJS require() is no longer supported. (laravel.com)

This reflects a larger JavaScript ecosystem trend.

Modern frontend tooling is increasingly moving toward:

ES Modules
TypeScript
Modern bundlers

This is another reason Laravel developers working with React need to understand the JavaScript toolchain, even if PHP remains their primary language.

SSR becomes easier to use with Laravel

Server-side rendering is another area where Inertia becomes interesting.

Laravel's current starter kits support Inertia SSR for React, Vue and Svelte applications, and Laravel provides commands for building and starting the SSR server. (laravel.com

That gives us a hybrid architecture:

Laravel
↓
Inertia
↓
SSR
↓
React

The initial page can be server-rendered, then React takes over on the client.

This can improve initial page experience and SEO for appropriate applications.

SSR does add another process

Of course, there is no free lunch.

Now we have:

Laravel
+
PHP
+
SSR Node process
+
Vite

That means another runtime to deploy and monitor.

So I would use SSR when there is a clear reason.

For an internal ERP dashboard, SEO may not matter much.

For a public SaaS marketing page or content-heavy application, SSR can be valuable.

Again:

Architecture follows requirements.

Inertia is also good for page transitions

Because Inertia manages navigation between server-driven pages while maintaining a client-side application experience, users can get SPA-like navigation without rebuilding the entire application around a separate frontend router.

This is one of the reasons I think it works well for business applications.

The browser can feel like an SPA.

The backend can still feel like Laravel.

That is a very good combination.

The architecture remains understandable

This is perhaps my biggest reason for liking Inertia.

When I open a Laravel + Inertia application, I can still follow:

Route
↓
Controller
↓
Service
↓
Model
↓
Inertia Page

I don't have to jump across:

Backend API
+
Frontend API client
+
Frontend router
+
Data-fetching abstraction

unless the application actually needs those things.

That can make debugging easier.

This is useful for developers who know Laravel first

Suppose my team is strong in Laravel.

I can give them a React frontend.

But the application's routing, controllers, validation and authentication remain familiar.

That lowers the conceptual cost.

Developers can gradually improve their React knowledge without having to throw away the Laravel mental model.

I think that is one of Inertia's strongest advantages.

But I would not use Inertia for everything

There are applications where I would absolutely choose a proper API-first architecture.

For example:

Multiple completely independent frontends

or:

Mobile-first platform

or:

Public API product

or:

Multiple external clients

If the backend needs to be a platform independent of the web UI, an API-first architecture can make more sense.

Inertia is strongest when the web application and backend are closely connected.

This is why I see three useful Laravel architectures

Laravel + Blade / Livewire

Best when:

Server-driven business application

Laravel + Inertia + React/Vue/Svelte

Best when:

Modern frontend
+
Laravel server-side application

Laravel API + separate frontend

Best when:

Multiple clients
+
Strong backend/frontend separation

None of these is automatically superior.

The important skill is knowing why we selected one.

Inertia also reduces API duplication

This is another practical benefit.

Suppose we have:

Customers page

The Laravel controller already knows how to get the customers.

Why create:

GET /api/customers

just so the React application can request exactly the same data?

With Inertia, the controller can provide the page props directly.

That means fewer endpoints to maintain.

Less API documentation.

Less API versioning pressure.

Less frontend data-fetching code.

That can be a significant reduction in complexity.

But don't put giant datasets into page props

This is another architectural rule.

If a page needs:

10 million customers

we should not simply send all of them through Inertia.

Use:

Pagination
Filtering
Search
Lazy loading
Partial reloads

Inertia supports partial reloads and lazy data patterns specifically to avoid sending unnecessary data on every navigation. Inertia 3 has also changed some of these APIs, such as removing the old Inertia::lazy() helper in favor of Inertia::optional(). (laravel.com)

That is another place where good backend architecture remains important.

Performance still depends on your backend

Inertia does not magically fix:

Slow SQL
N+1 queries
Huge responses
Bad indexes
Slow external APIs

If the controller takes 2 seconds, the user still waits.

So all the lessons around:

Query optimization
Caching
Redis
Queue processing
Observability

still matter.

Inertia changes the frontend architecture.

It does not remove backend engineering.

This connects nicely with what I wrote earlier about observability

A useful architecture is one where we can trace:

Browser
↓
Inertia request
↓
Laravel
↓
Database
↓
Response

That makes performance investigation easier.

And because Laravel remains the primary server-side application, our existing logging, monitoring and tracing approach remains useful.

The Laravel ecosystem is clearly embracing the model

Laravel 13's official starter kits now include Inertia 3 for the React, Vue and Svelte approaches, while Livewire 4 is offered for the PHP-driven frontend approach. (laravel.com

I think this is a good sign.

Laravel is effectively saying:

"You can build a modern frontend without giving up Laravel's server-side development experience."

That is a valuable proposition.

My final view

I don't think Inertia 3 means:

"API-first architecture is dead."

And I don't think it means:

"Every Laravel project should use React."

What I think it does is give Laravel developers a very practical middle ground.

We can have:

Laravel routing
Laravel controllers
Laravel authentication
Laravel authorization
Laravel validation
Laravel business logic

while also having:

React
TypeScript
Modern components
Rich UI
SPA-like navigation

without automatically turning the project into two completely independent applications.

For me, this is especially attractive for SaaS products where the web frontend is closely tied to the Laravel backend.

The biggest lesson is simple:

Don't build an API just because you are using React.

Build an API when you actually need an API.

And when the web application and Laravel backend belong together, Inertia gives us a very clean way to keep them together while still getting a modern frontend.

That is why I think Inertia 3 deserves serious attention from Laravel developers in 2026.