One of the biggest problems with mixing client and server code like this together is coupling which is one of the reasons that client-server architecture was created to avoid.

I watched the video, and it didn't feel compelling honestly, backend frameworks like symfony have ways to compose client and server side code for years.

There are many ways to mix and match client(js) and server (php) in a composable way without react. Components can be created on the server side as well (mixing html+js+php). Only thing lacking is DX and type checking.

Most other solutions are not composable to the same extent. It’s not enough to be able to mix client/server (although that’s a start). It’s more about it going all the way — for example, the state of the client parts is preserved on refreshes of the server parts around them, the same components can be reused on either side depending on whether you want them to be state-driven or data-driven, state changes are predictably instant, you can stay within the same paradigm while moving code between highly interactive and fully data-driven (no awkward moving stuff “between PHP and JS” when something needs to be “more dynamic” and back when it needs some server-only feature), ability to send closures over the server to the client and back (lets you essentially .bind server actions over the network), all of this is integrated end-to-end (a client button can know precisely how long to display an indicator while the server is data fetching next page and the next client code and CSS are loading), and of course all of this being fully composable (you can nest server stuff into client stuff into server stuff into client stuff and they all retain state and refresh as you would expect).

If you don’t see what’s new about this I encourage you to look deeper because this definitely isn’t what backend frameworks have been doing for years so you are missing something.