I really enjoyed this write-up - especially the “semantic mismatch” point. That resonated a lot.
One thing we’ve found helpful in our apps is thinking of Inertia as replacing navigation and form submissions, with partial reloads and co. sprinkled in, rather than replacing HTTP entirely. We still reach for fetch/axios for background tasks or strictly ordered workflows, and that hybrid approach has felt very natural.
On the sequential request section: the lack of Promises tripped us up early too, but it clicked once we internalised that router calls behave like browser navigation, not like normal HTTP requests. Redirects, cancellations, history changes, and full reload fallbacks don’t map cleanly onto a single Promise lifecycle, which explains the design choice - even if it feels surprising at first.
The deploy/stale-chunk section was interesting. We’ve had good results relying on Inertia’s built-in asset versioning (the X-Inertia-Version header via the middleware) rather than polling the Vite manifest - it forces a hard reload automatically when the asset hash changes, which removed a lot of that operational concern for us.
Totally agree on props discipline. Treating every prop as public API output was a big mindset shift for our team too. We now only pass Resources/DTOs to Inertia responses to avoid accidentally leaking model attributes. Model toArrays are the absolute devil with Inertia.
Curious if you ended up adopting any tooling or conventions around prop auditing?
Founder of CodeCrank.ai (AI-accelerated MVPs) and DCTSoft.com (performance-first web development). Passionate about 100/100 PageSpeed scores, rigorous testing, and modern web standards.
Location
Richmond KY
Education
Georgetown University
Work
Founder at CodeCrank.ai and DCTSoft.com. Co-founder at Omnitrain.ai
Great comment, Charlie, appreciate you sharing what's worked for your team.
Full disclosure: this was a production codebase that landed in my lap. I was adding features on top of an existing Inertia setup, not choosing the stack. So my perspective is heavily weighted toward "here's what I hit as someone who didn't opt into this" rather than "here's how I'd architect an Inertia app from scratch." That context probably explains why some of the workarounds felt more abrasive than they would to a team that internalized the mental model early.
Your framing of router calls as browser navigation rather than HTTP requests is the cleanest explanation of the design choice I've seen — wish that was the first thing in the docs instead of something you have to discover through broken await calls. On prop auditing: no formal tooling. The codebase I worked in was already leaking model attributes in a few places, which is what flagged the concern.
For what it's worth, my own stack is Vue + explicit API calls — whether that's a SPA or Nuxt with server routes. Standard fetch/axios, Promises behave like Promises, no router abstraction in between.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I really enjoyed this write-up - especially the “semantic mismatch” point. That resonated a lot.
One thing we’ve found helpful in our apps is thinking of Inertia as replacing navigation and form submissions, with partial reloads and co. sprinkled in, rather than replacing HTTP entirely. We still reach for fetch/axios for background tasks or strictly ordered workflows, and that hybrid approach has felt very natural.
On the sequential request section: the lack of Promises tripped us up early too, but it clicked once we internalised that router calls behave like browser navigation, not like normal HTTP requests. Redirects, cancellations, history changes, and full reload fallbacks don’t map cleanly onto a single Promise lifecycle, which explains the design choice - even if it feels surprising at first.
The deploy/stale-chunk section was interesting. We’ve had good results relying on Inertia’s built-in asset versioning (the X-Inertia-Version header via the middleware) rather than polling the Vite manifest - it forces a hard reload automatically when the asset hash changes, which removed a lot of that operational concern for us.
Totally agree on props discipline. Treating every prop as public API output was a big mindset shift for our team too. We now only pass Resources/DTOs to Inertia responses to avoid accidentally leaking model attributes. Model toArrays are the absolute devil with Inertia.
Curious if you ended up adopting any tooling or conventions around prop auditing?
Great comment, Charlie, appreciate you sharing what's worked for your team.
Full disclosure: this was a production codebase that landed in my lap. I was adding features on top of an existing Inertia setup, not choosing the stack. So my perspective is heavily weighted toward "here's what I hit as someone who didn't opt into this" rather than "here's how I'd architect an Inertia app from scratch." That context probably explains why some of the workarounds felt more abrasive than they would to a team that internalized the mental model early.
Your framing of router calls as browser navigation rather than HTTP requests is the cleanest explanation of the design choice I've seen — wish that was the first thing in the docs instead of something you have to discover through broken await calls. On prop auditing: no formal tooling. The codebase I worked in was already leaking model attributes in a few places, which is what flagged the concern.
For what it's worth, my own stack is Vue + explicit API calls — whether that's a SPA or Nuxt with server routes. Standard fetch/axios, Promises behave like Promises, no router abstraction in between.