Features of a Laravel Inertia project
Content Index
- What is Laravel Inertia and Why It Solves So Many Problems
- How Inertia Blends the Best of SSR and SPA
- Main Features of Laravel Inertia (the complete list)
- Rendering with Inertia
- Props: direct server → client communication
- Controller-Controlled Views
- Middleware and Global Messages
- Classic Laravel Routing with an SPA Experience
- User Model and Authentication
- Where are the Views?
- Integration with Laravel Authentication and Sessions
- Layouts and Application Structure
- Navigation with and Smart XHR Requests
- Minimal State Management Without External Store
- App Initialization with Inertia
- Component Location and Usage
- Form Handling with Inertia
- Real Advantages of Working with Laravel Inertia
- When to Choose Inertia.js over Blade or Livewire?
- Recommended Use Cases
- Frequently Asked Questions
- Conclusion
When you start working with Laravel and want a truly smooth experience between backend and frontend, you inevitably end up looking at Inertia.js. And for good reason: it allows you to create an SPA without setting up a full REST API, without struggling with Vue Router, or duplicating logic between client and server.
The first time I tried Inertia and created a new project in Laravel Inertia, I was coming from projects using Breeze and Blade, so I was surprised by how natural it feels to work with Inertia... almost as if Laravel could natively render Vue, which is the key piece and main feature.
In this article, I'll tell you about all the features of Laravel Inertia, how it works internally, and why it's gaining so much ground among developers.
What is Laravel Inertia and Why It Solves So Many Problems
The classic problem with SPAs with a separate API
The traditional SPA approach (API + JS client) has two side effects:
- You have to duplicate concepts (Laravel routes + Vue/React routes).
- You lose native functionalities like sessions, middlewares, or validation.
Furthermore, setting up a complete CRUD ends up being more complex: one part in Laravel, another part in the frontend... and two worlds that need to be kept in sync.
How Inertia Blends the Best of SSR and SPA
Inertia simplifies everything by returning JavaScript components directly from Laravel controllers.
You don't need a REST API to display data: Laravel passes props to the component, and that's it.
The magic happens because Inertia captures requests and prevents page reloads. This way, you get an SPA experience, but with the simplicity of Laravel's SSR.
I remember that when I reviewed my controllers for the first time, I thought: "this works just like Blade... except what's being rendered is a Vue component." And that's when it finally convinced me. This is the beauty of Inertia; it's a very smooth evolution of what we have in base Laravel. Now we simply return a Vue in the view instead of a Blade, with minimal changes for everything to work as expected.
Main Features of Laravel Inertia (the complete list)
Here we will do what the competitors don't: a clear, complete, and explained list.
Rendering with Inertia
Spoiler alert: Inertia is used to render components in Vue (or React, if you choose). In this case, we use Vue. This is the core of Inertia: simply rendering components instead of using Blade files.
The same applies to all views we render, as you can check if you inspect the controllers. The names are quite descriptive and reflect the operation they perform well. Basically, we have a complete authentication module: login, registration, password recovery, etc. Nothing out of the ordinary.
return Inertia::render('Users/Show', [
'user' => $user
]);And that returns a Vue/React component instead of a Blade view.
Props: direct server → client communication
Laravel sends data directly to the component as props.
You don't need Axios, fetch, or additional endpoints.
Controller-Controlled Views
An important point is that, in Inertia, views are rendered via controllers, not directly by components as you might do in "pure" Laravel (or Blade). If you want to render something, by default you do it via controllers, as we are doing here.
Middleware and Global Messages
Laravel comes with a recommended middleware: HandleInertiaRequests.
This file is also important, as it acts as a middleware, i.e., an intermediary. We use it when we want to pass something to the components. Later, we will use it to send flash messages, which are those temporary messages displayed after an action is performed (for example, successfully saving a form).
This is where we configure the data we want to send globally to all views.
Classic Laravel Routing with an SPA Experience
All your routes are still Laravel routes.
Inertia only intercepts the navigation and converts it into internal navigation without a reload.
User Model and Authentication
The user model is totally basic, with the `Authenticatable`, `HasFactory`, `Notifiable` traits, and a few others. There is also a Provider, which seems borrowed, but there's not much mystery here.
Where are the Views?
If you check the `resources/views` folder, you'll see there's only one view. We pause here to explain this: I already told you that we use controllers and that we render Vue components. So, where are the other views?
Answer: I already hinted at it... they are Vue components!
We only have one Blade view, but there are many views rendered through Vue components.
For every page you see, there's a component behind it. And they are organized like this:
Pages: contains the complete pages.
Components: contains the reusable pieces used to build those pages.
The structure is quite well modularized.
Integration with Laravel Authentication and Sessions
The best part: you change nothing.
Sessions, middlewares, guards... they work the same as always.
When I rebuilt my login and registration, I practically reused the Blade code, just transforming it into components.
Layouts and Application Structure
We also have the Layouts folder, which contains common structures for the pages.
If we open the startup file (`app.ts` or `app.js`), we'll see how the application is initialized.
We also have `App.blade.php`, which is the only Blade file, and we are importing it as the main template. Inertia already tracks it automatically, so you shouldn't move or rename it.
Inertia encourages a broad yet very organized structure:
- `/Pages` → complete pages
- `/Components` → reusable pieces
- `/Layouts` → global templates
Navigation with <Link> and Smart XHR Requests
Inertia replaces link navigation using:
<Link href="/posts/1">View post</Link>This prevents page reloading and maintains the frontend state.
Minimal State Management Without External Store
You don't always need Vuex, Pinia, or Redux.
The "controller → props → component" pattern greatly reduces the need for a global store.
App Initialization with Inertia
The app startup is similar to any Vue project:
We use `createApp`, although it is customized here.
The path where our pages are located is indicated.
Where the components will be mounted is defined.
Custom plugins (like the navigation progress bar) are configured:
createInertiaApp({
title: (title) => `${title} - ${appName}`,
resolve: (name) => resolvePageComponent(`./pages/${name}.vue`, import.meta.glob<DefineComponent>('./pages/**/*.vue')),
setup({ el, App, props, plugin }) {
createApp({ render: () => h(App, props) })
.use(plugin)
.use(Oruga)
.use(CkeditorPlugin)
.use(ZiggyVue)
.mount(el);All this happens in the startup file.
Component Location and Usage
As we already saw, pages are in the Pages folder, and reusable elements are in Components. You can see everything that is being used and also reuse them yourself.
Form Handling with Inertia
An important difference compared to a traditional Vue application is data handling. Here we don't use axios directly. Instead, we use an internal Inertia mechanism called useForm from Inertia:
const form = useForm({
name: '',
email: ''
});
form.post('/users');We import and use this `useForm` directly to handle forms and data in a cleaner way. Here we define the form data, submission, and any other related logic.
Real Advantages of Working with Laravel Inertia
Time savings compared to setting up API + SPA
- You don't duplicate routes, you don't create API controllers, you don't create Axios services.
Everything goes through Laravel. - Minimal learning curve for Laravel developers
- If you come from Blade, you feel right at home from day one.
The same thing happened to me: I started migrating views and had the flow set up in an afternoon. - Native integration with Vue/React/Svelte
- Since the backend delivers props to the components, the frontend is extremely simple.
When to Choose Inertia.js over Blade or Livewire?
Brief Comparison
- Blade: perfect for traditional sites.
- Livewire: ideal when you don't want to touch JS but need reactivity.
- Inertia: the option for modern apps that combine Laravel + Vue/React.
Recommended Use Cases
- Dashboards
- CRUD Systems
- Applications with complex logic but dynamic views
- Projects where you want an SPA without creating a full REST API
Frequently Asked Questions
- Does Inertia replace Blade?
- No, but in an SPA you will only need one Blade file.
- Can I use Inertia without Vue?
- Yes, it also works with React and Svelte.
- Is it a good option for large projects?
- Yes, because it keeps the logic in Laravel and the frontend modular.
- What about SEO in an SPA with Inertia?
- You can enable SSR with Node to deliver HTML to the bot.
Conclusion
Laravel Inertia combines the best of server and client without forcing you to create a full REST API or a complex JS router.
If you already work with Laravel, using Inertia feels almost natural: controllers, routes, middleware, validation... nothing changes, but the frontend becomes much more dynamic.
In my experience, the learning curve is minimal, and development becomes very agile: a login, a CRUD, or a dashboard is set up in half the time compared to a traditional SPA.
If you are looking for flexibility, speed, and a clean architecture, Laravel Inertia is one of the best options available in modern web development.
I agree to receive announcements of interest about this Blog.
We're going to present what we have in detail: the project, its features, and how it works.