The experience of a SPA without building two applications. And what that choice really costs.
Building a modern interface often leads to separating frontend and backend. Along come a dedicated API for the screens, a second router, new error handling, validations to keep in sync and client state that keeps growing.
What if we could get the experience of a SPA without starting by building two applications?
In this two-voice talk, the Barry brothers go in search of another formula: Inertia.js v3.
With Laravel and React, we'll build a modern music application: instant navigation, persistent layout, forms, search, infinite pagination, deferred data, prefetching and optimistic updates. Yet routes, controllers, authentication, authorisation, validation and data access will remain entirely driven by Laravel.
We'll then open the black box to discover that Inertia is neither a frontend framework nor a Laravel-specific feature. It's a protocol that connects a classic backend to pages written in React, Vue or Svelte. Laravel will be used for our demos, but the same model can be implemented with Rails, Phoenix, Django and many other environments.
We'll see how Inertia turns a first HTML response into a client-side navigable application, how pages and their props travel through the protocol, and how its third version makes the experience even smoother with instant visits, deferred props, prefetching, optimistic updates and better cache handling.
But every transmutation requires an equivalent exchange. So we'll finish with the limits of this architecture: coupling between frontend and backend, varying adapter maturity, multi-client applications, offline needs, and situations where a real API remains the best choice.
Inertia.js is not a silver bullet. It may be something more useful: a simple protocol that lets each part of our stack do what it already does well.