It's very different after the initial render. LiveView creates an Elixir process for each client which holds all of the necessary state, and then the client uses websockets to send requests and receive responses from that process. There's no rehydration done on the server-side, the state is kept in memory (by default. You can delete parts of it from memory but then you have to re-fetch it if you need it again). Requests and responses are absolutely tiny and you don't have to trust the client to send the current state, only the operation it wants to perform.

It looks like the PHP version uses AJAX requests instead, but most importantly it doesn't persist any state on the server continuously. And then it looks like client requests send the current state, as well as checksums etc. to keep it secure. Then the server spins up a new instance of the class, hydrates it with the current state, runs the requested operation and returns the dom patch.

It looks like LiveView has much smaller requests/responses and both client and server do much less work. But the tradeoff of that is that you have lots of Elixir processes, which I guess pretty much only works with something like the BEAM. And you have to be careful about memory because those processes all hold a client's state. If you want to display a page of database results then that's fine but you'll want to clear them from the state instead of keeping them in memory for as long as the user is on the page. And of course then you're going to lose some performance if you need that data again for a future operation by the client. The Livewire approach doesn't force you to think about that, you don't have the choice to hold the state in memory.

i think livewire is just a port of Phoenix LiveView for laravel ecosystem.