Inertia.js v3.1: Rescued Deferred Props and the Axios-Free Stack

Host

Hey everyone, welcome back to Allur, your go-to spot for everything happening in the world of PHP, Laravel, and modern web development. I’m your host, Alex Chan.

Host

Joining me today is Mark Sterling. Mark is a Senior Lead Developer at NorthStack, where they build some of the most complex Laravel-Inertia apps I’ve ever seen. Mark, it is so great to have you on Allur.

Guest

Thanks, Alex! It’s great to be here. Honestly, I’ve been waiting for this specific update for a while, so I’m stoked to chat about it.

Host

I can tell! So, let’s jump right in. Inertia v3.1—the community is calling this a "pivot point." In your eyes, why is this release such a big deal compared to, say, the jump from version 1 to 2?

Guest

Yeah, that’s a great way to put it. You know, version 2.0 gave us "Deferred Props," which was huge. It meant we could load a page and let the slow stuff—like a heavy report or a third-party API call—load in the background. But the problem was stability. If that background call failed, the whole UI could just… well, it could get messy.

Host

"Rescued Deferred Props." I love that name—it sounds like a superhero team or something. Can you explain for the listeners what exactly is being "rescued" here?

Guest

Haha, it kind of is a superhero for your UI! So, okay, imagine you have a dashboard. You’ve got your user stats, a list of recent orders, and then a little widget that shows, I don't know, live currency rates from an external service. In v2.0, you’d "defer" that currency widget so the rest of the page loads instantly. But if that currency service timed out or threw a 500 error during a refresh, the user might see a blank spot or, worse, a crash.

Host

Oh, interesting! So it’s like a "stale-while-revalidate" approach, but specifically for when things go south?

Guest

Exactly. It’s about "graceful degradation." Instead of the "white screen of death," the user just sees slightly older data for that one specific piece while the rest of the app stays totally interactive. For enterprise apps, where uptime and perceived stability are everything, this is a massive win. Actually, we had a project last month where a slow database query was causing intermittent UI flickers on reloads. If we’d had v3.1 then, the users wouldn't have even noticed the blip.

Host

That’s such a relief for developers. I mean, we’ve all been there where one slow API call ruins the whole user experience. But let’s talk about the other elephant in the room: the "Axios-Free Stack." This one surprised me. Inertia has used Axios since day one, right?

Guest

Since day one. It was the industry standard. But, if you look at how the web has evolved, native Fetch and XHR capabilities in browsers are actually really good now. By removing Axios, Inertia is basically saying, "We don't need this extra weight anymore."

Host

Is the bundle size difference that noticeable?

Guest

It’s significant! It’s not just the kilobytes of the library itself, but it’s the dependency tree. When you strip that out, your Time to Interactive—or TTI—gets a nice little boost. But more importantly, Inertia now uses its own internal XHR client. This means the framework has 100% control over how requests are intercepted and handled. It’s "tuned" specifically for the Inertia protocol.

Host

Okay, but I’m thinking about all the developers out there—myself included—who have built their whole auth systems or header management using Axios interceptors. Does this mean we have to rewrite everything?

Guest

(Laughs) Well, the short answer is "yes," but the long answer is "it’s easier than you think." You can't use `axios.interceptors` anymore because, well, Axios isn't there. Instead, you move that logic to Inertia’s native event hooks. So, you’d use `router.on('before', ...)` or `router.on('error', ...)`.

Host

Right, it’s more unified. It’s not "Inertia + this other library," it’s just… Inertia. You mentioned it signals that the framework is maturing. Where do you see this going next? Is this the end of the "glue" era?

Guest

I think so. Inertia is becoming a "robust foundation." We’re seeing it move toward a "zero-config" future. They’re handling the plumbing—the headers, the status codes, the state preservation—so we can just focus on building the product.

Host

It’s such an exciting time to be in the Laravel ecosystem. It feels like every few months, the "floor" for what a "good" app looks like just gets raised.

Guest

Totally. And the best part is, even with these big changes, the upgrade path in Laravel is usually pretty smooth. The Inertia team is really good about documentation.

Host

Mark, this has been so enlightening. Before we wrap up, for someone listening who’s looking to migrate their app to v3.1 this weekend, what’s your one "pro-tip"?

Guest

Ooh, good question. I’d say: start by auditing your Axios interceptors. Map them out on a piece of paper first. See what’s adding headers, what’s handling 401 errors, and then look at the new Inertia `router.on` documentation. Once you get that bridge crossed, the rest of the upgrade is honestly a breeze. And definitely play around with `Inertia::defer` in your controllers to see those rescued props in action—it’s actually pretty satisfying to watch a page *not* break when you force an error.

Host

(Laughs) Breaking things on purpose to see them stay fixed—the true developer way! Mark, thank you so much for joining us on Allur.

Guest

My pleasure, Alex! Thanks for having me.

Host

What a great conversation. It’s fascinating to see Inertia.js move toward this self-reliant, Axios-free future. The takeaway for me today is that stability doesn’t just mean "it works when everything goes right"—it means "it works even when things go wrong." Those "Rescued Deferred Props" are a game-changer for anyone building complex dashboards or data-heavy apps.