Last Tuesday Mira, who runs the frontend half of our Inertia admin panel, pinged me with a screen recording. She opens the invoice export preview, which takes a while to build because it renders roughly eleven thousand table rows. Then she types a customer name into the sidebar search, and the search results just sit there, frozen, until the export preview has finished. "Why does the search care about the export?" she wrote. Fair question. On the PHP side we stopped asking it a long time ago, because our runtime answered it for us.

Think about what a PHP-FPM pool actually does. One worker gets stuck on a 9 second report query, and the next request goes to another worker, does its job and returns in 40 ms without ever learning that the report exists. Shared-nothing is a habit we stopped noticing. Each request lives and dies alone, so a slow one cannot make an unrelated one look slow. As far as I can tell from the React 19.3 changes, the client side is now picking up that same habit for transitions, and I think it is the right call. It also makes the frontend a more natural place for PHP people to think in.

Here are the facts. A transition is whatever you wrap in startTransition(), and it tells React the update is real but can give way to anything urgent, like a keystroke. Before 19.3, if two transitions were in flight at the same time, React could tie them together, so the cheap one ended up waiting for the expensive one to finish. In 19.3, transitions that have nothing to do with each other can render independently. Mira's search and her export preview become two FPM workers instead of one worker with a long queue behind it. The article that tipped me off is careful to add that how much you gain depends on what you render and whether the updates really touch each other, and I'd underline that.

There's a strong objection here and I want to take it seriously. None of this makes anything faster. A component that needs 400 ms to render still needs 400 ms. All React changes is when that time gets spent and what gets to cut in line. A sceptic would say that smarter scheduling is an excellent way to hide a bloated component, the way a big FPM pool lets you ignore a terrible query until the database falls over at month end. I've lived through that month end. The pool kept the site answering, and it also kept anyone from fixing the query for two years.

So yes, isolation can turn into an excuse. I still land on the side of welcoming it, because the alternative is worse. When everything is coupled, the user pays for your slowest code on every interaction, including the ones that never touched it. With isolation they pay only for the thing they actually asked for. That's a better default, and it doesn't stop you from profiling. If anything it makes profiling more honest, because once the export preview no longer drags the search down with it, its 400 ms shows up in the profiler as its own cost instead of hiding inside everyone else's numbers.

What I'd take from this as a backend developer is less about React APIs and more about the shape of our responses. Mira's export preview and her search both call Laravel endpoints. If those two endpoints share a session lock, or one giant props payload gets rebuilt on every Inertia visit, the client can schedule as cleverly as it likes and the two pieces of work will still be tied together on the server. Independence has to exist all the way down for the scheduler to do anything with it. We already know how to give each piece of the UI its own lean endpoint, with partial reloads, separate routes and no session writes on read-only calls. Now there's a concrete reward for doing it.

To be fair, transitions were never meant for everything. A controlled input still has to update immediately, and the usual pattern still holds: keep the value you type into urgent and push only the expensive derived state into startTransition(). That hasn't changed. The new part is that you can now have several of those background updates running without them coming back to you as one combined, slow lump.

Where I'm genuinely unsure is the team dynamics. In our shop the person who writes the endpoint is rarely the person who wraps the update in startTransition(), and isolation on one side only pays off if the other side cooperates. So, to those of you who ship PHP backends for React frontends: when the UI gets janky, who owns the fix in your team, and has a change like 19.3 ever moved that line?