4 ms·

How similar is this thing to the Phoenix.LiveView?

by Errancer 5y ago

cute_boi 5y ago
i think livewire is just a port of Phoenix LiveView for laravel ecosystem.
- ecmascript 5y ago
  Not really, Liveview uses websockets and Livewire uses http. So there is quite a big underlying difference
  - montblanc 5y ago
    Not sure what the OP is asking - if he's asking what kind of API or abilities they give you I would say pretty much equivalent things. If he's asking what the underlying architecture is then I yes they're different.
    - mcintyre1994 5y ago
      The server-side process in LiveView does enable some things that I don't think this does, like multiplayer games, collaborative apps and anything where you can have data/events made available to the client that doesn't originate from that client. One of the nice things with LiveView IMO is that it makes all of that work in the same programming model as the client sending things to the server and getting responses. It doesn't matter if the event originated from the client, some other client or eg. Phoenix Pub/Sub, it all looks and works the same.
mcintyre1994 5y ago
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.

How similar is this thing to the Phoenix.LiveView?

cute_boi 5y ago

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

ecmascript 5y ago
Not really, Liveview uses websockets and Livewire uses http. So there is quite a big underlying difference
- montblanc 5y ago
  Not sure what the OP is asking - if he's asking what kind of API or abilities they give you I would say pretty much equivalent things. If he's asking what the underlying architecture is then I yes they're different.
  - mcintyre1994 5y ago
    The server-side process in LiveView does enable some things that I don't think this does, like multiplayer games, collaborative apps and anything where you can have data/events made available to the client that doesn't originate from that client. One of the nice things with LiveView IMO is that it makes all of that work in the same programming model as the client sending things to the server and getting responses. It doesn't matter if the event originated from the client, some other client or eg. Phoenix Pub/Sub, it all looks and works the same.

mcintyre1994 5y ago

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.